こと、てらだよしおさんのマイクロサービスにまつわるおはなしをがっつり聞いてきました。私自身が、インフラ力がないというか、そもそもインフラに興味がない(おい)、ので、そういう話はこの記事にはあまり出てきません。話やらを色んな所でしてきたが、その感想として、現場の実情とあまりにも乖離していてどうしていいかわからないとか浮世離れしているなどと言った感想を多くもらったそうです。(あー、すいません私もその中の一人です・・・。今はどこから始めればマイクロサービスに近づいていけるかということを念頭に置いて話されているのだそうです。マイクロサービスは銀の弾丸ではないまあ、この業界、何事に置いても銀の弾丸など存在しなくて、もちろんマイクロサービスも例外ではないということです。マイクロサービスに関わる技術を身につけておくことはもちろん重要であると。その技術の使いみちを正しく見極められることが重要とのこと。管理できないとすぐ破綻するそれはまあインフラに詳しいわけではない私でもわかります。それにすればハッピーになるのではない自分たちのサービスに合ったものを、自分たちで組み合わせないといけない。デザインパターンはあるにはあるけれども、それをただ適用しても何も上手くいかない、と。それは何においてもそうですね。寺田さんはアジャイルを別の例としてあげられていました。いう、(スクラムという)型にこだわるのではなくチームが必要とするものをまずやっていこう、というお話でした。何に向いているかスケーラビリティの向上やサービスの独立性を高めることは、マイクロサービスでなくとも可能。変更に強いシステム作りや耐障害性を高めるなどがより向いている、とのこと。今までの技術の延長線上これが今回一番私に刺さった話。話の前半と終盤で同じことを繰り返されていたので、寺田さんも大いに伝えたいことだったのではないかと推測。マイクロサービスは、あくまでも今までの技術の延長線上にあるのであって、突然変異で出てきた救世主などではないということ。これが何を意味するかというと、今までの技術でちゃんとできていないことが、マイクロサービスに変えただけでちゃんとできるようになることはない、と。マイクロサービスにすると考慮することが増えて、正しく管理できないとすぐ破綻するわけですから。マイクロサービスにするにはここから先は、より具体的で実践的なお話が続いたのですが(もう眠いので)特に気になった部分を箇条書きで。共有ライブラリは呪縛まったく同じライブラリでも全てのサービスが一つの場所を見るのではなく、サービス毎に別々に管理するように。今ならバージョン管理するためのツールは揃ってるからできるよね、というお話。?ってちょっと思った。(って、いつの時代の人だよ)障害は起きる(必ず起きる)そこで、起きないように努力するのではなく、起きても大丈夫なシステムを作ることを考えたほうがよい。038久しぶりの0完。1373完1TLE1WA。