千のマイクロサービスによる死
(renegadeotter.com)- マイクロサービスをデフォルトのように導入する文化は、実際のスケール問題ではなく存在しない問題を解くために、コストと複雑さを増やしてきたという批判
- JavaScript/Node.js エコシステムの閉鎖性、FAANG流の慣行、潤沢なベンチャー資金が重なり、スタートアップまでもが web-scale アーキテクチャをまねる空気が生まれた
- Docker や Kubernetes があっても、開発、デバッグ、デプロイ、テスト、レジリエンス確保といった分散システムの難しさは消えない
- Dropbox、Twitter、Netflix、Facebook、GitHub、Instagram、Shopify、StackOverflow、WhatsApp などは、モノリシックなコードベースで始まったか、今も中核にモノリスを置いている
- ほとんどの会社は本当に分散システムが必要な規模には到達しないため、明確に分離・スケールさせるべき負荷があるときだけサービスとして切り出すのが現実的
複雑さを崇拝する文化
- ユーザーの誕生日を1つ取得するために複雑なマイクロサービスの迷路を説明しようとして失敗する風刺は、現在の技術文化における過剰設計を狙ったもの
- 目の前の課題を解く代わりに、存在しない問題を解決するために資金を燃やす方向へ目的が変わってしまったことが問題
- JavaScript と Node.js への批判は特定技術だけの問題ではなく、すでに学んだ教訓を再び学ばせる閉鎖的なソフトウェアエコシステムの危険とつながっている
- 業界は過去にも CORBA や SOAP のような複雑さの壁にぶつかったあと、方向転換した経験がある
マイクロサービス流行を生んだ条件
- ブラウザ向け JavaScript を使っていた開発者たちが「full-stack」を自称してサーバー開発と非同期コードへ入っていき、初期の Node は個人の学習プロジェクトに近く、初期の JavaScript はサーバー開発には問題の多い選択肢だった
- Node の外の世界が事実上存在しないかのように受け止められ、Node のやり方だけが唯一の方法だという独断的な思考が生まれた
- その後、FAANG 出身者がスタートアップに入り、「Google でやっていたやり方」を文脈や規模に関係なく正解のように広めた
- 専用の
User Preferences Serviceがなければスケールしない、といった圧力が代表例
- 専用の
- ベンチャー資金が潤沢だった時期には、売上よりも投資家に爆発的成長を見せることが重要になり、会社は高額なソフトウェアエンジニアを急速に採用して「何か」をさせた
分散システムはいまも難しい
- マイクロサービスは「スケーラブルなソフトウェアを書く新しい方法」のように包装されたが、本質的には昔から存在する分散システムの問題と接している
- かつて分散システムは難しく危険な道具と見なされ、とりわけ厄介な問題のための最後の手段に近かった
- 分散システムでは、次の作業がすべてより難しく、より時間がかかる
- 開発
- デバッグ
- デプロイ
- テスト
- レジリエンスの確保
- マイクロサービスベースの開発には標準ツールや共通フレームワークがなく、2020年代でも分散システムの作業は少し楽になっただけ
- Docker と Kubernetes は、分散構成の本質的な複雑さを魔法のように取り除いてはくれない
シンプルさがより良い結果を生んだ事例
- 5年間のスタートアップコード監査からの学びは、うまくいっているスタートアップほど、ほとんど厚かましいほどに Keep It Simple のアプローチを取っていたとまとめている
- 早すぎるマイクロサービス移行、分散コンピューティングに依存したアーキテクチャ、メッセージング中心設計は、複数の会社を苦境に陥れた主な落とし穴だった
- 多くのスタートアップは、シンプルで性能の良いシステムを作りながらも、「初日からマイクロサービスをやっていない」ことに偽の劣等感を覚える
- 「数人のエンジニアが保守する Django モノリスと MySQL インスタンスだけだが、何が悪いのか」という問いへの答えは、ほぼ常に「悪いところはない」
- 経験豊富なエンジニアでも今日の技術文化では不適切さを感じるが、実際の問題は、不当な過信と浪費、ダニング＝クルーガーが混ざった環境にあるのかもしれない
モノリスでも成長した会社たち
- モノリスなしでは成長できないという考えは、神話に近い
- Dropbox、Twitter、Netflix、Facebook、GitHub、Instagram、Shopify、StackOverflow などはモノリシックなコードベースで始まり、一部はいまも中核にモノリスを維持している
- StackOverflow は、大規模サイトを少ないハードウェアで運用している点をパフォーマンスページで誇りにしている
- Shopify は今も Rails モノリスを使い、実績ある Resque で数十億件のジョブを処理している
- WhatsApp は Erlang モノリスと約50人のエンジニアで大きく成長した
- エンジニアリング組織を約50人の小規模に保った
- 個々のチームは1〜3人規模で、高い自律性を持つ
- サーバーは少数を好み、各サーバーを可能な限り垂直スケールさせる
- Instagram は12人規模のチームで数十億ドルで買収され、Threads も Instagram のモデルに従っている
存在しない問題を解いてはいけない
- 核心的な問いは「どの問題を解決するのか」
- スケールが問題なら、何をなぜ別サービスに分けるべきかを示すデータが必要
- 分散システムはスケールとレジリエンスのために作られるが、あるサービスが遅くなったり落ちたりしたときに他のサービスへトラフィックが集中する状況まで考慮しなければならない
- 必要な考慮事項は、システムの利用パターンと負荷特性によって変わる
- バックプレッシャー
- サーキットブレーカー
- キュー
- ジッター
- すべてのエンドポイントに対する合理的なタイムアウト
- 小さな変更が全体障害を生まないようにする保護策
- ほとんどの会社は、本当に分散システムが必要な巨大規模には到達しない
- Amazon や Google の規模、専門性、リソースを持たないままそのやり方をまねると、時間とお金を浪費しやすい
- 悪い分散システムは、分散システムそのものよりさらに難しいという警告が残る
チーム別サービスと API という理想と現実
- 会社構造に分散トポロジーを合わせようとする試みは、問題を小さな断片に分ければ簡単になるという考えから出発する
- 理想的なマイクロサービスは、専任チームが厳格に保守し、美しく後方互換性のあるバージョン付き API の背後に隠れ、他チームとほとんどコミュニケーションしなくてもよい形
- 現実では Slack チャンネルがリリース、バグ、設定変更、破壊的変更、告知であふれる
- 全員が常にあらゆる状況を把握していなければならず、すでに忙しいチームが複数のマイクロサービスを中途半端に担当することがよくある
- 人の移動に伴ってサービスの所有権も変わり、1台の優れたレーシングカーではなく、複数の出来の悪いゴルフカートを作る状況になる
マイクロサービスが失わせるもの
-
DRY の弱体化
- マイクロサービスは基本的に DRY ではなく、各サービスに重複したボイラープレートが入る
- 小さなマイクロサービスでは配管コードの比重が大きくなり、平均的なサービスインスタンスがプロダクトコードというより「サービス」コードに近くなることがある
- 共通コードを切り出そうとしても、選択肢はどれも痛みを伴う
- 共通ライブラリを作ると、バージョンと更新戦略を決めなければならない
- すべてのリポジトリに定期的に pull request を作って強制更新できる
- モノレポでまとめると、それ自体の問題が生じる
- 一部のコード重複を許容するか、チームごとに毎回車輪を再発明させることになる
-
開発者体験の悪化
- 開発者体験とは、新機能開発やバグ修正に必要な摩擦と労力の大きさ
- マイクロサービス環境では、特定の作業にどのサービスを起動すべきか、どのチームの誰に何を聞くべきかを知るために、システム全体のメンタルマップが必要になる
- Spotify は多数のシステムとサービスをカタログ化するために Backstage を作ったが、これはこのゲームのコストが高いことを示す手がかりになる
- Spotify ではない会社は独自ソリューションを応急処置的に作ることになり、堅牢性や移植性は期待しにくい
- 新しいサービスを始めるには、自動化すべき項目も多い
- GitHub/GitLab の開発者権限
- 基本環境変数と設定
- CI/CD
- コード品質チェック
- コードレビュー設定
- ブランチルールと保護
- モニタリングとオブザーバビリティ
- テストハーネス
- Infrastructure as Code
- 複数のプログラミング言語を使うと、この一覧は言語の数だけ増える
- こうした自動化を磨き込むには数か月かかることがあり、プロダクトを作るのかツールを作るのかを選ばなければならない状況になる
-
統合テストの難しさ
- 単一サービスのテストとユニットテストが通っても、各コミット後に重要経路がなお維持されているかは別問題
- 分散構成の統合テストはほとんど不可能に近い問題として扱われ、その座をオブザーバビリティが置き換えるようになったと見ている
- オブザーバビリティは新しい産業領域となり、コストだけでなく開発者の時間も要求する
- オブザーバビリティはプラグインのようにすぐ動くものではなく、カナリアリリースやフィーチャーフラグなどを理解して実装しなければならない
- 問題を分割しても解決が簡単になるわけではなく、より難しい問題の束を得ることになる
モノリスが自動的に良いコードというわけではない
- モノリス擁護は「モノリスは良いコードで、マイクロサービスは悪いコード」という意味ではない
- 現実には、拙速なチームや平凡なチームが作った平凡なモノリスが多い
- ただし分散システムは、適当に済ませた部分、悪い判断、見落とした失敗モードに対してはるかに過酷
- 常に高い水準で運用しなければ、分散システムでは代償を払うことになる
マイクロではなく、ただのサービスで十分な場合もある
- サービスは必ずしも「micro」である必要はなく、ただのサービスで十分な場合がある
- 一部のスタートアップは関数ごとにサービスを作る水準まで行き、検証されていないカーゴカルトがどこまで行けるかを示した
- モノリスで始めることは明確な選択肢
- 「trunk & branches」パターンも多くの場合に合うことがある
- コア機能は「肉とじゃがいも」のようなメインのモノリスが担う
- 明確に識別でき、別途スケールが必要な負荷は branch サービスが担当する
- CPU を多く使う
Image-Resizing Serviceは、User Registration Serviceよりも別サービスとして筋が通る - 1秒あたりの登録数が独立した水平スケールを要求するほど多いのか、という問いがサービス分離の判断基準になる
流行の後退と現実的な選択
- マイクロサービスの過熱は冷めつつあるようで、ベンチャー資金の流れが引き締まるにつれ、企業がより常識的な判断をするよう市場で調整されている
- web-scale の問題がないのに web-scale アーキテクチャにお金を使うやり方は持続可能ではない
- ニューヨークからフィラデルフィアへ行く必要があるなら、複雑な宇宙船を作るより、90分の Amtrak の列車切符を買うほうが問題に合った解決策
1件のコメント
Hacker Newsのコメント
私はマイクロサービスを強く支持してきた人間の一人で、Netflixのプラットフォーム構築を手伝い、世界中を回ってその利点を説いてきたが、スタートアップに助言するときは、ほぼ常にモノリスから始めるように言っている。
コードベースとデータベースを一つにしておくほうがはるかに簡単で、かなり長い間スケールできる。DynamoDBのようなキー/バリューストアを使えば、リレーショナル機能の一部は失うものの、さらに持ちこたえられる。
モノリスもLambdaにデプロイできるし、サービスを分割しなくてもLambdaの利点は得られる。
成長してから、独立してスケールする必要がある部分や別個にデプロイする必要がある部分を、独自のデータストアを持つマイクロサービスとして切り出せばよい。
マイクロサービスはプラットフォーム維持だけでエンジニアリング時間の少なくとも**25%**を食うので、それだけの効率を取り戻せないなら価値はない。
成長中なら、いや多くの場合は、そもそもマイクロサービスをやらないほうがいい。
そしてお願いだからデータを分割してはいけない。データはコードより管理がずっと複雑だ。
今より複雑にすることはいつでもできる。モノリスから一部を切り出してサービスにすることもできるし、もちろん難しくはあるが、すでに入り込んだ複雑さをシステムから取り除くこととは比べものにならない。
複数のマイクロサービスをモノリスに戻したことがある人なら分かるが、たいていは最初から作り直すのに近い作業量になる。
こうした製品は、望めば本当にノートPCで本番環境を動かすこともできる。
前職では、顧客300人のためにマイクロサービス祭りをやっていた。数千人でも成功、数万人なら大成功というビジネスだったにもかかわらずだ。
普通はプラットフォーム維持にエンジニアリング時間の25%を使わないので、ローカルでは実行もできず、本番環境はダクトテープでかろうじて貼り合わせられている状態になる。
最近の面接で「同時接続ユーザー5億人」のシステムを設計せよという質問を受けたが、その会社は概して顧客数が少なく顧客あたり売上が高いタイプだった。
5億は世界のインターネット接続人口の約10%で、ばかげた数字だと見抜く試験だったのか、スタートアップが本当にそうなり得ると信じていたのか、今でも分からない。
私は、最も単純なもの、つまりモノリスを作り、機能と人々が求める製品かどうかの確認に集中すると答え、採用されなかった。
コントリビューターが約800人いる巨大なモノリスで働いているが、ユーザーの誕生日のような単純なフィールドを追加するだけでも同じように複雑だ。ただし複雑さのすべてが技術的なものではなく、全員のコードに触れるため「組織的な整合」が必要になる。
設計とレビューが延々と繰り返され、少なくとも2人のアーキテクトの承認が必要で、複数の計画サイクルに追加される。実際のコードは半日もかからない。
コードレビューでは90%のテストカバレッジを満たす必要があるが、テストが多すぎて1つのPRでは大きすぎるため、複数のPRに分け、複数週のリリースにまたがって入ることになる。
そのため機能フラグの裏に隠すのだが、現在の機能フラグは13,000個ある。
本番に入り、ダッシュボードとモニタリングが付くと、オンとオフを繰り返す。誕生日機能がなぜ課金サービスを壊したのか確信はないが、原因に見えるので数週間分析しなければならない。
結局1年後、その仕事を担当したエンジニアは良い評価を受け、昇進候補になるかもしれない。そしてすぐに、開発3年目に入った別の壊れたプロジェクト、ユーザーがタイムゾーンを設定できるようにする仕事に投入される。
マイクロサービスもモノリスも万能のハンマーや銀の弾丸ではなく、逆に悪そのものでもない。どちらもトレードオフのある道具であり、組織ごとに異なる文脈のトレードオフと結び付く。
問題は、エンジニアが複雑さに魅了され、「シンプルさ」を「その場しのぎ」と混同すること、そして組織がツールやアーキテクチャパターンを盲目的にまねることだ。
アーキテクチャやデザインパターンを使いさえすれば利点が生まれると信じて素朴に適用しても、そんなことは起こらない。
ソフトウェアエンジニアリングとは複雑さと果てしなく戦う仕事だということを肝に銘じようとしてきたし、成功したことも失敗したこともある。
この戦いは常に行うべきで、最優先の価値であるべきだ。そうでなければこういうことが起きる。
この戦争を終わらせてくれるアーキテクチャやイデオロギーはなく、ただこの職業の本質なのだ。
本番環境ではこうしたリリースフラグをオンにできないようにし、開発者は最終テストとリリース前にフラグのコードを削除しなければならなかった。
フラグが必要な機能ごとに多少の手間は増えるが、数か月もすればコードベースの複雑さが減る効果が大きく返ってくる。
マイクロサービスは技術的な問題ではなく、社会的な問題への解決策である
N人のエンジニアがいるチームでは、N²の調整が必要になる。大きなチームは終わりのない会議、メール、設計レビューに陥り、小さなチームはより効果的だが、大規模なシステムの維持には苦労する
システムをサブシステムに分ければ、各チームが自分のパズルのピースに集中しつつ、人同士の調整を減らせる
マイクロサービスが複雑さとオーバーヘッドを増やすのは確かだが、このアプローチは大きな組織が大きなシステムを素早く作り、反復的に改善できるようにする
今度は直接つなぐ代わりに、チーム間の「クロスファンクショナル」な会議と複雑な通信レイヤーが必要になる
もしサブシステム間のつながりがほとんど不要な分割を見つけたのなら、元のシステムでもそのつながりは存在しなかったはずで、N²問題もなかったはずだ
繰り返し見てきたのは、「全員がすべてのマイクロサービスに責任を持つ」という一つの巨大なチームで、結局誰も何にも責任を持たなくなるというものだ
「人の問題」を解決すると言って、些細な技術的問題を複雑な分散システム問題に変えてしまう
そうして本当の問題が生まれる
2種類のデータベースをサポートし、水平スケール可能なジョブ実行基盤もあった
かつては35人だったが、レイオフで7人まで減り、そのときむしろはるかに多くの仕事をこなすようになった。全員の足並みをそろえるのに使う時間が大きく減ったからだ
会議、承認、レビュー、計画、レトロスペクティブ、管理会議が大幅に減り、開発者の裁量が大きくなって、ただ仕事を終わらせるようになった
機能追加は半分の時間で容易にこなし、残りの50%を技術的負債の返済に使った。複雑さを容赦なく減らしたため、新機能の追加速度も上がった
プロジェクトによってはより多くの人員が必要かもしれないが、一定時間内にシステムへ追加できる複雑さには上限があると思う
しきい値を超えて開発者を増やすと、週あたりの機能数は変わらないのに、全員が少しずつ仕事を減らし、コミュニケーションにより多くの時間を使うようになる
この過程を数千人まで繰り返すと、フィールドを一つ追加するのに数か月かかる
別々のフォルダに移す方法を考えてみたのか気になる
新しいリポジトリや新しいDocker設定まで用意してモジュール化する必要はない。単にフォルダを使えばいい
よく見かけるパターンはこうだ。現在のCTOやVPたちが、もともとのモノリスを作ったか、その作成に関わっていた
誰もCTOにそのコードがひどいとは言いたがらない。あるいは時代が変わって全面的な改修が必要なコードにすぎず、モノリスであることとは関係ない
CTOはマーケティングや資金調達で忙しく、マイクロサービスかモノリスかを決められず、新しく採用されたアーキテクトが決定を下す
皆がマイクロサービスに歓声を上げる。急成長する本格的なテック企業という物語にぴったり合い、誰も一人で反対したりCTOを批判したりしたくないからだ
心からマイクロサービスが最善のトレードオフだから勧めるケースはほとんどない。自分の仕事が好きで、人をもっと採用するのが好きで、会社の物語にうまく合うからだ
大規模な改修の中で多くのコードを書き直して改善できるが、それを単にマイクロサービス移行と呼べばいい
結局、CTOの感情を傷つけず、群衆に従い、ほぼ全員が支持する大義名分のもとで、古くて悪いコードを大量に書き直す方法になる
個人のリードエンジニアであれCTO/創業者であれ、結局振り返ればもっと良くできたという結論に至り、チームが誠実に従ってきたパターンやプロセスの利点と欠点を、喜びと恐怖の中で見ることになる
自分のバイアスを確認してくれる文章なので、なおさら良い
何年も前から言ってきたが、マイクロサービス熱は、普通のエンジニアが需要を維持するための口実に近いと思う。凡庸さがそれを煽り、同時に多くのテック企業を回し続けている
UNIXをきちんと扱い、StackOverflowのような美しいミニマルなシステムを作れる有能なエンジニアは十分にいない
だから、凡庸さを覆い隠す煙幕としてのマイクロサービスは残り続けるだろう。AWSのようなクラウドプロバイダーが、あらゆるチャネルで自分たちを宣伝し、意思決定者にその道を選ばせるのだから、なおさらだ
クラウド、マイクロサービス、検証されていない最新フレームワークを語らなければ、時代遅れの老人扱いされる
そうしたシステムが最も効率的、強力、安全であることはめったにないにもかかわらずだ
今の会社は他社内で使うソフトウェアを作っていて、同時利用者は多くても200人で、利用量の急増もない
普通のWebサーバーにぴったりの環境で、予期しないスケーリング問題もないはずなのに、みんなクラウドへ行きたがる
理由は、経営陣、プログラマー、さらには顧客までがクラウドマーケティングに説得され、クラウドは格好いいと信じているからだと思う
会社は組織図だけを出荷するのではなく、あらゆる機能不全と歴史的な負債まで製品に載せて送り出す
5年前には効率的でよく設計されたデータモデルとAPI、よく書かれテストされたコードを備えた美しいプラットフォームだったとしても、CEOの度重なる方向転換、営業チームが押し込んだ土壇場の顧客要望、必要でも求められてもいない機能を追加するプロダクトマネージャー、人員と時間の不足によって、5年後には完全な混乱になり得る
ある日、巨大な技術的負債の山を前に、バグ修正や機能追加が必要以上に時間を食う状況に直面し、マイクロサービスは「すべてを焼き払って最初からやり直さなくてもいい」とささやくセイレーンの歌のように聞こえる
揚げ足取りに見えるかもしれないが、もっと大きなポイントがある。技術選択がボトルネックであることはめったにない
逆にマイクロサービスは可動部品と失敗モードが多く、はるかに複雑なので、普通のエンジニアはもちろん、普通ではない多くのエンジニアでも問題を作り込む可能性がずっと高い
この仕事で何が重要なのかを、今の世代にきちんと教えることに失敗したように思う
小さなチームでマイクロサービスへ移行中なので共感する。最大の問題は可観測性だ
運用で問題が起きたとき、正確に何が間違っているのかを突き止めるのが途方もない雑務になる
分散アプリケーション1つのログを追う程度では足りず、互いにメッセージが入り乱れた複数の分散アプリケーションのログを同時に見なければならない
トレースを可視化するツールがあれば何とかなるだろうが、小さなチームなので人的な帯域が限られており、まだそうしたツールはない
逆にモノリスには数年前からNewRelicが統合されていた。性能問題はあったが、ほとんどはインデックスといくつかのマテリアライズドビューで解決できた
何が間違っているのか把握しやすく、コードが古く競合状態だらけでも、問題解決そのものは難しくない
各マイクロサービスごとに別々のデータベースインスタンスを持ち、後でアップグレードしなければならない時が怖い。1つのデータベースインスタンスに複数のデータベースを置きたかったが、そのアーキテクチャは選択肢にない
集中ログ管理やサービス呼び出し／コード実行のトレースは新しいものではない。ただ、しばしば後回しにされ、その結果こうした不快な状況に陥る
最初から適切なツールを入れていなかったため、チームはより小さく、より制約された状態になる。サービスが何をしているのか、ほとんど、あるいはまったく分からないからだ
データベースインスタンスは1つずつアップグレードすればよい。セキュリティなどの深刻なバグがあるのでなければ、単にアップグレード可能だからという理由だけで急ぐ必要はない
こういう文章を読むと、妙に癒やされる感じがする。10年前にも同じことを大声で言っていたが、不信心者扱いされ、黙っていろと言われたからだ
「マイクロサービス」パラダイムに苦い後味を感じていることは了承してほしい。流行りの技術のトレードオフを完全に理解しないまま全面的に受け入れると何が起きるのか、実際に経験した
昔StumbleUponに採用されたとき、先端的なコンピューターサイエンス博士だという人物が、うまく動いて収益も上げていたPHPモノリスをScala/Javaのマイクロサービスアーキテクチャに変えようとしていた時期だった
新入社員のオンボーディングには、その狂ったコンピューターサイエンティストとの奇妙な1対1もあり、彼はマイクロサービスの利点を熱弁し、「単に数字のリストを足し合わせる分散サービスをなぜ作るんですか？」といった質問は、「それがなぜはるかに優れているのか、お前には理解できないだろう」という身振りで巧みにかわした
30人超の新規採用と4年以上の高負荷な開発の末、もはや収益を上げられなくなった会社には、より遅く、バグが多く、デバッグ不能な分散地獄絵図だけが残った
全体の設計者でありアーキテクトだった彼は、その時が「サバティカル」に行く良いタイミングだと判断し、ほどなくして何度目か分からない投資金も尽き、全員が職探しをすることになった
この記事は、Amtrakのたとえを借りるなら完全に脱線している
著者は、ひどいマイクロサービスを作ったのなら、単にモノリスを作ってさえいれば魔法のようにうまくいったはずだと前提している
同じ水準の設計とエンジニアリングでゴミのようなマイクロサービスを作ったとしても、目標がモノリスだったなら黄金のような結果になったはずだ、という言い方だ
文章の随所に自己満足的なところも強く、フルスタックJS開発者へのコメントがその一例だ
しかし実際のエンジニアリング観点の内容はほとんどない。測定値やデータを期待しても、返ってくるのは長広舌だけだ
システム変更のコストを低く保つために複雑性を管理するのは良い目標だが、この記事が提案しているのはそれではない
この点を認めていたか、データ、せめて逸話の一つでも示していれば、記事はもっと良くなっていただろう
私たちのチームなら、すでにすべてを知っていると信じていてこれ以上成長する余地がない人より、視野を広げてフルスタック開発者として成長したいと思っている明るく熱意あるフロントエンド開発者を選ぶ
現在の職場でこの流れと戦っていて、あるチームではある程度成功したが、別のチームでははるかにうまくいかなかった。そのチームは今、自分たちが作った分散モノリスと戦っている
皮肉なことに、元FAANMG出身者は全員モノリス支持派だ
多くの人が、マイクロサービスは反復的なプロセスの結果だという点を見落としているように思う。結局、スケールさせる必要がある部分をモノリスから切り出すのだ
マイクロサービスには、必要になるまでは維持したくない基盤インフラが大量に必要になる
ほとんどの企業は、そのパターンを支える適切なプラットフォームも持っていない
同感だ。うちの会社ではツールがまともに動かず、デバッグ自体を諦めている状態だ
ローカルマシンで1つのサービスを実行するには、残り9つがそのサービスとつながるように調整しなければならない
顧客向けの「機能」を作るとなれば、当然少なくとも2つのサービスを同時に触って、さらに多くのデータを移動させる必要がある
片方にブレークポイントを置くと、もう片方はタイムアウトする
そのため開発者全員がローカルVMにリリースビルドをデプロイし、ホットリロードなしでconsole.log、System.PrintLines()、_loggerを仕込んで、散らばったログファイルを読んでいる
当然、私はこの船から飛び降りるつもりだ
全部を分散トレーシングへ移すならさらに良いが、リクエストを正しく追跡するにはトレースメタデータを全体で統一する必要があり、投資はより大きくなる
開発より運用に役立つ可能性が高いが、それでも助けにはなるだろう。まともな区間情報だけでも、この混乱を理解するうえで多くの洞察を与えてくれる
片方のブレークポイントがもう片方のタイムアウトになるなら、開発モードでタイムアウトを延ばすか無効にする方法がないのか気になる