モノリシック vs. マイクロサービス アーキテクチャ: マイクロサービスは廃れ、モノリスが復活

ひどい技術的なデジャブに苦しんでいるように感じる人たちにとって、それは間違いではありません。 これは、Anne Thomas Manes がサービス指向アーキテクチャ (SOA) の終焉を宣言した2009 年頃の状況と同じです。 リンクは、デヴィッド・リンシカムによるマネスの投稿に対する解説へのリンクとなっている。なぜなら、元の投稿はインターネットによって消えてしまったようだからだ。

さて、Manes 氏は誇張し、いくぶん皮肉を言っていました。なぜなら、私たちがよく知っているように、サービス指向アーキテクチャは消滅していないからです。 マイクロサービスとしてかなり早く復活しましたが、インターネットの嘆きによって、設計者は「ネットワーク」がパフォーマンスにおいてどれほど大きな役割を果たすかをまだ理解していません。

SOA が「消滅」した理由は 2 つあります。

1. 競合する肥大化した XML ベースの標準により、アーキテクチャが過度に複雑になりました。 WSDL、SOAP、UDDI を懐かしく思い出す人はいません。 誰も。
2. 物理法則と相互運用性標準により、ネットワーク パケットの交換は光速と 1500 バイトに制限されます。

最初の課題は克服できたかもしれませんが、2 番目の課題はどうでしょうか? 2 番目の質問に対する唯一の答えは、これまでも、そしてこれからも、サービス設計の粒度とサービス間のデータ転送にかかる時間を適切に把握することとの間の微妙なバランスを保つことです。

データの転送は無料ではありません。 時間がかかります。 サービス間の通信に関しては、「ゼロコスト」というものは存在しません。 パケットを回線に送り、転送し、パケットから取り出し、最終的に処理するまでに時間がかかります。 また、輸送通信にも時間がかかることを忘れないでください。 ソケットを開いてリクエストを受け入れるのも無料ではありませんし、ペイロードをサービスが処理できる形式にシリアル化およびデシリアル化するのにかかる時間も無料ではありません。

次に、その合計コストに、使用しようとしているサービスの数を掛けます。

システムをより細かく設計するほど、リクエストの処理にかかる時間が長くなります。 つまり、リクエストを処理する合計時間は、リクエストが通過する必要があるサービスの数に依存します。

より細かい粒度ですか? 処理時間が長くなります。 その他のサービスはありますか? ネットワークの混雑が大きくなり、ネットワーク カードやデバイスがパケットを整理して再送信を要求するため、最終的に処理時間が長くなります。

したがって、SOA と同様に、マイクロサービスも、細分性が高すぎる設計パターンの影響を受ける可能性があります。

Amazon はマイクロサービスに代わるモノリスを選択しました。 つまり、彼らのユースケースでは、モノリシック アーキテクチャが最適な選択肢でした。 それはマイクロサービスが死んだことを意味するのでしょうか?

いいえ。 代わりに、次の 2 つの重要なポイントを理解しておく必要があります。

• まず、Amazon に倣い、サービスに依存するシステムの設計方法についてより慎重かつ思慮深くなり、あまりに多くの小さなサービスに職務を分割することがパフォーマンスにどのような影響を与えるかを確実に理解する必要があります。
• 第二に、モノリスは実行可能なアプリケーション アーキテクチャの選択肢であることを覚えておく必要があります。 エンタープライズ アプリ ポートフォリオの 60% が「従来の」アーキテクチャに基づくアプリケーションで構成されており、組織の 16% がそれらを廃止する予定がないのには理由があります。

アプリケーション アーキテクチャは良いものでも悪いものでもなければ、あらゆるユース ケースに適しているわけでもありません。 組織は、流行っているからという理由だけで、最も「最新」のアーキテクチャを選択するのではなく、一歩下がって、何を達成しようとしているのか、どのアーキテクチャがそのニーズに最も適しているのかを慎重に検討する必要があります。

将来はハイブリッド IT になると私たちが言うとき、それは単にマルチクラウドとオンプレミスの展開を組み合わせたもの以上のものを意味します。 また、エンタープライズ アプリのポートフォリオは、当面の間、従来のものと最新のものを組み合わせたハイブリッドな状態を維持することになります。 そのため、F5 ポートフォリオは、オンプレミス、パブリック クラウド、またはその両方を問わず、すべてのアプリケーションを引き続きサポートします。