マイクロサービスを蝕む負の力学

マイクロサービスを蝕む負の力学 マイクロサービスアーキテクチャでは、全体を分割し小さいチームとサービスにすることでチームの責任範囲を小さくし、 限られた範囲内で独自にPDCAを回すことで人数の拡大に対しても生産性を落とさないのが利点の一つになります。 これにより個々のマイクロサービスの関心事は小さく保たれるため、構成はシンプルになり実装しやすくなります。 一方でサービス間の依存関係が複雑になったり、通信量コストがとても増えるといったサービス間をまたいだところへの問題、 データの整合性や分散コンピューティングの落とし穴といった分散システム特有の問題、通信先のマイクロサービスの信頼性、安定性といった問題など、マイクロサービスアーキテクチャ全体としての複雑性は上がります。 そして、こういった複雑性や一部のマイクロサービスの不安定さは、そのマイクロサービスを構成する全員に悪影響を与えます。 つまり

[muramurasan]

組織の成熟度に合わせて選択すべきと。基盤チームの役割も出てきてわかりやすい。確かにマイクロサービスはアプリエンジニアではない人間が業務ロジックと切り分けて原因解析できないと辛そう。

[yukisno]

マイクロサービスやるときには責任共有モデルを明確にしないといけない理由が説明されている(と理解した)

[sh19910711]

"チームを超えた領域に複雑性が寄せられていき、かつそういった領域の複雑性は個々のチームにとっては解決しづらい力学が働くため放置されやすくなります"

[sasasin_net]

チームの境界とマイクロサービスの境界を揃えたら、チーム間の問題には手を出しにくくなる、優先度が下がるのは、完全にそのとおりだよなあ

[endok]

マイクロサービスの困難な部分が解説されてる。

[wwolf]

こういう問題に対応するべくSREという役割が自然発生的に生まれたと言える

[tune]

組織の実力とマイクロサービスの粒度はバランスを取らないとダメというお話と理解しました。

[tomiyanx]

OKRがちゃんとツリー状になっていなくて他チームがどうでも良くなってしまうのではないか？？？

[qsona]

内容自体は問題に向き合ってきた人の意見でとても重みがあると思う。僕の記事が "基盤エンジニア側からみた理想論を話すポジショントーク" と紹介されていたのは、僕の意図とは正反対で残念。

[ota42y]

おそらくマイクロサービスに限らずこういった力学はあるんだろうけど、マイクロサービスだとより強くなるのでは…って感じ。ただ組織によってまた力学の強さが違うので…うーん