平成最後のエントリです。(ギリギリ間に合った...)
10連休中の目標であった『進化的アーキテクチャ』を読み切ることができたので備忘録を残します。
※ 僕は別に設計について明るいわけでもマイクロサービスについて明るいわけでもありません。
サマリ
- 『マクロサービスアーキテクチャ』、『プロダクションレディマイクロサービス』、『進化的アーキテクチャ』のマイクロサービスアーキテクチャ本３兄弟（僕が勝手にそう呼んでるだけです。)を読み終えました。
- 拡大するフェーズのマイクロサービス化を終えて、運用人数が限られて行く中でのマイクロサービスをどう運用するのかに最近の個人的な関心があります。
雑感
下記三冊を2年がかりくらいでようやく読み終えました。
そこで考えたことをまとめてみます。
マイクロサービスアーキテクチャって昨今、様々な企業で採用されるケースがとても増えてきてると思うんですよ。
特にモノリスで作られたサービスを分割する、という文脈でのマイクロサービスを採用するケースをよく目にするようになってきました。（個人の観測範囲の話です。)
僕も業務でマイクロサービスアーキテクチャで作られたサービスの運用に関わっています。
ただ、運用をする中で最近、成熟したプロダクトでマイクロサービスアーキテクチャを採用してる際にどう運用していくべきなのか、ということを考えてます。
というのも、組織や企業が拡大するフェーズにおいてマイクロサービスを採用するのは、マイクロサービス本に書かれてる通り嬉しいことが多いと思います。
その一方で、サービスとして成熟してしまって、自動化などもありつつ、開発・運用する人数が限られていく（減っていく）にも関わらず、マイクロサービスの数は変わらず、エンジニア1人が見るべきサービスの守備範囲（ドメインの守備範囲と言ってもいいかもしれません）が広がっていって負荷が上昇していく可能性がある場合に、どう安定的にサービスを運用していくのか、ということに個人的に興味があります。
サービスを拡大する中で、マイクロサービス化して、疎結合で、技術スタックも柔軟に、デプロイ頻度も増やして、プロダクトの改善イテレーションを高速に回していく、というのはプロダクトと組織が拡大する前提があってこそでは？と最近考えるようになりました。プロダクトが現状維持、開発メンバーの工数削減傾向というフェーズにある場合はどうするのか、まだその実践的な活きた情報は多くありません。
先を見据えながら、開発サイドがつらくならない程度でマイクロサービスを少しずつ減らしていく（統合していく）方向もあるでしょうし、さらなる自動化もあるでしょう。（あんまり積極的ではないですけど）ドキュメンテーションで解決できることもあるかなと妄想してます。
マイクロサービスは事実として採用されるケースが増えてきてますが、ある時点で、ナノサービスではない粒度で、適切な粒度に切られていたマイクロサービス達は、プロダクトそのものが成熟し、本当の意味での運用フェーズに入ったときにどういう手法をとるのがベターなのか、その実践的なプラクティスをどんどん知りたいなと思っています。
平成最後の雑エントリ終わり。令和でもアウトプットの継続頑張るぞ。
