microservices
要件が定まっている場合に2週間ぐらいで作り治せるような規模らしい
各マイクロサービスごとに並行して・集中して開発することで、大規模で複雑なアプリケーションも迅速かつ頻繁にリリースできる
以下のようなところがマイクロサービスアーキテクチャの利点にマッチしていたため採用されました。
そもそも機能ごとに開発チームが別だった => 組織構成に合わせたサービス構成がマッチしていた
リリースに向けて短い期間で一気に開発する必要があった => 多人数の並行した開発で、小さなプロダクトに集中することでスピードが出せた
サービスによっては、社内の別サービスからも使われていた => 別サービスから使われる箇所をN予備校ドメインから切り離し1つのサービスとして開発した
N予備校では2016年のリリース当初から5年間、この構成を運用し続けてきました。
課題: 責務の分割へのハードル
責務の肥大化・複雑化は私たちのアジリティを低くする要因になってきています。
リリース後5年間は1つのチームですべてのマイクロサービスを見ています。どうしても広いマイクロサービスの知識が必要になるとアジリティが落ちてしまいます。
横断的問題を解くモチベが低くなる
マイクロサービスにおいては通信周りの重要性がとても高く、サービスメッシュやApache Kafkaといった様々なミドルウェアを入れて解決を図ろうとすることが多いです。 ですがその場合、それらを適切に設定・運用するためのリソースに加え、各サービスを管理しているチームに導入してもらうといった協調作業が必要になり、モノリシックに比べるとコストが大きくなります。 また、マイクロサービス全体に関わる問題解決は全体としては嬉しいですが、ある特定のサービスチームに対しての嬉しさは分散され小さくなるため、 特定のチームの目標に落とし込むのは難しく、チームとして解決に動くインセンティブが生まれにくいです。
マイクロサービスでは個々のサービスの複雑性は抑えられますが、 マイクロサービス全体の問題は難易度は上がり、かつリソースを割くインセンティブは下がってしまうため、 問題を放置する方向に強い力学が生まれます
Microservicesアーキテクチャに移行する最大の理由は「組織の拡大においても小さな自立独立したチームによる組織を編成し組織としてのパフォーマンスを最大化する」ことである（2000年初頭においてGoogleはComputer Scienceの問題を解決するために今でいうMicroservicesアーキテクチャへ移行したという話 What We Got Wrong: Lessons from the Birth of Microservicesがあるが現在ではこの理由でMicroservicesをやる理由は少ないと思う）． 採用の目安
規模は重要なファクターである
マイクロサービシズには分散（引用者注：分散システム）と非同期性があり、どちらも複雑さを助長する。本当は必要のないマイクロサービスに手を出したプロジェクトを、私はもう二つも見かけた。結果として機能開発の速度を著しく損ねていた。一枚板が良い犠牲的アーキテクチャになることは多い。後から徐々にコードを引きはがし、マイクロサービスにすればいい。 利用前に思っていたこと
サービスが小さいのでサービスの中のドメインの凝集度は上がるらしいが
各サービスを要求の変化に適した言語でかけるのはよさそう
トレードオフ：学習コスト、採用
全体をまたがるログ収集のつきあわせとかつらそう
全体の工数が見積もりやすいかもしれない？
サービスを作り続ける体制ができれば見積もりの精度は上がるはず
開発的な嬉しさ
作り直すときに不要な仕様を落とせる
作り直しの際にベストプラクティスを取り入れることができる
レガシーなものをずっと保守していくのは辛い
スキルの棚卸し
新しい人が来たときにクソデカドメインを理解しなくてもよいかも？