アジャイル手法と継続的な改善が現代の開発チームのデフォルトになるにつれて、マイクロサービスの人気が高まっています。多くの複雑なビジネスは、厳格なモノリシック ソフトウェアから柔軟なマイクロサービス アーキテクチャに移行しています。
しかし、マイクロサービスとは何でしょうか?また、マイクロサービスアーキテクチャはビジネスにどのように価値を付加するのでしょうか?
マイクロサービスアーキテクチャとは?
マイクロサービスアーキテクチャ 最も広くは、他の機能サービスからアーキテクチャ的に分離された一連の機能要素を処理する 1 つのプロセスとして定義されます。言い換えれば、マイクロサービスアーキテクチャは、大規模で複雑なソフトウェアまたはテクノロジーを、個別にデプロイでき、疎結合された小さなサービスに分割されるアーキテクチャスタイルです。
マイクロサービスは分散され、疎結合されているため、1 つのサービスを変更してもアプリ全体が壊れることはありません。これにより、開発チームは、ビジネスのニーズの変化に応じて、新しいコンポーネントや機能をアプリケーションに迅速に導入できます。
「マイクロサービスアーキテクチャ」という用語は、ソフトウェアアプリケーションを独立してデプロイ可能なサービスのスイートとして設計する特定の方法を表すために、ここ数年で登場しました。このアーキテクチャ スタイルに正確な定義はありませんが、組織とビジネスの機能、自動デプロイ、エンドポイントのインテリジェンス、言語とデータの分散制御など、特定の共通の特性があります。
-マーティン・ファウラー、ソフトウェア開発のソートリーダー、著者、ThoughtWorksのチーフサイエンティスト
マイクロサービスアーキテクチャは、アプリケーションやプラットフォームをそのコア機能、つまりサービスに分割します。
たとえば、eコマースプラットフォームには、製品、注文管理、在庫管理から、検索、支払い、ロイヤルティ管理に至るまで、さまざまな機能に対応するマイクロサービスがあります。これらのマイクロサービスは、ビジネスのニーズに応じて、個別に、または一緒に消費できます。マイクロサービスアーキテクチャを利用している開発チームは、絶え間ない変更をよりシームレスに行うのに適していると感じています。
マイクロサービスアーキテクチャとモノリシックアーキテクチャの比較
モノリシック アーキテクチャは、データベース、ユーザー インターフェイス、サービス側アプリケーションの 3 つの部分で構成される 1 つのユニットとして構築されたアプリケーションをサポートします。モノリシック アプリケーションに変更を加えるには、開発者は、サーバー側アプリケーションの完全に別の更新バージョンを開発してデプロイする必要があります。
一方、マイクロサービスアーキテクチャは、コアビジネス機能をカプセル化するAPIを介して表現されます。マイクロサービスベースのアプリケーションのインターフェースは、ビジネスによって定義されます。マイクロサービスはビジネスのニーズに基づいて引き込まれ、開発の観点から非常に適応性が高く機敏なアプリケーションを作成します。
モノリシックアーキテクチャでは、各アプリケーションが他のアプリケーションと関連して動作します。一方、マイクロサービスアーキテクチャでは、各マイクロサービスはそれ自体が明確に定義された機能を持つAPIであるため、独立して機能できます。
モノリシック アーキテクチャでは、1 つの変更がアプリケーションの多くの側面に影響を与える可能性があるため、カスタマイズのリスクが高くなります。マイクロサービス アーキテクチャ アプローチでは、他のユーザーを中断することなく、既存のマイクロサービスを強化したり、新しいマイクロサービスをデプロイしたりできるため、カスタマイズが促進されます。
モノリシック アーキテクチャの機能強化、更新、アップグレードは、アプリケーションに組み込まれた緊密な結合と依存関係のために、多くの場合、より高価で労力がかかります。マイクロサービスアーキテクチャは、ニーズの変化に応じて、新しいマイクロサービスやAPIを介して拡張できる無限の可能性を提供します。
マイクロサービスアーキテクチャの利点は何ですか?
マイクロサービス アーキテクチャは、通常、より効率的で効果的な開発チームを作成します。
1.アプリケーションの構築、デプロイ、保守が容易
マイクロサービスアーキテクチャの中核となるのは、システムのデプロイとプロセスを簡素化することを目的としています。本質的に、アプリケーションは、より小さな消費可能なサービスに分割されると、構築、デプロイ、保守が容易になります。さらに、各マイクロサービスが個別のコードであるため、開発チームにとってコードの管理が容易になります。各サービスは、それぞれを個別にデプロイ、更新、管理できるように、異なる言語を使用して実装できます。最後に、マイクロサービスで問題が発生した場合、各マイクロサービスは独立しているため、アプリケーションの他の部分にリスクはありません。
2.ビジネス能力を中心に組織化
開発チームは、アプリケーション全体のコードを一度に書くことに集中するのではなく、さまざまなマイクロサービスを利用して、個別にビジネス機能に集中することができます。開発チームがマイクロサービス アーキテクチャを使用すると、各メンバーは特定の機能に集中でき、多くの場合、より効率的で効果的な開発チームが作成されます。彼らの出力は、すべての部品が本来あるべき姿で正確に機能するように設計されたアプリケーションであり、各ビジネスに固有のものです。
3.スケーラビリティ、俊敏性、スピードの向上
マイクロサービス アーキテクチャは、「これは私のビジネスに合わせて拡張できるか」という古くからのテクノロジーの問題に取り組んでいます。 マイクロサービス アーキテクチャは、アプリケーションをより小さく管理しやすいサービスに分割しているため、アプリケーションの開発が速くなり、管理が容易になります。開発サイクルが短縮されるため、デプロイと更新の頻度が高くなります。また、さまざまなチームが、バックエンドにリスクを持たずにコンポーネントに取り組んでいたり、別のコンポーネントが特定のポイントに到達するのを待ったりする必要もありません。
4.焦点を絞ったチームと小さなコードベース
マイクロサービスでは、コードとデータが共有されないため、更新や機能を追加するために触れる必要のあるコードの量が減ります。これには 2 つの利点があります。(1)バックエンドへのリスクが軽減され、(2)更新と機能を迅速に展開できます。また、コードベースが小さいため、開発チームは小さく集中でき、俊敏性が向上します。
マイクロサービスアーキテクチャの2つの頻繁な「落とし穴!」:
すべてのテクノロジーとアーキテクチャにおいて、開始する際に考慮すべき重要な点と注意すべき点が常にあります。
1.開発には思慮深いオーケストレーションが必要
マイクロサービスアーキテクチャでは、アプリケーション全体の有効性を確保するために、サービス間の依存関係を特定するのに時間が必要です。ビルドの観点からは、マイクロサービス アーキテクチャでは、1 つのビルドを完了すると、他のサービス間でビルドがトリガーされる可能性があることに注意してください。
2.テストして、テストして、またテスト!
統合とエンドツーエンドのテストは、より困難で重要になる可能性があります。これは、1 つのマイクロサービスで障害が発生すると、相互にサポートするようにサービスをどのように設計したかによっては、将来的に別の障害が発生する可能性があるためです。
Sitecore OrderCloud プラットフォームとアーキテクチャについては、機能ガイド.