昨日は「Microservices Casual Talks」に参加してきた．前日まで補欠35番目で厳しいかなーと思ったけど，奇跡的な繰り上がりで参加できた．本当に参加したくて祈り続けてたからその効果かも？w

「マイクロサービスアーキテクチャ」は Amazon で予約していたから既に届いてるんだけど，まだ読めてなくパラパラと開いた程度で，事前に読んでいればもっと理解できたなと後悔した．

開催側のポリシーに準じた範囲で，自分の意見も合わせて簡単にメモを残しておこうと思う．特に参考資料が多く出ていて，読めていないものもあるため，合わせてリンクしておこうと思う．

『マイクロサービスアーキテクチャ』とAzure Service Fabric @satonaoki

開口一番「アズールじゃなくてアジュールです」には吹いた！最近 Docker Meetup もそうだけど，頻繁に Azure の話を聞くし，Microsoft も DevRel に力入れてるんだなーと思ったりした．あと Sway を使ったスライドで結構オシャレだなと思った．特に右に半ページ進んでいく感じは新しいなーと．セッション内容としては「マイクロサービス本の紹介」と「Principles Of Microservices by Sam Newman」の解説が中心で凄く勉強になった．

sway.com

https://docs.com/satonaoki/3740/microservices-casual-talks-azure-service-fabricdocs.com

Principles Of Microservices by Sam Newman

翌日に動画を見てみて「マイクロサービス」と簡単に言うけど，その原則は多岐にわたっているし，考えないといけないことも多いなーと感じた．と同時にマイクロサービスごとにオーナーシップ（自律性）を持って進化していくというプロセスがスクラムやリーンの考え方に似ていて，組織とサービスはセットで考えるべきだよなーとも感じた．「Principles Of Microservices」として以下の8項目が紹介されていたので，ポイントとなる部分や資料を箇条書きにしておく．

Modelled Around Business Domain
- ヘキサゴナルアーキテクチャ(Hexagonal architecture翻訳) | blog.tai2.net
- "DDD の上にマイクロサービスは定義されている"
- The Twelve-Factor App （日本語訳）
Culture Of Automation
- マイクロサービスをスケールさせるためにはあらゆるオペレーションを自動化する必要がある
  - Infrastructure Automation
  - Automated Testing
  - Continuous Delivery
Hide Implementation
- （具体例として）データベースに直接接続するアプリケーションは1つに制限して依存度を無くす
- スキーマ変更などの影響を広げないように
- API で接続する
- BoundedContext
Decentralise All The Things
- マイクロサービスを担当するチームごとにオーナーシップ（自律性）を持つ
- "Giving people as much freedom as possible to do the job at hand"
- Redirecting…
- マイクロサービス間をバスで疎結合に保つ
Deploy Independently
- 影響を抑えるために1ホスト（コンテナ）1サービスという形を目指す
- Consumer-Driven Contracts: A Service Evolution Pattern
- GitHub - realestate-com-au/pact: This repository has moved to https://github.com/pact-foundation/pact-ruby
Consumer First
- HumaneRegistry
Isolate Failure
- 障害も独立させる
  - Fix Timeouts
  - Bulkhead
  - Circuit Breakers
Highly Observable
- ログ収集や可視化を通してトレーサビリティを高める
- 障害が発生した時は Correlation Ids を使ってマイクロサービス間を辿っていけるようにする

www.youtube.com

Principles of microservices velocity from Sam Newman

www.slideshare.net

マイクロサービスの今とこれから @shot6

<ポリシーに準じて割愛>

紹介されていた資料（ハッシュタグに流れてたの）だけをリンクしておこうと思う．

www.infoq.com

philcalcado.com

How Microservices are linked at Cookpad @adorechic

クックパッドの事例紹介のセッションだった．資料は既にブログ内に up されているので，詳しくはそちらを参照した方が良いと思う．

techlife.cookpad.com

セッションを聞いていて感じたのは，マイクロサービスの原則を取り入れながらサービスを常に改善していて，さらに適切なツールが無ければ OSS で作ってしまえば良いという推進力で，とにかく技術志向な意思決定を徹底していて凄いな！という点だった．既に Pact を使って CDC を実現しているのもそうだし，トレースログの仕組みを運用してるのもそうだし，まさに「Principles Of Microservices」を満たしているサービスだなと驚いた．

github.com

techlife.cookpad.com

Yet Another Talk on Microservices @tmaesaka

1番刺激を受けたセッションだった．プレゼンが非常に上手く引き込まれて聞いてしまったし，話の節々で知的だなと感じた．「キラキラネーム現象」は笑ったw

plex.hatenablog.com

マイクロサービスはモノリシックサービスと比較すると関心事が増えるため，ある意味オーバーコストになり，スタートアップの創業時に選択するべきではないという話だったり，マイクロサービスは組織論にも繋がるため「エンジニア」と「エンジニアリングマネージャー」と「プロダクトオーナー」の間で視点が異なることもあるという話も参考になった．またアーキテクチャは流行りではなくその本質を考えて Polyglot に選択するべきという話も説得力があった．Fastly スゲェなぁ...！

途中聞き逃してしまったんだけど "Bikeshedding" という表現はどういう意味だろう？

同じくセッションで紹介されていた資料をリンクしておく．

github.com

techblog.netflix.com

パネルディスカッション

マイクロサービスが増えたときにローカル環境に全てを構築することは現実的ではないという話は少し驚いた．確かに Docker を使うことが障壁を下げる前提になるとは思うけど，クラウド上に専用の開発環境が用意されていて，他のマイクロサービスはそこに接続する形で開発をすると言っていた．ある意味で同じチームと考えるのではなく，別のチームが作っているマイクロサービスという捉え方をするなら，そういう形に落ち着くかもしれないなとも思った．あとカナリア環境の話はもう少し調べてみようと思っている．

マイクロサービス間の関係を可視化するところはまだ各社が独自に進めている段階でまだ課題が残っているという話も出ていた．まだまだマイクロサービスと一言に言っても答えはないというのが印象的だった．

まとめ

本当に本当に参加できて良かった．マイクロサービス本はさっそく今日から読んでいるんだけど，本だけじゃなくブログなども合わせて読もうと思っている．「マイクロサービスに関してチームでディスカッションするだけでも価値がある」という話も印象的で，まずは原則を知った上で，自サービスにどう適用していけるのかを考えてみたいと思っている．マイクロサービスを勉強しよう！