IT アーキテクチャにおけるマイクロサービスの影響についての議論: 長所と短所

Twitter の CEO が同社のマイクロサービスの一部を削除することを決定したとき、一部のユーザーの 2 要素認証で一時的な問題が発生し、IT アーキテクチャにおけるマイクロサービスの役割が精査されました。 Twitter の場合、特定のマイクロサービスを削除したことで複雑な影響が生じ、重要な機能が一時的に停止しました。これは、組織がマイクロサービスなしで存在できるかどうか、またはマイクロサービスが運用にあまりにも安全に融合されているかどうかという問題を提起します. InformationWeek とのインタビューで、Pulumi の CEO である Joe Duffy は、マイクロサービスが IT アーキテクチャに適合する場所、マイクロサービスが提供する利点、および IT リーダーが用心しなければ、マイクロサービスが一種の従来の技術的負債になる可能性について語っています。

IT アーキテクチャにおけるマイクロサービスの配置

Duffy 氏は、モノリシック アーキテクチャから完全分散アーキテクチャまでの範囲があり、マイクロサービスはその範囲のどこかにあり、後者に傾いていると説明しています。クラウドは、2 台の仮想マシンとデータベースの時代から、マネージド サービス、コンテナー、およびサーバーレス アーキテクチャを使用した完全分散システムへと移行することで、アプリケーション アーキテクチャの革新的な考え方を大幅に可能にしました。マイクロサービスは、この変化の中心です。最新のクラウドは、さまざまな長所と短所を提供しながら、より分散されたアーキテクチャへの移行を加速させています。マイクロサービスは、API 境界の背後にサービスを配置することである程度の複雑さを管理できますが、企業が少数のマイクロサービスしか必要としないときに何千ものマイクロサービスを採用することで、簡単にやり過ぎになる可能性があります。

レガシー IT との比較と技術的負債の蓄積のリスク

マイクロサービスは、テクノロジーのレイヤーが時間をかけて構築される従来の IT に匹敵するものになる可能性があります。マイクロサービスの利点は、API の背後にあると、重要な運用管理が不要になることです。ただし、これは技術的負債の蓄積につながる可能性もあり、サービスが価値を付加できなくなり、時代遅れになる可能性があります。

マイクロサービスの合理化と頭痛の緩和

あらゆるテクノロジーと同様に、マイクロサービスを取り巻くハイプ サイクルがあり、過大な期待と避けられない幻滅があります。マイクロサービスは現在、誇大広告のピークを過ぎている可能性がありますが、過度の複雑さと相互依存を避けるために、これらのサービスを導入する際には実際の目的を理解することが不可欠です。基本に戻ることで、システムの背後にある主な目的と最も効果的なアーキテクチャに再び焦点を当てることができる場合があります。モノリシック システムは本質的に悪いわけではなく、特定のタスクに完全に適していますが、プロジェクトの規模が大きくなるにつれて、運用のボトルネックになる可能性があります。モノリシック サービスとマイクロサービスのバランスを取ることが重要です。

マイクロサービスの理想的な状況と必要とされないケース

マイクロサービスの成功の明確な例は、アマゾン ウェブ サービスのような企業で見つけることができます。この企業では、チームがこれらのサービスに依存して、400 を超えるさまざまな個別のサービスを含む膨大な製品ポートフォリオを維持しています。対照的に、モノリシックな性質を持つより単純な製品を提供する企業は、製品を多数の個別のサービスに分割する必要がない場合があります。

企業のインフラストラクチャからマイクロサービスを削除した結果

マイクロサービスの実装など、根深いアーキテクチャ上の決定を元に戻すことは困難な場合があり、大規模な再構築が必要になる場合があります。マイクロサービスはサービスと API の分離を提供しますが、それらを削除すると、企業はソフトウェア運用を再評価し、サービスを統合してアーキテクチャを大幅に変更するようになる可能性があります。要約すると、マイクロサービスは最新の IT アーキテクチャで重要な役割を果たします。それらの実装には多くの利点がありますが、レガシーな技術的負債になる可能性など、固有のリスクもあります。組織は、マイクロサービスの影響と、IT ランドスケープの変革におけるマイクロサービスの継続的な関連性を慎重に検討する必要があります。 AppMasterを含む アプリ開発業界は、これらのテクノロジを利用して、さまざまなユース ケースに対応する幅広い柔軟なソリューションを提供しています。