スタートアップ、あなたは本当にマイクロサービス税を支払いたいですか?

なぜコードベースを早めに分割することは、チームのスピードを静かに破壊するのか - 代わりに何をすべきか。

なぜコードベースを早めに分割することは、チームのスピードを静かに破壊するのか - 代わりに何をすべきか。

スタートアップで、your survival depends on how quickly you can iterate, ship features, and deliver value to end-usersさらに、あなたのテクノロジースタックやプログラミング言語の選択などが、チームのスピードに直接影響します。間違ったアーキテクチャ、特に早期のマイクロサービスは、生産性を大幅に損なうことができ、ソフトウェアの提供に欠かせない目標に貢献することができます。

私は、初期段階のスタートアップ向けのグリーンフィールドプロジェクトに取り組む際、ソフトウェアアーキテクチャの面で疑わしい決定が下され、サービスが半端に完成し、Brittle, over-engineered and broken local setups(脆弱で、過剰にエンジニアリングされ、壊れたローカルセットアップ)そして、demoralized teams不要な複雑さを維持するために戦う人。

特定の落とし穴に潜入する前に、マイクロサービスを早期に導入するときに実際に登録しているものがあります。

Microservices Early On: What You’re Paying For

展開の複雑さ

単一機能のための5+サービスのオーケストラリング

Hours lost per release

ホーム > Dev Fragility

Docker 拡張、破損したスクリプト、プラットフォーム特有のハック

Slow onboarding, frequent breakage

CI/CD ダブル化

Multiple pipelines with duplicated logic 複数のパイプライン

Extra toil per service

クロスサービスカップリング

共有状態によって密接に結びついている「decoupled」サービス

Slower changes, coordination tax

Overhead 観察

Distributed Tracking、Logging、Monitoring

Weeks to instrument properly

Suite Fragmentation テスト

サービスに分散したテスト

Brittle tests, low confidence

マイクロサービスがなぜ早期に反発するのか、どこで本当に役立つのか、そしてスピードと生存のためにスタートアップのシステムを構築する方法を解説しましょう。

Monoliths Are Not The Enemy(モノリスは敵ではない)

いくつかの SaaS 製品を構築している場合、単純な SQL データベース ワラッパーでさえ、ビジネス ロジックの働き方に多くの内部の複雑さをもたらす可能性があります。

時間とともに、時には不要な機能があれば、あなたのアプリが混乱する可能性は避けられない。Monoliths, even when messy, keep your team focused on what matters most:

• 生き残る
• 顧客価値の提供

Monoliths の最大の利点は、デプロイのシンプルさです. 一般に、このようなプロジェクトは既存のフレームワークに基づいて構築されています — it could be Django for Python,ASPネットC#、Nest.js、Node.js アプリケーションなど、モノリチックアーキテクチャに固執すると、ファンシーなマイクロサービスに比べて最大の利点を得る - 主にこれらのフレームワークを単一プロセス、モノリチックアプリとして動作させるように設計したオープンソースコミュニティとプロジェクトメンテナリストの幅広いサポート。

私がフロントエンドチームを率い、時々バックエンドチームにテクノロジー選択について相談したある不動産スタートアップでは、Laravelベースのアプリの興味深い進化がありました。

時間の経過とともに、数百ギガバイトのドキュメントを処理し、数十の第三者サービスと統合する機能豊富なスイートに進化しました。

チームはLaravelコミュニティが推奨するベストプラクティスに大きく依存し、その規律が報われたことで、当社はアプリケーションの能力を大幅に拡大し、同時にビジネスのニーズと期待を満たすことができました。

興味深いことに、私たちはシステムをマイクロサービスに切り離す必要もなく、より複雑なインフラストラクチャパターンを採用する必要もありませんでした。その方法で多くの偶然の複雑さを回避しました。『Majestic Monolith』なぜ単純さが初期のスーパーパワーであるかを明らかにする。

人々はしばしば、モノリットをスケーラブルにするのは難しいと指摘しますが、それは悪いモジュラー化です。内部このような問題を引き起こす可能性のあるモノリス。

Takeaway: A well-structured monolith keeps your team focused on shipping, not firefighting.

しかし、マイクロサービスは「ベストプラクティス」ではないでしょうか。

多くのエンジニアが早期にマイクロサービスに到達し、彼らは「正しい方法」だと思っているし、確かに、規模で、彼らは助けることができますが、スタートアップでは、同じ複雑さがドラッグに変わります。

マイクロサービスは、実際のスケーリングボトルネック、大きなチーム、または独立して進化するドメインがある場合にのみ有効になります。その前に? あなたは利益を得ることなく価格を支払っています:複製インフラ、脆弱なローカルセットアップ、そして遅いイテレーション。Segment最終的にマイクロサービスの分割を逆転させるこの正確な理由 - コストが多すぎる、価値が足りない。

Takeaway: Microservices are a scaling tool — not a starting template.

マイクロサービスが間違っている場所(特に初期)

私がアドバイスした一つの初期段階のチームでは、サービスを分割するという決定は、技術的な利益よりも、PMエンジニアリングの連携をより大きく生み出しました。

以下は、早期に浮かぶ最も一般的な反パターンです。

1.任意サービスの境界線

理論的には、ビジネスロジックのドメインによってアプリケーションを分割するための提案がよく見られます - ユーザサービス、製品サービス、注文サービスなど。これはしばしばドメイン駆動デザインやクリーンアーキテクチャの概念から借りられます - スケールで意味がありますが、初期段階の製品では、製品自体が安定または検証される前に構造を早期に骨格化することができます。

• 共有データベース
• シンプルなワークフローを求めるクロスサービス
• カプセル化「分離」

あるプロジェクトでは、ユーザー、認証、および認証を別々のサービスに分離するチームを観察し、それが構築していたすべての API 操作のデプロイの複雑さとサービス調整の困難につながった。

実際には、ビジネス論理は直接サービスの境界線をマッピングしません. Premature separation can make the system more fragile and often times difficult to introduce changes quickly. 早期分離は、システムをより脆弱にし、しばしば変更を迅速に導入することが困難になります。

代わりに、ボトルネックを外科的に隔離 - 理論的な優雅さではなく、実際のスケーリングの痛みに基づいて。

初期段階のチームをトレーニングしたとき、我々は時々内部の旗や展開トグルを使用して将来のサービス分割をシミュレートしました - 直ちの運用負荷なし。

Takeaway: Don’t split by theory — split by actual bottlenecks.

2.Repository and Infrastructure Sprawl(リポジトリとインフラストラクチャ)

アプリケーションで作業するとき、通常、次のコレクションが重要です。

• コードスタイルの一貫性(linting)
• 統合テストを含むインフラのテスト
• 地元環境構成
• 文書化
• CI/CD 構成

プロジェクトがモノレポとして構成されている場合は、中央 CI/CD 構成(GitHub Actions または GitLab CI で作業する場合)で生活を簡素化できます。

リポジトリやツールを切り替えるコンテキストは、配信されるすべての機能の開発時間を増加させます。

monorepos と 1 つのプログラミング言語を使用して問題を軽減する

この問題を軽減する方法はさまざまです. 初期のプロジェクトでは、最も重要なことは、コードをモノレポに保存することです. これにより、プロダクトに存在するコードのバージョンが1つあることを保証し、コードレビューを調整し、より小規模なチームで協力することがより容易になります.

Node.js プロジェクトでは、monorepo ツールを使用することを強くお勧めします。nxまたはturborepo両方:

• サブプロジェクト間の CI/CD 構成の簡素化
• dependency graph-based build caching をサポート
• 内部サービスを TypeScript ライブラリとして扱う(ES6 インポートを通じて)

これらのツールは、ライティングコードを書くことやオーケストラを再発明することに費やした時間を節約します。

• 複雑な依存性の木は急速に成長することができます
• CI performance tuning is not trivial. CI performance tuning is not trivial. CI performance tuning is not trivial.
• ビルドタイムを下げるために、より速いツールリング(Bun)が必要かもしれません。

タグ:Tooling Likenxまたはturborepo小さなチームにモノレポスピードを提供します - あなたがそれらを清潔に保つために投資する用意がある場合。

開発するときgo-based microservices, a good idea early in development is to use a single microservices. -based microservices, a good idea early in development is to use a single goワークスペース with thereplace指令 ingo.mod最終的に、ソフトウェアがスケールするにつれて、簡単に分離することが可能になります。 goモジュールは別々のリポジトリに置く。

Takeaway: A monorepo with shared infra buys you time, consistency, and sanity.

Broken Local Dev = 壊れたスピード

If it takes three hours, a custom shell script, and a Docker marathon just to run your app locally, you've already lost velocity.

初期のプロジェクトはしばしば苦しむ:

• 欠落資料
• 時代遅れの依存
• OS 特有のハッキング (Hello, Linux-only setups)

私の経験では、以前の開発チームからプロジェクトを受け取ったとき、これらのプロジェクトはしばしば単一のオペレーティングシステムのために開発されました。一部の開発者はmacOSで構築することを好み、Windowsでシェルスクリプトをサポートすることを決して気にすることはありませんでした。以前のチームでは、Windowsマシンで作業するエンジニアがいましたが、しばしばシェルスクリプトを書き直すか、ローカル環境を実行するプロセスを完全に理解し、逆にエンジニアリングする必要がありました。

別のプロジェクトでは、ソロ開発者が脆弱なマイクロサービス設定を作成し、Dockerコンテナを実行するワークフローがローカルファイルシステムにマウントされた。

しかし、古いWindowsのノートパソコンで新しいフロントエンドの開発者を搭載することは悪夢に変わりました. 彼らはUIを見るために10つのコンテナをスピンアップしなければなりませんでした. すべてが壊れました - ボリューム、ネットワーク、コンテナ互換性 - セットアップは非常に悪く文書化されました. これは搭載中に大きな摩擦ポイントを作成しました.

我々はコンテナなしでnginx/Dockerの構成を模するNode.jsプロキシをハッキングしたが、それはエレガントではなかったが、開発者がブロックを解除して貢献し始めた。

Takeaway: If your app only runs on one OS, your team’s productivity is one laptop away from disaster.

Tip:理想的には、目標はgit clone <repo> && make up現地でプログラミング言語やツールチェーンが機能していない場合、Windows/macOS/Linuxのための指示を含む最新のREADMEファイルを維持することは必須です。現在、Windows(OCamlのような)ではうまく機能しないプログラミング言語やツールチェーンがありますが、現代の広く人気のあるスタックは、広く使用されているすべてのオペレーティングシステムでうまく動作します。

4.技術不一致

アーキテクチャを超えて、あなたのテクノロジースタックはまた、痛ましいマイクロサービスがどのように変化するかを形作ります - すべての言語がマイクロサービスアーキテクチャで輝くわけではありません。

• Node.js および Python: 迅速なイーテレーションに最適ですが、ビルドアーティファクト、依存バージョン、およびサービス間のランタイムの一貫性を管理することは痛ましいスピードになります。
• Go: 静的バイナリ、高速ビルドタイム、低いオペレーティングオーバーヘッドにコンパイルします. More natural fit when splitting is really needed.

パフォーマンスを求めるなら、JVMとそのエコシステムと、アーティファクトを規模で展開し、マイクロサービスベースのアーキテクチャで実行する能力を探すかもしれません。

チームは、テクノロジーの選択に当初は明らかでなかった大きな問題があり、別のプログラミング言語でバックエンドを再構築する代償を支払わなければならなかったことに気づくことがしばしばあります。あの男たち伝統的なPython 2コードベースについて何かをするように強制され、Goに移行しました)。

しかし、逆に、本当に必要であれば、複数のプログラミング言語をプロトコルとしてブリッジすることができます。gRPCあなたが機械学習機能やETLベースの仕事であなたの機能セットを豊かにしたいという点に到達したとき、あなたは単に独自にPythonでMLベースのインフラストラクチャを構築するだけで、ドメイン特有のライブラリの豊かなエコシステムのために、自然に他のプログラミング言語が欠けているが、そのような決定は、この起業を正当化するのに十分な頭数があるときに作られるべきである。

Takeaway: Match the tech to your constraints, not your ambition.

5. 隠された複雑さ:コミュニケーションと監視

マイクロサービスは、目に見えないニーズのウェブを導入します。

• サービス発見
• API バージョン
• Retries, circuit breakers, fallbacks シリーズ
• 分散トラッキング
• Centralized Logging and Alert(中央レッスンと警報)

モノリスでは、バグは単純なスタックの痕跡である可能性があります。分散型システムでは、「Bの展開がCに30秒遅れるとサービスAが失敗するのはなぜですか?」あなたは、観測可能なスタックに徹底的に投資する必要があります。それを「適切に」行うには、アプリケーションを特定の方法でツール化する必要があります、例えば、OpenTelemetryを統合してトラッキングをサポートするか、複雑なサーバーなしのシステムを使用する場合、クラウドプロバイダのツールAWS XRayに頼る必要があります。actually生産で機能する。

もちろん、観測可能な機器のいくつかはモノリットアプリで実行する必要がありますが、一貫した方法でサービスの数に関してそれを行うよりもはるかに単純です。

Tip:理解する そのdistributed systems フリーじゃない彼らは、全く新しいクラスのエンジニアリングの課題へのコミットメントです。

マイクロサービスの場合ドー意義あること

マイクロサービスの難しさにもかかわらず、サービスレベルの切り離しは実際に非常に有益な場合があります。

• Workload Isolation: 一般的な例は、S3 イベント通知の使用に関する AWS のベスト プラクティスで、画像が S3 にアップロードされるとき、画像の変更/OCR プロセスを起動するなど、なぜ有用であるか:私たちは、不明瞭なデータ処理ライブラリを自己隔離されたサービスに切り離し、画像処理に専念し、アップロードされたデータから出力を作成する API を作成できます。
• Divergent Scalability Needs: - あなたがAI製品を構築していると想像してください。MLワークロードを引き起こし、過去の結果を表示するシステムの一部(Web API)は、リソース密集ではなく、データベースと主に相互作用しているため、軽量です。逆に、GPUで動作するMLモデルは実際に実行し、追加構成を備えたGPUをサポートする特別なマシンが必要です。
• さまざまなランタイム要件: — C++ で書かれたコードの古い部分を持っているとしましょう. あなたは 2 つの選択肢を持っています — 魔法でそれをあなたのコアプログラミング言語に変換するか、コードベースに統合する方法を見つける。 古いアプリの複雑さに応じて、あなたは粘着コードを書く必要があり、そのサービスとの相互作用を確立するための追加のネットワーク / プロトコルを実装するが、底線は — あなたは実行時間の不互換性のためにこのアプリを別々のサービスとして分離する必要があります。

大規模なエンジニアリング機関は同様の課題に直面しています。例えば、Uberのエンジニアリングチームはドメイン指向のマイクロサービスアーキテクチャへの移行を文書化— 理論的な純粋さからではなく、チームの複雑さと限界の拡大に対する実際の反応として、彼らのポストは、組織の成熟と運営上のオーバーヘッドがそれらをサポートするときにマイクロサービスがどのように機能するかを示す良い例です。

あるプロジェクトでは、不動産であることもあり、Pythonベースの分析ワークロードを実行する以前のチームからのコードがあり、データをMS-SQL dbにロードすることにより、Djangoアプリを作成することは無駄であることが判明しました。

Takeaway: Use microservices when workloads diverge — not just because they sound clean.

スタートアップ向けの実践ガイドライン

あなたがあなたの最初の製品を配信している場合は、ここは私が推奨するプレーブックです。

• monolithic を開始 共通のフレームワークを選択し、機能を完了することに集中してください. すべての既知のフレームワークは、いくつかのAPIまたはウェブサイトを構築し、ユーザーにサービスを提供するのに十分です。
• Single repo. Do not bother splitting your code into multiple repositories. I have worked with founders who wanted to separate repos to reduce the risk of contractors copying IP — a valid concern. But in practice, it added more friction than security: slower builds, fragmented CI/CD, and poor visibility across teams. Marginal IP protection was not worth the operational drag, especially when proper access controls inside a monorepo were easier to manage. 初期段階のチームにとって、明確さとスピードは理論的なセキュリティの利益よりも重要である傾向にあります。
• Dead-simple local setup. Make up work. If it takes more, be very specific on the steps, record a video/Loom, and add screenshots. If your code is going to be run by an intern or junior developer, they’ll likely hit a roadblock, and you’ll spend time explaining how to troubleshoot a problem. 私は、あらゆるオペレーティングシステムのすべての可能な問題をドキュメンタリー化することは、地元のセットアップで特定のものがうまくいかなかった理由を明らかにするために費やされた時間を排除することを発見しました。
• CI/CD を早期に投資する. あなたが手動でサーバーに scp するだけのシンプルな HTML であるとしても,これを自動化して CI/CD でソースコントロールに頼ることができます. セットアップが適切に自動化されるとき,あなたは継続的な統合インフラストラクチャを忘れて機能に焦点を当てるだけです. 私は、外部チームと作業するときの多くのチームと創設者が CI/CD で安いことがよく見られ、その結果、チームは手動の展開プロセスによって demoralized とイライラされます.
• 外科的に分割する. 分割は、痛ましいボトルネックを明確に解消する場合にのみ。そうでないと、モノリット内のモジュラリティーとテストに投資する - より速く、維持しやすくなります。

そして何よりも:optimize for developer velocity.

Velocity is your startup’s oxygen.早期のマイクロサービスは、その酸素をゆっくりと漏らす - ある日、あなたは呼吸ができないまで。

Takeaway: Start simple, stay pragmatic, and split only when you must.

マイクロサービスベースのアプローチを採用する場合

私は、それらがすべきよりも早く作成されたマイクロサービスベースのプロジェクトを持っており、以下に私がそれについて示すことができる以下の勧告があります。

• マイクロサービスベースのアーキテクチャをパワーアップするテクニカルスタックを評価してください。開発者体験ツール化に投資します。サービスベースの分離があれば、マイクロサービススタックを自動化し、ローカル環境と生産環境の両方でコンフィギングを自動化することを考える必要があります。いくつかのプロジェクトでは、モノレポジトリの管理タスクを実行する別々のCLIを構築しなければなりませんでした。一つのプロジェクトでは、15〜20のマイクロサービス展開が含まれており、ローカル環境では、従来の開発者のためのシームレスな単一コマンドスタートアップまでダイナミックにdocker-compose.ymlファイルを生成するためのクライアントツールを作成する必要があります。
• サービスコミュニケーションを取り巻く信頼性の高いコミュニケーションプロトコルに焦点を当ててください。もしアシンクメッセージであるなら、メッセージのスケジュールが一貫して標準化されていることを確認してください。もしRESTであるなら、OpenAPIドキュメントに焦点を当ててください。サービス間のコミュニケーションクライアントは、ボックスの外に出ない多くのことを実装する必要があります:エクスポンシャルバックコフ、タイムアウトのリリース。
• ユニット、統合テスト、およびエンド-to-エンドテスト設定が安定しており、コードベースに導入するサービスレベルの分離量とスケールしていることを確認します。
• マイクロサービスベースのワークロードを使用する小規模なプロジェクトでは、共通のユーザを含む共有ライブラリをデフォルトで使用して、観測性、コミュニケーションコードを一貫した方法でインストールする可能性があります。
• 構造化された JSON ログを追加し、アプリケーションが展開されるときに物事をバグアップするためのさまざまな相関 ID を作成します. 豊富なログ情報を出力する基本的なアシスタントでさえ(適切なログ / トラッキング機能でアプリケーションを機器化するまで)しばしばスムーズなユーザー フローを把握するのに時間を節約します。

要するに、マイクロサービスを提供する場合は、追加の開発時間とメンテナンスに関して支払う税金を事前に理解して、チーム内のすべてのエンジニアのためのセットアップを実行できるようにする必要があります。

Takeaway: If you embrace complexity, invest fully in making it manageable.

結論

Premature microservices are a tax you can’t afford. Stay simple. Stay alive.痛みが明らかになったときに分裂する。

Survive first. Scale later. Choose the simplest system that works — and earn every layer of complexity you add.

関連資源

• Monolith First / マーティン・ファウラー
• The Majestic Monolith - DHH / Basecamp
• Goodbye Microservices: From 100s of problem children to 1 superstar - セグメントEng.
• Deconstructing the Monolith - Shopify Eng. (モノリットを解体する)
• ドメイン向けマイクロサービスアーキテクチャ - Uber Eng.
• Go+Services = One Goliath Project - Khan Academy(ガン・アカデミー)