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