マイクロサービス戦略はスモールチーム（アジャイル）も一緒に考えないと危ない
よくある話で
「モノリスな環境があって、きちんとマイクロサービス化してドメインごとに独立したプロセスを実現して、よりイテレーティブな改善を実現しよう」
というのはあって、この方向性はとても正しい
一方で、これを実現しようと組織が動くとソフトウェアアーキテクチャのみが先行するケースがある。大きなモジュールをマイクロサービスに分割しようという開発プロジェクトが立ち上げる。
実際これも順番としては正しい。
一方で、マイクロサービス化で実現したことは
「モノリスな環境によってドメインの依存関係がごちゃごちゃになって技術的負債が溜まっていき機能追加もしずらく、さらにリリースするにも他チームとの調整が必要で全然リリースできない。
なので、マイクロサービスによってドメインごとにプロセスを独立させて、小さいサービス単位でリリース可能にすることでイテレーティブな事業改善を実現する」
少し、乱暴だが雑に書くとこんな感じだと思う。
本当に得たいもの
マイクロサービスアーキテクチャで本当に得たいインクリメント（成果物）は、マイクロサービス化の先にある、イテレーティブさである。マイクロサービス化は、そのための手段であって目的ではない。コンウェイの法則が有名だが、マイクロサービスアーキテクチャによって得られる一番大きいものは、最適化された組織・人である側面が大きい。
結局、プロダクト開発をするのは「人」なので、マイクロサービス化された環境下で、開発者がどう動けるべきかを考えてなければならない。
実際、マイクロサービス化しただけでは、開発速度は速くならない。（ことが多い）きちんとマイクロサービス化の後に、開発組織のチームがどういった開発プロセスで動くべきかまでを考えていかなければ、マイクロサービスの効用は得られない。
つまり、マイクロサービス戦略は「マイクロサービス とアジャイル型の組織」のアーキテクチャと組織戦略をセットで考えていかないとアウトカムが得られない。
マイクロサービス化したあとに本当に効果があったかは、そのあとにそのアーキテクチャの上で開発する組織に委ねられています。
マイクロサービスに適したスモールチームの形
では、マイクロサービス化の効果を一番得られる組織体制については、ある程度答えは出てきていて、マイクロサービスで分解されたドメインごとにチームがあることが望ましく、その最大規模はAmazonのTwo Pizza Team（チーム全体に2つのピザを提供できる）の概念になります。
そして、Two Pizza Team単位でチームを分けたあと、そのチームの中ではアジャイル型の開発で行うことが望ましいです。
せっかくマイクロサービス化によって小さいサービス単位で小さいチームで小さくデプロイが可能になったにも関わらず、ウォーターフォール型の開発でやっていては、マイクロサービスの恩恵は受けられません。そして、アジャイル型の開発も奥が深いのでしっかりと戦略立てて考えていく必要がります。
このようにマイクロサービス戦略と呼ばれるものは、
- ソフトウェアアーキテクチャによってシステムのマイクロサービス化
- それによってドメイン・サービスごとに小さいチームで小さい粒度でリリースできるようになる
- そして、小さいチームの中でアジャイル型の開発によってイテレーティブな改善を回せる。
といった形で、in/outの意識しながら取り組んで行かなければ正しいアウトカムは生まれません。
逆コンウェイの法則
そういった意味だと、逆コンウェイの法則の気持ちはわかる。ゴールを人がマイクロサービス化によってどう動くかにするならば、はじめから組織がどういった構造で開発するべきかを考え最適解を出した上で、システムがどうあるべきかを考えるのは、合理的である。
「よりイテレーティブな開発体制 → それを実現するためのアーキテクチャ」という思考の流れになるのはわかります。
ただ現実的に見たときに、システムが先にあって、既にそこには人もいるため、逆コンウェイの法則の考え方に簡単に当てはめることは難しいというのはわかりますが、ぜひ実践してみると良いです。
マーティン・ファウラー
ここに関しては、実はマイクロサービスを広めたとされているマーティン・ファウラーの良い記事がある。詳しくは記事を読むとよく理解できます。
ちなみにマーティン・ファウラーは、アジャイル界隈で超有名人である。
簡単に紹介していきます。
まずはモノリスとマイクロサービスの概要について。モノリスはイメージとして1つのサーバーに色々なドメイン、サービスが単一ユニットとして入っている（FE,BE,INF）。これをドメインごとにサーバーを分けながら運用していきましょう。これの問題のひとつとして、何か小さい修正をデリバリーしたいときに全体のアプリケーションをデプロイしなければいけないことである。時間とともに負債が溜まっていくとこれがかなり障害の起因になることが多い。
一方、マイクロサービスはキチンと単一ユニットごとにサーバーをわけてメンテナンスしていきましょうということです。
マイクロサービス化への後押し
一方、少し前の時代でなぜサーバーを一緒にしていたかについて、実はサーバーコストの問題がありました。昔はサーバー自体が高価だったため、ドメインごとにサーバーを分割したり、DBを分割するといったことはコスト的に難しかったのでは？と考察しています。
それが最近では、AWSを筆頭にクラウド環境が整い最近ではコンテナ技術の発展によって、かなりマイクロサービスがしやすくなった背景もあるでしょう。
以上です。
