読書感想文: Istioがなぜマイクロサービスアーキテクチャをやめたのか

マイクロサービスアーキテクチャにした事例もあるけども、マイクロサービスアーキテクチャじゃなくした事例も目にするようになりました。

Istioはサービスメッシュとして使われるソフトウェアです。
最初Istioのコントロールプレーンの仕組みをマイクロサービスアーキテクチャを使って実現していましたが、弊害の方が強すぎてモノリスにしました、と言う話です。

CSDL | IEEE Computer Society

コントロールプレーンの仕組み

画像をサイトから引用させていただきます。
(a) がマイクロサービスアーキテクチャを採用していた時の構造、(b) がモノリスで実現した構造です。

引用した画像

それぞれが何をするものかはここでは割愛しますが、オリジナルのページには書いてありますのでご興味があればどうぞ。

そもそもなぜIstioをマイクロサービスアーキテクチャで実現したかと言うと以下です。

• 馴染みがあったから (Google出身の開発者が多かった)

• 各機能を疎結合にすることで運用をより楽にすることができると思ったから

Istioで見つかった「弊害」

明確に書かれているのがIstioを使うユーザーに対して複雑な状況になってしまったこと。

• Istioの各機能は基本的に単一の管理チームにより使われるため、マイクロサービスのメリットである独立したロールアウトや独立して拡張できるなどのメリットがあまり関係がなかった。

• マイクロサービスにすることでインストールや運用などの考慮事項やパラメータなどが増えて複雑になってしまった

• 結果エクスペリエンスが悪かった

こう言う弊害は予見できなかったのでしょうか。
おそらく難しかったと思います。

「自分たちの」運用課題と、Istioを利用する側の運用課題がごっちゃになってしまったなどで見えづらくなってしまったことも弊害が予見できなかった一因かと思います。
でもそれ以上に、Istioを使用するユーザーがどう言うチーム構成を立ち上げるのかを把握するなど、製品の将来的な利用シーンまで正確に予見することはおそらく難しいのでは。

記事にはSam Newmanのマイクロサービスにて実現をお勧めしない状況に照らし合わせてIstioを評価したものなどもあって非常に参考になります。