マイクロサービスに関するメモ
マイクロサービスの勉強中。「モノリスからマイクロサービスへ」の2章までのメモ。
マイクロサービスとは
マイクロサービスとは、ビジネスドメインに基づいてモデル化された、独立してデプロイ可能なサービス。
「ビジネスドメインに基づいてモデル化された」というところも大事らしく、今までは、システムがいわゆる3層構造（フロント、バックエンド、データベース）の分け方をしていたのを、ビジネスが受注生産品の販売であれば、「受注」「生産」「販売」「製品管理」「発送」など、ビジネス自体に基づいて分けられることになるらしい。 当然、組織もビジネスに合わせて分けることになり、ＤＢなども複数持つことになるらしい。DevOpsとかの文脈も含むみたい。
利点
- 各チームが仕事をコントロールしやすくする（仕事の範囲を明確に線引きできる）
- 管理範囲が横断的でなくなるため、仕事をコントロールしやすくなる。（三層構造だと、各チームの仕事が他のチームに影響を及ぼしやすい）
- 市場投入までの時間の削減
- 小さくデプロイできるため。
- 負荷に対するスケーリング
- 小さいサービスが複数あるため、サービスに応じてスケーリングできる。
- 堅牢性の改善
- 各サービスが独立しているため、トラブル時の影響範囲を狭められる。
- 同時に作業可能な開発者の数の増加
- サービスを分けることで、並行作業を容易になる。
- 新しい技術を受け入れ
- サービスを分けることで、サービスにあった技術を選択できる。
マイクロサービスがうまく機能しないと想定される場合
- ビジネスドメインがはっきりしていないとき
- マイクロサービスは、ビジネスドメインでわけるため。
- スタートアップなど、マイクロサービスの利点よりも他に優先するべきものが多い場合
- スタートアップはそもそもビジネスがうまくいくかわからんので、ビジネスを試すことを優先すべき
- 顧客の環境にインストールして管理するソフトウェアなど。
- Kubernatesをいれろというわけにいかない。
- 最もな理由を持たない場合
- なんとなくマイクロサービスにしようっていうのはやめようねってはなし。おおそうだけど。
感想
なんというか、利点はわかるけど、導入は難しそうだなってのも思う。本で書かれている通り、一部の機能だけ切り出してやってみるとかがいいんだろうな。例えば、コードを書く人が6人くらいいれば、4人と2人に分けてサービス持つとかするといいかも。逆に、そもそも２人しかコードを書く人いなかったら、仕事増えるだけな気もする。
