Self Contained Systemsの紹介

Posted on 12/24/2019

Microservicesは面白い。ほとんどすべて必要なことはそこに書かれているように思う（言い過ぎ）。https://martinfowler.com/articles/microservices.html 訳 http://kimitok.hateblo.jp/entry/2014/11/09/211820

"適切に" 分離し、"適切に" それらの間の依存さえ解決出来れば、コンポーネントを個別で管理し運用し、進化させ続けることが出来る。開発チームは自分達の関心範囲が明確になり、集中しビジネスレベルで責任を持つことさえできる。

ただし、多分 "適切な" 人が読んだら、に限る。これは半分言葉だけの問題で、"マイクロ" と "サービス" が共に少しミスリーディングなせいか、現実問題どのように切ったらいいかがよくわからないからだ。

Self Contained Systems は正直単なる Microservices の具体的解釈の一つ（ほぼAlias）に過ぎないと思うが、明示的に1レイヤー増やしていること（Microservicesでは暗黙的なだけ）で、事業の進め方や組織ポリシーを反映させやすく、扱いやすい気がしている。その割に知られていない気がしているのでご紹介。

Self Contained Systems

詳しくは下記を参照。
https://speakerdeck.com/rstrangh/self-contained-systems-1 だいたい書いてあるスライド
https://scs-architecture.org 本丸のサイト
https://www.infoq.com/articles/scs-microservices-done-right/ infoqの記事

ざっくり言えば、Microservice を複数束ねたもの（+ 必要であればFront/Api）を SCS: Self Contained System と呼び、それらをTeamにAssignしよう、というもの。Microfrontends に親しい人にはそちらの解釈に近いように感じるかもしれない。Frontも含まれないものも表現できる意味で少し適用しやすい。（front側はurlベースでの協調がメイン。基本url切っちゃおうということ）

イメージ（別にモノレポの制約とかはない）

repo
- system1 = product1 (Teamにassign）
  - service1.1
  - service1.2
  - ...
  - api
- system2
  - service2.1
  - service2.2
  - ...
  - front
- ...

System間は通常のMicorservicesと同様に、単純なRestやEvent BusをVersion管理して依存を切る。
System内はコードを直接依存させても良いし、versionを意識せず開発し、Deployはsystemの粒度で同期して行われることを想定する。（Canaryを使いたいケースでは使えば良い）versionを意識した開発は気が滅入る。できうる限り考慮したくない。
ある意味、SCSsの一つのSystemは、多少構造化されている小さいMonolith だと言える。Monolithの良さは凝集性に、デメリットはスケール性にあるが、一つのTeamを小さく=一つのSystemを小さくする制約が付けられれば、良い点だけが享受できる。

Systemそのものの考え方はそれで良いとして、ここでの最大の関心は、Systemの境界、ひいてはTeamの境界をどう引くか、というところにある。

Teamをどのように機能させたいかと、Systemの切り方

Teamの境界をどう考えるか、は Teamをどのように機能させたいか と関連している。これは多くの場合、事業構造/組織ポリシーそのものと関連している。（つまり、それぞれの企業ごとに別の解がある）（注1）

例えば、Plaidの場合は（少し特殊なところかもしれないが、）事業のベースを抽象度が少し高い設計をする代わりに、その具現化のために、メンバーの発想力とモチベーションを生かすことを想定している。また間違いによるエラーの許容度も高く設計していて、大きく、素早く開発サイクルを回すことをちょっとした競合差分として設定している。そのため、Teamに対してサービスレベルでの意識を持ってもらう構造になること、できうる限り大きい幅広の範囲で裁量がわたるような構造にすることが、組織ポリシーとしても重要で、それは事業構造から来ている。

具体的には、Designer/Business/Developer が1Teamで動けるようにして、Featureよりもなるべく大きい Productを持つようにし（Productと呼ばないケースも多いが）、アーキテクト設計から、クライアント提供方針、（必要であれば）価格/コスト、マーケティングまでをある程度裁量を持たせる粒度で切る必要がある。
その時、1Productのサイズは、その1Team（Plaidの場合TeamのサイズはDeveloperのみでは2~5人程度を目安）が1サイクル（Plaidの場合2~3ヶ月）でまわせるサイズを考える。これは提供できるものの制約にもなるが、それがそのままSystemの単位になる。

これはPlaidにおけるSystemの切り方の一つの例（注2）だが、もちろん他にも色々考えられる。

例えば、安定性/障害耐性等が高まることが事業構造上競争優位になるような場合、なるべく小さく、（SCSsのように一気通貫性を高めAgilityを上げるのではなく）職能によるレイヤーで切って固く進めた方が良いかもしれない。

結局次のような質問に答えつつ、Systemの粒度をまず決める必要がある。

チームのサイズをどのくらいが適切と考えるか
事業構造とTeamの機能のさせ方をどう考えるか
事業フェーズをどのように考えるか

注1: 個人的にはこれも 逆 と書くのはミスリーディングだな、という気がしているけれど、business architecture → org structure = system architecture を目指す逆コンウェイ戦略といいたいことは多分同じ。

'Inverse Conway Maneuver' recommends evolving your team and organizational structure to promote your desired architecture. Ideally your technology architecture will display isomorphism with your business architecture https://www.thoughtworks.com/radar/techniques/inverse-conway-maneuver

注2:
もちろん、System Architecture寄り (DDDとか) の切り方に引っ張られた方が良い場合もある。というか結構ある。そこら辺は、、柔軟に判断するw

終わり

結局systemっていう言葉を導入しただけなので、なんてこともないが、microserviceそのものを使っていると多分悩んだであろうところが、ある程度社内で悩まずに進めている。正直結構うまくハマっている好例だと思うので、誰かの参考になれば。

CI/CD戦略とかk8sの使い方とか、モノレポとかversion管理とか、そこの具体が当然また面白いところではあるし、実際に進めているところのHard thingsとかがまた面白いところだと思うが、そこは基盤チームの誰かが書くと思う & 弊社に来てくれればいくらでも説明しますので、気軽に遊びに来てくれれば良いんじゃないかと思います。