Microservicesとは何か？

「神」がいない場合の解決策である。以上。
deeeet.com
滅多にこういうことは書かないのだが、たまにはいいか。
これを読んでみんな同じことで悩むんだなあ、と思った。

まず、Microservicesは銀の弾丸ではない、ということは大体の人は理解していると思うのだが、実感を持っている人は意外と少ないんじゃないか。
基本的に、殆どのServiceはMonolithicで十分である、という前提に立った後に、どうしてもそれでは解決できないからMicroservicesを選択する、というレベルで構わないと思う。そうじゃないとこういう話が出てくる。
tech.nikkeibp.co.jp
テスト駆動開発もMicroservicesも問題の本質ではないが、ある意味的を射ている。最初から「綺麗」にしようと思うのは間違いである。ほぼ10割と言ってもいいが、スタートアップには不要な概念であろう。Microservicesを真に導入すべきは巨大な基幹系システムである。本来はそここそに導入を考えなければならない。
今時のシステムについては、作りっぱなしで終わりということはなく追加開発は避けられないが、開発箇所を見極める必要が出てくる。巨大なMonolithicシステムの場合は、業務もインフラも方式もその他諸々全て把握している「神」が必要である。そうではないと正しく見極めるのが難しい。
しかし、人間なのだから、そんなことは不可能である、という前提に立って、初めてMicroservicesの必要性がわかるのである。
とはいえ、ここに書いてある通り、アーキテクチャの設計に置いて最初に責務の分担を決定するのは非常に難しい。後々、特定のMicroserviceがどのように発展していくのか、完璧ではなくてもある程度見極めが出来ないといけない。そうじゃないとあっという間に密結合になり、「分散Monolith」になってしまう。
また、追加開発の際に、責務を分離出来なくてはならない場合を当然想定する必要がある。大多数のEngineer及び決定権者は、ServiceComponentが分離していくことに極めて否定的である。これはオンプレミスはサーバ調達も含まれるため、本当に厳しく、このコストを抑えるためにもクラウドの方がMicroservicesとは親和性が高い、が、Serviceの分割はある程度分散Monolithの負の要素を理解している人の割合がいないと難しい。インフラ構築が何れにしても必要であるし、既に存在するService内で作るのと比べると既存踏襲が出来なくなるからである。
上記のようなことを正しく理解して、Microservicesでシステムを構築するとしよう。
それでもまだ課題がある。

ObservabilityやMonitoring，セキュリティや認証・認可，CI/CDといった直接ビジネス的な価値を出さないCross-cutting concernには統一的な方法があるべきである．そしてこれらはそれぞれの開発チームではなく専用の基盤チームが取り組むべきである．

これは本当にその通りだが、このチームは単純にコストである。
誰がこのコストを払う？
受託型開発でこのコストを理解してもらうのはとてもとても難しいが、内製でもそれほど簡単ではないだろう。要するにビジネス的な価値を生むチームではないのだからコストセンターと言われても止む無しである。誰かの上前をピンハネして生きていかなければならないのであるが、その重要性は何らかの形で常に実証できなければならない。本質とは異なる、と言われるのはごもっともだが、理解してもらわないとチームが存続できなくなり、結果的に色々破綻する。しかしこの価値がわからない人に対して説明が必要なのだから、実際かなりの面倒な作業である。
それとともに、この「専用の基盤チーム」ができるEngineerは端的にいうとFull-Stack Engineerなのであろうが、そんなEngineerはそうそういない。詳細な業務仕様は知らなくても、最低限の業務知識と深い(インフラも含む)専門知識が必要である。CI/CDも出来なければならない。セキュリティ含めた非機能要件も実現できなくてはならない。勿論、Serviceを実現するためのFrameworkも知らなくてはならない。
周りを見渡してほしい。
いるかそんな人？
いてもいくらで雇えるのそれ？
また、最後に「ObservabilityやMonitoring」はコード的なソリューションだけではなく、インフラも含めた総合的な設計が必要である。勿論、構築にもコストがかかる。上記で書いてあるように、「サービスにまたがったPerformance問題を検出するためにDistributed tracingを整備し」ようとする必要がある。Service間のどこにTAT遅延が発生し問題が起きているのか監視できないと商用運用ではBlackBoxになるからである。例えば、JavaでいうとSpring-Cloud-Sleuthを入れて、ログのトレーシングを実現し、ZipkinServerで参照できるようにすれば良い。こんなことは誰もが思いつく。
だが、そのコストは誰が払う？
全体方式を全て揃える必要がある、というのは最初にやったとしても、サービスには直結しない。問題が起きない限りは役に立たない。導入しても運用コストは定常的に追加になる。
本当に重要性を説明できるかこれ？
トレーシングデータ収集そのものも巨大なシステムの場合難題なので、システム構築自体も一筋縄ではいかない。データ収集自体も商用トラブルになることだって普通にある。こういった一つ一つを地道にやっていく必要があるのである。
こうやって考えるとMicroservicesやらない方がいいんじゃない？どう？
というところまで考えて、Microservicesの導入は考えるべきだと思う。
往々にして思慮が浅すぎる。

あえて書かなかったこと

データの一貫性の担保。これはNoSQLでは解決しないので、RDBに頼らざるを得ない。Microservicesにおけるデータの保持の仕方については、これだけで論文が書けるほど難題である。