モノリスの分解において、マイクロサービスは必然ではない - QCon LondonにおけるSam Newman氏の講演より

フルスタック開発者のためのBallerina: バックエンドAPI開発ガイド この記事では、REST API開発のためのプログラミング言語"Ballerina"の直感的な構文について解説します。さらに、認証や承認、OpenAPIツール、可観測性、SQL/NoSQLクライアントライブラリなど、重要な言語機能についても論じます。記事を読み終えれば、Ballerinaが次のバックエンドAPI開発の有力な候補である理由がよく理解できるでしょう。

[teppeis]

「"最悪のモノリスである、分散モノリス(distributed monolith)"だ。分散モノリスは多数のサービスを持つが、すべてを同時にデプロイしなければならない」

[estragon]

“ほとんどの企業にとって、マイクロサービスよりもモジュラモノリスの方がうまくいくはずだ”ってのは同意

[sonots]

モノリスで進める場合もモジュールごとにDBを分けるモジュラーモノリスにしておけばマイクロサービス化しやすいと。なるほど、と思ったけど、必然性がないのに先のためという強い意志を持ち続けてやる人いるかな

[endok]

“運用環境へのデプロイとユーザへのリリースは同じではない"　この考え方は意識したいな。

[cl-gaku]

モジュラモノリスをきれいに保つのはマイクロサービスより辛そうなのが問題

[peketamin]

マイクロサービスを意識してモジュールや処理の境界を引いた上でモノリスになってると嬉しい気がする。

[tsuwatch]

今やってるけど、確かにモジュラモノリスやっとけば、マイクロサービス化するかとなってもまぁそんなに大変じゃない印象。もちろんDB分ける分けないとかで、大変さ変わるけど

[tkmkg8m]

“モジュール境界を意識して"大きな泥玉"を回避するには確固とした規律が必要だが、ほとんどの企業にとって、マイクロサービスよりもモジュラモノリスの方がうまくいくはずだ”

[boomerangj]

将来の負荷を考えてこことここは同一DB前提にしない(JOINしない、同一トランザクションを期待する処理を書かない)というのは昔からあるテクニックな気がする。

[suzx]

#メモ保存

[ngmy]

当たり前のことしか言ってないし考えればわかることなんだけど、みんな新しくてカッコいいワードが好きだからな。

[mztnex]

“ほとんどのスタートアップにとって、マイクロサービスはよい選択ではない”

[Nyoho]

“Newman氏が声を大にして警告するのが、"最悪のモノリスである、分散モノリス(distributed monolith)"だ。”

[RYoMa_0923]

進化的アーキテクチャの中で述べられてた内容がもう少しわかりやすく解説されてる感

[kkobayashi]

確かにデータをきれいに分けてさえおけばモノリシックかマイクロかは後からどうにでもなりそう

[t-wada]

"テクノロジではなく結果を重視する" "デプロイの独立性が目標であるという意識を常に持つ" "ほとんどの企業にとって、マイクロサービスよりもモジュラモノリスの方がうまくいく" "最悪は分散モノリス" すばらしい講演

[ten-gallon-Mouse]

“分散モノリス”

[DeikunChar]

確かに。データ層の分離は難しい。モノリス開発メインのSEには，そもそもデータストアを分割するという発想が希薄（私だけかもしれないですが）RDBMSこそが主役だと教えられてきた

[kno]

“複数のデータベースを使用したモジュラモノリスを推奨する。奇妙に思えるかも知れないが、最終的にモノリスをマイクロサービスに分割することが可能なのは分かっている。本当に大変なのはデータ層の分割なのだ”

[Chisei]

見たことあるやつだ！ “分散モノリスは多数のサービスを持つが、すべてを同時にデプロイしなければならないため、何かを行うにはチーム間の調整が数多く必要となる。”

[yujiorama]

"確固とした規律が必要だが、ほとんどの企業にとって、マイクロサービスよりもモジュラモノリスの方がうまくいくはずだ。その点でモジュラモノリスは、あまりにも過小評価されていると言える。"

[ohbarye]

“最悪のモノリスである、分散モノリス(distributed monolith)だ。分散モノリスは多数のサービスを持つが、すべてを同時にデプロイしなければならないため、何かを行うにはチーム間の調整が数多く必要”

[ikeike443]

分散モノリス、よく見るね