emahiro/b.log

日々の勉強の記録とか育児の記録とか。

MicroServices本3兄弟を読んで考えたこと

平成最後のエントリです。(ギリギリ間に合った...)
10連休中の目標であった『進化的アーキテクチャ』を読み切ることができたので備忘録を残します。

※ 僕は別に設計について明るいわけでもマイクロサービスについて明るいわけでもありません。

サマリ

  • 『マクロサービスアーキテクチャ』、『プロダクションレディマイクロサービス』、『進化的アーキテクチャ』のマイクロサービスアーキテクチャ本3兄弟(僕が勝手にそう呼んでるだけです。)を読み終えました。
  • 拡大するフェーズのマイクロサービス化を終えて、運用人数が限られて行く中でのマイクロサービスをどう運用するのかに最近の個人的な関心があります。

雑感

下記三冊を2年がかりくらいでようやく読み終えました。

そこで考えたことをまとめてみます。 マイクロサービスアーキテクチャって昨今、様々な企業で採用されるケースがとても増えてきてると思うんですよ。
特にモノリスで作られたサービスを分割する、という文脈でのマイクロサービスを採用するケースをよく目にするようになってきました。(個人の観測範囲の話です。)

僕も業務でマイクロサービスアーキテクチャで作られたサービスの運用に関わっています。
ただ、運用をする中で最近、成熟したプロダクトでマイクロサービスアーキテクチャを採用してる際にどう運用していくべきなのか、ということを考えてます。

というのも、組織や企業が拡大するフェーズにおいてマイクロサービスを採用するのは、マイクロサービス本に書かれてる通り嬉しいことが多いと思います。
その一方で、サービスとして成熟してしまって、自動化などもありつつ、開発・運用する人数が限られていく(減っていく)にも関わらず、マイクロサービスの数は変わらず、エンジニア1人が見るべきサービスの守備範囲(ドメインの守備範囲と言ってもいいかもしれません)が広がっていって負荷が上昇していく可能性がある場合に、どう安定的にサービスを運用していくのか、ということに個人的に興味があります。
サービスを拡大する中で、マイクロサービス化して、疎結合で、技術スタックも柔軟に、デプロイ頻度も増やして、プロダクトの改善イテレーションを高速に回していく、というのはプロダクトと組織が拡大する前提があってこそでは?と最近考えるようになりました。プロダクトが現状維持、開発メンバーの工数削減傾向というフェーズにある場合はどうするのか、まだその実践的な活きた情報は多くありません。

先を見据えながら、開発サイドがつらくならない程度でマイクロサービスを少しずつ減らしていく(統合していく)方向もあるでしょうし、さらなる自動化もあるでしょう。(あんまり積極的ではないですけど)ドキュメンテーションで解決できることもあるかなと妄想してます。

マイクロサービスは事実として採用されるケースが増えてきてますが、ある時点で、ナノサービスではない粒度で、適切な粒度に切られていたマイクロサービス達は、プロダクトそのものが成熟し、本当の意味での運用フェーズに入ったときにどういう手法をとるのがベターなのか、その実践的なプラクティスをどんどん知りたいなと思っています。

平成最後の雑エントリ終わり。令和でもアウトプットの継続頑張るぞ。