おそらくマイクロサービスは必要ない

このブログ記事を書くのは楽しかったです。多くの人に嫌われる可能性は高いですが…

開発者の皆さん、私たちは話し合う必要があります。マイクロサービスと、うまくいかない状況について話し合う必要があります。簡単ではありませんが、やらなければなりません。そうしないと、うまくいきません。

マイクロサービスは最近とても人気があります。これはシステムと組織の拡張に役立つ優れたアーキテクチャスタイルです。多くの成功している企業がマイクロサービスを使用しています（例： Netflix、Spotify など)。 したがって、ほとんどの企業がこれを使用しているか、使用を計画しているのは当然です。しかし、それがもたらす追加コストに気付いていない企業もあります。

本題に入る前に、マイクロサービスに関する私の経験についてお話ししたいと思います。

どのように始まったのか – マイクロサービスですか?

2012 年、私が勤めていた会社では、会社を何千人ものエンジニアと 1000 倍の取引に成長させるという課題に直面していました。この記事では、採用やオンボーディングなどではなく、アーキテクチャに焦点を当てています。

読んでいた スケーラビリティのルール: Web サイトのスケーリングに関する 50 の原則 当時、 そしてこの本は AKFスケールキューブ。

非常に理解しやすいと感じました。そのため、私はこれを使用して、本番環境で異なるバイナリを実行する必要がある理由を他の人に説明しました。検索モジュールのトラフィック パターンは、ショッピング カート モジュールのトラフィック パターンとはまったく異なります。これらのコンポーネントを分割することは理にかなっています。さらに、複数のチームが独立して自律的に作業できるようになります。これは、会社を数千人のエンジニアに成長させるという課題を解決するのに役立ちます。

当時はマイクロサービスとは呼ばず、単にサービスと呼んでいました。マイクロサービスという用語は私たちの視野に入っていませんでした。その過程で多くの間違いを犯しました。しかし、私たちは自分たちの問題に基づいて決断を下し、振り返ってみると、それは良い決断でした。

ということで、私がこのトピックに多少精通していること、そしてこの 10 年以上にわたって多くのサービスを実装し、多くの再アーキテクチャを実行してきたことで傷ついたことがあることがおわかりいただけたと思います。

それで、何が問題なのですか?

何も問題はありません マイクロサービス それ自体は何も悪いことではない モノリス 同様です。しかし、私たちの業界では、特効薬は存在しないということを忘れているようです。そして、時には、実際にあなたを傷つける弾丸が存在するのです。信じられないですか? いくつかの例を挙げて説明しましょう。

例1 – あなたはサービスを受け、あなたもサービスを受け、全員がサービスを受ける

私は、業界の他の人々と会話をして、彼らが何をしているのかを理解し、自分の経験を共有するのが好きです。こうした会話は、ネットワークを広げ、非常に賢い人々から洞察を得る素晴らしい方法です。

特に覚えているのは、技術部門に約 200 人の従業員がいるスタートアップ企業のエンジニアリング ディレクター 2 人との会話です。彼らは素晴らしい人々で、とても賢く、話しやすい人々でした。

私は通常、テクノロジーの領域を詳しく調べて、会社が何をしているのか、そして主な課題は何かを理解するのが好きです。ですから、当然のことながら、アーキテクチャとチームの編成方法についてもっと詳しく教えてほしいと頼みました。

マイクロサービスを使用していると話す人がいました とともに 複雑なシステムを生産している。そして、彼らは約350の マイクロサービス 彼らによると、最大の課題は、古い依存関係、古いランタイム バージョン、一部のサービスの内部に関するノウハウがないなど、すべてのマイクロサービスが維持されるようにすることだったという。

同社にはさらに マイクロサービス 開発者よりも、クライアントに多くの機能を提供する製品重視の企業では、これらすべてのマイクロサービスに対応するのは困難です。

例 2 – あなたも変わる、私も変わる、私たち全員が変わる

低い結合と高い凝集性 正しく行うことは難しい。 マイクロサービス アーキテクチャ。結果として、密に結合され、凝集度の低い非常に小さなマイクロサービス (ナノサービスとも呼ばれる) になってしまう可能性があります。

以前勤めていた会社で、「境界付けられたコンテキスト」に非常に多くの小さなサービスがあったため、変更を行うには多くのチームが協力して対応する必要がありました。さらに悪いことに、パフォーマンスはひどいものでした。

この例は非常に良いです。なぜなら、チームはパフォーマンスを向上させるためにすべての情報を集約する別のサービスを作りたかったからです。 合併 より統合性を持たせるために小さなサービスを追加することは、「一枚岩のように見えた」ため、良くないと考えられていました。

例3 – すべてが順調だったが、それがうまくいかなくなった

すべての 解雇 テクノロジー業界で起こっていることの中で、私がますます耳にすることが増えているのは、企業が大幅な削減を行った後にサービスが多すぎるという話です。

これは公平な例ではないかもしれません。なぜなら、企業が技術部門の40%または60%を削減し始めると誰が予想したでしょうか？問題は、シンプルさが私たちの業界で最も難しいことの1つであるということです。しかし、私たちはシンプルさを維持することを目指すべきです。 物事をできるだけ単純にするが、それ以上単純にするわけではない。

生産においてシンプルなシステムを導入している企業は より機敏に運用上の諸経費をあまり気にすることなく、コストを削減し、人員を削減することができます。

例4 – マイクロサービスを使ってスタートアップを始めよう

これは最後の例になります、約束します。これは実際に私が見つけるのに苦労している講演からの抜粋です。私が言及している講演がどれかご存じの場合は、適切なクレジットを付けられるようにコメントしてください。

グリーンフィールド プロジェクトは素晴らしいと思いませんか? 創造的なアーティストが絵を描き始めるのを待っている空のキャンバスのようなものです。この場合、アーティストはカラフルな絵を描くことを選択しました。アーティストは、Ruby、Golang、Java という主要な色をすべて選びました。それらを PostgreSQL、Elasticsearch、Cassandra と組み合わせました。

その絵は？完成させる時間さえあれば、ピカソの作品になったかもしれないのに。

いつも悪いのですか？

悪いと言っているわけではありません。Jet.comは実際 開始 マイクロサービスを使用して、Walmart に素晴らしい出口をもたらしました。私が言いたいのは、エンジニアとして、批判的思考を持ち、最善のものを選択する必要があるということです。

いいけどなんで？

これを読んで、「これはスキルの問題だ」と考える人もいるでしょう。しかし、そうではありません。最初の 2 つの例に関係する人たちを私は知っています。彼らは本当に頭が良く、優秀なエンジニアです。他の例に関係する人たちも本当に頭が良いと確信しています。

もっと深い理由があると思うし スコット・ハナー このツイートではもっともらしい例を挙げている:

私は、OOP と同じように、マイクロサービスを内面化したと思います。もはや、マイクロサービスではないものがどのようなものかわかりません。それは、私が知っているほとんどの人の意識から抹消されています。1984 年のニュースピークのようなものです。私たちは思考を形成する能力を失っています。助けが必要です。

— スコット・ハンネン (@scotthannen) 2024年5月10日

私たちは 内面化された マイクロサービス。おそらくこれが、多くの小規模チームがマイクロサービスを採用している理由でしょう。この考え方は私たちの脳に深く根付いています。

ゼロ金利政策（ZIRP）も原因かもしれない。このツイートでは、 DHH それについて話します。

マイクロサービスの流行は、おそらく ZIRP の最も純粋な例です。ルーズベルトは、たとえ試みたとしても、プログラマーのためのより優れた完全雇用プログラムを設計することはできなかったでしょう。 https://t.co/9nZ4RX4j3p

— DHH (@dhh) 2024年5月11日

私は DHH に同意する傾向にあります。ZIRP がこの現象に寄与した可能性があります。企業は成長を望んでおり、多くの開発者を雇うことはほとんどの企業にとって標準的な選択肢でした。

ZIRP 後の時代には、マイクロサービスの隠れたコストに対する人々の認識が高まると予想されます。たとえそれが当面の問題に対する優れた解決策であったとしても、経営陣はおそらくマイクロサービスの導入に消極的になるでしょう。

まだ時間はあります

上記の例のいずれかがあなたの現実を反映しているとしても、心配しないでください。ソフトウェアの良いところは、次のことができることです。 ほとんど – 常に変更してください。 問題問題という単語を次のように置き換えてみてください 機会 代わりに、ジョークのように、 飲む機会がある。

サービスの数がイノベーションの能力に影響を与えている状況に陥っていませんか? 会社が運用上のオーバーヘッドを削減する方法について戦略を立てます。信頼性を重視するか、将来の革新のための能力を高めるためにシステム アーキテクチャの簡素化に投資するか、どちらかです。

例 2 のチームはそれを実行しました。彼らは、コスト削減と顧客エクスペリエンスの向上に重点を置いたサービスを統合する戦略を提示しました。関係者は非常に満足しました。

会社を立ち上げますか？ 会社を立ち上げてマイクロサービスの使用を検討している場合は、課題、マイクロサービスが必要な理由、検討した代替案を説明する設計ドキュメントを作成してください。信頼できる人がいる場合は、その設計ドキュメントを共有してフィードバックを求めてください (合法的に実行できる場合)。これにより、考えが整理され、マイクロサービスがスタートアップに適したアーキテクチャ スタイルであるかどうかを明確に理解できるようになります。

マイクロサービスは素晴らしいですが、システムと組織に複雑さを増します。作業方法が変わり、アーキテクチャがより複雑になり、モノリスからマイクロサービスに移行する場合は、何年もかかることを理解してください。急いでマイクロサービスを導入する前に、一歩下がって、それがどのように役立つか、またどのように害を及ぼすかを考える必要があります…

そして信じてください、それは両方をします。たとえそれが最高の建築様式であったとしても、それはあなたを傷つけ、喜ばせるでしょう。人生のあらゆる良いものと同じように。

開発者の皆さん、私がこの会話を始めたのは、私が気にかけているからです。業界の将来を気にかけています。私は、時代を超えて耐久性のあるソフトウェアを構築する、長続きし、永続的で、持続可能な業界を望んでいます。実用的な決定を下し、テクノロジーを目的ではなく手段として使用する業界を望んでいます。

マイクロサービスは素晴らしいこともあります… しかし、おそらくマイクロサービスは必要ありません。