マイクロサービスアーキテクチャはなぜ最近になって注目されるのか～マイクロサービスは組織論の側面も持つ

「マイクロサービスアーキテクチャ」を読んだら、すごく面白かった。
ThoughtWorksの開発者が書いた本は、どれも随筆っぽく、個人的にはどれも面白い。
マイクロサービスに関するラフなメモ書き。

【参考】
akipiiさんのツイート: "「たぶんマイクロサービスは本当に組織論」という言葉がすごくイイ！ソフトウェア工学の理論で整理できないかな？マイクロにしすぎた結果がこれだよ！ #architecture #golang https://t.co/3w5pY6aedt"

Yoshihito Kuranukiさんのツイート: "プログラミング、それも優れたソフトウェア設計で学んできたことは、経営をする助けになっている。組織とソフトウェアの構造は似るという「コンウェイの法則」を逆に考えれば、良いソフトウェアの設計を応用すれば、良い組織の設計ができる、とも考えられる。そもそも会社とはソフトウェアなのだから。"

akipiiさんのツイート: "逆コンウェイの法則。組織構造はアーキテクチャに合わせる。経営者の観点では、組織は経営戦略に従うのだから、アーキテクチャの下で組織構造を従わせる感覚は普通なのかもしれない。 https://t.co/8FYPiEDyjh"

マイクロサービスアーキテクチャとは何か - arclamp

マイクロサービスアーキテクチャにおけるAPIコールの仕方とHTMLレンダリング - Qiita

マイクロサービスを設計するときはエンジニアの発想を捨てる

今話題のマイクロサービス・アーキテクチャについて、本格的に実践中のビズリーチさんに聞いてみた！ | HTML5Experts.jp

マイクロサービスの実際: 第 1 回 マイクロサービス入門

逆コンウェイ戦略のメモ～望ましいアーキテクチャを促進するためにチームと組織構造を進化させる: プログラマの思索

【1】マイクロサービスアーキテクチャはなぜ今頃、流行しているのだろうか？
@sakaba37さんにに、「マイクロサービスアーキテクチャ」の本が面白かったんですよ、とちょっと興奮気味に話したら、怪訝な顔をされた。

マイクロサービスというアーキテクチャの発想は既に知られているし、分割するのは当たり前だ。
でも、どの粒度まで分割すべきなのか、分からない。
従来のソフトウェアの分割統治の設計手法と何が違うのか？

マイクロサービスで、仮想環境や継続的デリバリーや自動テストの最新技術を取り入れて、早くリリースできるのは理解できるが、それら技術を使えば早くリリースできるのは他の設計でも同じ。
組織構造とマイクロサービスが密接に関連していて、マイクロサービス単位のチームを構成すべき、という観点も、従来のConwayの法則からして、当たり前ではないか、と。

確かに、そうだな、と思う。
では、従来の設計思想と何が違うのだろうか？

【2】マイクロサービスが今頃になって注目される理由は、「外部システム連携」「プラットフォーム」「組織構造」の3つの観点があるから、と思う。

【2-1】僕がマイクロサービスに興味を持つのは、社内の数多くの業務システムを開発したり保守していると、「外部システム連携の設計手法の一つ」としてマイクロサービスアーキテクチャが必要になってくる場面が多くなっているからだ。
以前は、外部システム連携と言えば、無数のバッチをフローでまとめたバッチ処理が主流で、ジョブフローのどこかが止まればバッチ処理が止まってしまう。
バッチ処理で設計すると、リランや運用フォローで必ず手作業の運用手順が入り込んで、更に作業が複雑になる。

そこで、外部システム連携をマイクロサービスでオンラインでリアルタイムにやり取りできるようにすれば、運用もかなり楽になる。
機能追加もやりやすい側面がある。

従来はバッチ処理でしか設計できない場面が多かったが、最近はサーバーの高性能化やクラウドのおかげで、マイクロサービスで作りやすくなった経緯もあるだろう。

【2-2】外部システム連携をマイクロサービスで作るようになると、元のシステムは、外部システムと連携しやすいようなAPIを多数作りこむ必要が出てくる。
そのAPIがマイクロサービスに相当するように作る場面が多い。

すると、元のシステムは「プラットフォーム化」してくる。
つまり、外部のシステムから見れば、マイクロサービスのAPIを提供するシステムは、重要なデータが蓄積されたデータ基盤である。
そのデータを取得したいために、マイクロサービスというAPIが必要になってくる。
その外部接続用APIは、リアルタイムに取得できるI/Fが良い。
たとえば、REST APIがその一つだろう。

そんな事を思うと、Redmineは一つのプラットフォームであるように思えてくる。
なぜなら、Redmineはソフトウェア開発案件の作業情報が蓄積された一つの情報系システムであり、そのデータはREST APIで好きなように外部システムから取得できるからだ。
たぶん、Redmineが日本で普及した理由の一つは、データが蓄積されるほど有用なシステムであり、そのデータをREST APIでいつでも取得できて、外部システム内でデータを加工できる点にあると思う。

【2-3】システム機能をマイクロサービスで設計してみると、システムは複数のサブシステム(マイクロサービス)に分割され、それらサブシステムが連携して一つのシステムとなるような設計になってくる。
つまり、システム構造はより複雑になる。
すると、それぞれのサブシステム毎に開発チームが作られて、システム単位の並行開発になってくる。

そういう側面を見ると、マイクロサービスごとに開発チームという組織構造が現れる。
Conwayの法則は「アーキテクチャは組織構造に従う」であるが、マイクロサービスの設計思想が浸透すると、「アーキテクチャ(マイクロサービス)に合わせて組織(開発チーム)が従う」という逆コンウェイ戦略の思想が自然に出てくる。
この部分がすごく面白いと個人的に思っている。

なぜなら、開発者主導で組織構造が変化する場面に遭遇することができて面白いからだ。
普通は、経営者が自分の戦略に基づいて、トップダウンで組織構造を定める。
開発者は、その組織構造に従って作業するしか無い。

でも、マイクロサービスアーキテクチャでは、マイクロサービスに合わせたチーム構成が自然であり、そのような組織構造を作ることが推奨される雰囲気になる。
マイクロにしすぎた結果がこれだよ！の中で「たぶんマイクロサービスは本当に組織論」という言葉が出てくるけれど、おそらくそんな感触なのだろうと推測する。

【2-4】アーキテクチャと組織の密接な関係は、知っている人は当たり前の概念みたいだが、僕にとっては、そんなに当たり前の概念でもない。
現代の日本のソフトウェア工学、ソフトウェアプロセスの問題の真因を探ると、結局、組織論の問題になってしまう場合が多いのではないか、と思ったりする。

組織構造は一度定めると、組織慣性が働いて、組織内部のメンバーはもちろん、経営者ですらも組織を変更できなくなる場合が多い。
たとえば、官僚制組織が最たる例だ。
つまり、組織構造は一旦作られると、それを変更するのは難しく、人々は組織に嫌々ながら従わざるをえない。

【2-5】一方、作られたシステムの設計に従って作られたチームがどんどん肥大化して大規模組織となり、その組織設計が経営戦略の障害になる事例もある。

たとえば、「マイクロサービスアーキテクチャ」の本では、こんな話があった。

大規模インターネットが出現する前の時代に、Webサイトを持つ大手印刷会社はCMSを作った。
そのCMSは、料金を支払った第三者がコンテンツを入力するシステム、そのデータを加工する中央システム、一般大衆が閲覧できるフロントシステムの3つに分割されていた。
当時は、入力・中核・出力の3つのシステムと密接に連携した組織が、小規模ではあるが、部門として作られた。

当初は、オンデマンドのビジネスは小さかったが、じきにCMSを中核としたオンデマンドのビジネスが従来の印刷事業を上回るようになった。
すると、組織構造が事業の成長に合わなくなってきて、不都合になってきたのだ。

つまり、事業のIT側の3つの部門はそれぞれ、入力・中核・出力の3つのシステムに一致しており、それぞれの部門で別々のデリバリーチームがあった。
この組織構造がシステム設計よりも前に存在しておらず、実際にシステムを中心に組織が形成されていった、ということを誰も自覚していなかったのだ。

しかし、組織構造をすぐに変えることは難しい。
上記の事例で組織変革が難しい理由は、組織の元になる入力・中核・出力の3つのシステムを変えなければ、組織をいくらいじっても、逆に業務に支障が生じてしまうためだ。

一般には、組織変革が失敗する理由は、組織慣性が働くために、経営者ですらも組織構造やそれに基づく組織文化を変えることが出来ないからだ。

上記の事例では、システム設計の欠点に気付き、組織構造を変更するためにシステム移行を行なっているらしい。
しかもその移行プロセスは、何年も経ったのに、今も進行中らしい。

そんな話を読むと、頑固な組織構造や組織文化の背後には、時流に合わないシステム設計がその根本原因である場合もある、ということに気づく。

【3】マイクロサービスが今頃になって出てきたのは、上記だけでなく、技術がようやく揃ってきたこともあるのだろうと思う。
開発環境や本番環境の仮想化がやりやすくなり、AWSのようなクラウドにすぐに乗せることができて、コミットできれば即リリースできるような仕組みが整ってきた。
つまり、継続的インテグレーション、継続的デプロイ、継続的デリバリーのような技術とマイクロサービスはすごく親和性が高い。

そのおかげで、マイクロサービスアーキテクチャというボトムアップの設計手法が注目されるようになったのだろう。

【4】でも、マイクロサービスが全ての問題を解決するようなバラ色の手法ではない。
たまたま設計してみたら、マイクロサービスという共通の設計手法が作れるのでは、という感じだ。

「マイクロサービスアーキテクチャ」の本でも、最初からマイクロサービスで分割する設計をするよりも、ある程度システムの機能が揃ってきた後に、マイクロサービスに分割するようにリファクタリングすることを勧めている。
つまり、最初からマイクロサービスで設計できる場面はそう多くないらしい。
実際、たとえば、Redmineもある程度チケット管理の機能が揃ってきた後で、REST APIが次々に作られて公開された歴史がある。
最初からマイクロサービスで作ろう、という発想はなかったのだろう。

一方、SOAはトップダウンの設計手法であり、最初から外部接続できるようなAPI設計をすべき、という思想が貫かれている。
SOAとマイクロサービスは共通点もあるが、相違点も多い。

個人的には、マイクロサービスを再利用可能なコンポーネントとみなして、デザインパターンのような設計パターン集が作れるといいなあ、と思っている。
Webシステム、Webサービスのより良い設計手法は発展途上であり、その手法はぐちゃぐちゃで整理されていないからだ。

【5】個人的には下記2つの資料がすごく分かりやすい。

マイクロにしすぎた結果がこれだよ！ from mosa siru

マイクロサービスアーキテクチャとは何か from Yusuke SUZUKI