で 前のブログ、私たちはコンウェイの法則が優勢となり、エンタープライズ DevOps の世界ではマイクロサービスが不可欠であると結論付けました。つまり、DevOps に真剣に取り組む人は誰でも、マイクロサービスの定義方法、管理方法、メリットの最大化方法、問題を最小限に抑える方法を学ぶ必要があります。さまざまなテクノロジーとさまざまなユースケースに最適なマイクロサービスを設計する方法を知ることが重要です。このブログでは、マイクロサービスがビジネスを最適な方法でサポートする方法の概要を説明します。

マイクロサービス アーキテクチャとは何ですか?

James Lewis と Martin Fowler は、マイクロサービス アーキテクチャの最も優れた定義を示しています。

マイクロサービス アーキテクチャ スタイルは、大規模なアプリケーションを一連の小規模なサービス (IT コンポーネントまたはアプリ) として構築するアプローチを提供します。各サービスは次のようになります。

• ビジネス能力を中心に構築されている
• 独自のプロセスを実行する
• 軽量なメカニズムを介して通信し、
• 自動展開装置によって独立して展開可能

最終的に、マイクロサービスはビジネスの柔軟性を促進するはずです。これは、新しい機能のリクエストが 1 つのマイクロサービスのみに影響を与える可能性が最大限に高ければ実現され、DevOps チームは問題を迅速に解決し、自動化によって迅速に再テストし、マイクロサービスを再デプロイできるようになります。

機能的マイクロサービスとは何ですか?

機能リクエストのほとんどはエンドユーザーから来るため、ほとんどのマイクロサービスは機能指向になります。機能リクエストには通常、GUI、ロジック、ワークフロー、データの変更が含まれるため、これらすべての部分を同じデプロイ可能なものにするマイクロサービスを設計すると、変更の影響を最小限に抑えることができます。

設計には、技術的な考慮事項以外にも多くの要素が含まれます。機能範囲を適切なマイクロサービスに分割するための最適な基盤は通常、ビジネス プロセスであることがわかっています。つまり、アーキテクチャを定義するには、ビジネス オーナーとプロセス アーキテクトを関与させる必要があるということです。

技術的なマイクロサービスはまだ必要ですか?

いくつかのマイクロサービスは、より技術的指向があり、明確で安定した要求応答インターフェースを介して呼び出し可能です。機能の一部が多くの目的で同じである必要があり、あまり頻繁に変更されない場合は、別のより「技術的な」マイクロサービスに分割できます。

その他のマイクロサービスは、他のサービスを調整するための統合指向であったり、他の大規模システムや外部パーティへの接続を担当したりすることがあります。サービスの効率化につながる場合は、中央の ESB は、独自のビジネス データを保持できる分散型の特殊なマイクロサービスに置き換えられることがよくあります。

企業は、マイクロサービスができること、すべきことについてオープンな姿勢で臨むべきです。あるビジネス分野に最適なマイクロサービス アーキテクチャが、別の分野にも必ずしも最適であるとは限りません。これは、設計上の決定をチーム レベルで委任することが多い DevOps と一致します。

再利用しすぎたり、これが SOA バージョン 2.0 だと考えたりしないことが重要です。この重要なトピックについては、近日中に別のブログで詳しく説明する予定です。

コンポーネントのサイズはビジネスの俊敏性にどのように影響しますか?

マイクロサービスの場合、10 ～ XNUMX 人の DevOps チームが約 XNUMX ～ XNUMX 個のマイクロサービスを所有、構築、運用、管理する必要があると多くの人が言います。マイクロサービスの設計では、サイズは比較的柔軟です。

小規模から比較的大規模な範囲では、ビジネスが求めているよりも小さな部分に分割する必要はありません。たとえば、チームとアーキテクチャを、サポートするビジネス機能に合わせて調整することで、最大限の自律性を実現し、簡単に進化して価値を生み出すことができます。

ただし、「システム」の範囲が非常に大きい場合は、機能を個別のマイクロサービスに分割する方が常に効果的です。何年にもわたる時間的に重要な修正や近道によって不要な依存関係が生まれると、内部および外部の依存関係が増大します。システムを変更するのは難しく、リリースやデプロイメントごとに重要な回帰テストを行うのはコストがかかり、リスクも伴います。

図 2: モノリス アーキテクチャでは、ユーザー グループが注目を集めようと争い、開発者が互いの足を引っ張り合います。

マイクロサービスの理想的なサイズは、開発者の数に関係します。つまり、HPA プラットフォームは、後で分割したり、マイクロサービスを大きくしたり、チームを小さくしたりできるため、オープンソースよりも有利です。

何ですか マイクロサービス？

マイクロサービスに関する柔軟な見方を推進してきたので、現在行われているものと比較するのは理にかなっています。 マイクロサービス:

• モノリスは大きすぎるため、マイクロサービスではありません。モノリスには 10 人以上の開発チームが必要で、(通常は) 同じデプロイ可能なシステム内に機能的に分離されたプロセスが多数存在します。このため、より多くの回帰テストとより長いリリース サイクルが必要になります。依存関係はサイズと時間とともに大きくなり、マイクロサービス アーキテクチャのようにサービス呼び出しによって明示的に示されることはありません。
• ビジネスデータが ESB の下にある階層型 SOA アーキテクチャもマイクロサービスではありません。同じデプロイ可能なユニット内にビジネス機能に必要なデータと機能が含まれていません。代わりに、ほぼすべてのビジネス機能は、共有デプロイ可能なユニットの技術的に重点を置いた複数の「レイヤー」にまたがっています。NGINX によると:SOA は「可能な限り多くを共有する」アーキテクチャ スタイルの概念に基づいて構築されていますが、マイクロサービスは「可能な限り少なく共有する」アーキテクチャ スタイルの概念に基づいて構築されています。」 マイクロサービスは自律的でビジネス機能を果たす必要があるため、必要に応じてデータを保存するための GUI、ロジック、ワークフロー、データベースが必要です。

図 4: マイクロサービスは、他のパターンよりも優れた柔軟性とビジネスと IT の連携を促進します。

私たちの見解: マイクロサービスの共通の特徴

マイクロサービスは、通常のビジネス プロセスの一部としてビジネス機能を実行し、相互に通信するため、技術者以外の人にも理解しやすくなっています。これは、DevOps やチームの意思決定にとって良いことです。私たちの見解では、優れたマイクロサービスには、次の共通の特性が必要です。

1. プロセス指向

機能的なマイクロサービスは通常、ビジネス プロセスのフェーズまたは完全なビジネス機能を実装します。「サービス」という名前は誤解を招きやすいものです。マイクロサービスは呼び出し可能なサービスになることもありますが、エンド ユーザーの機能に重点を置いたアプリになることもあります。

2. 自律性と柔軟性

マイクロサービスは個別に開発され、個別にデプロイされ、独自のデータを含む必要があります。時間の経過とともに進化し、変更や再デプロイが容易である必要があります。

3. 自動化と制御

マイクロサービスには、適切なテストとデプロイメントの自動化、エラー処理、監視とアラート機能が必要であり、ユーザーからのフィードバックを許可する必要があります。

4. 適切なサイズ

「マイクロ」という言葉もやや誤解を招きやすいですが、マイクロサービスは小さすぎても大きすぎてもいけません。サービスは10人程度の開発者で比較的大規模にすることができます。モノリスよりは小さいですが、通常のアプリより小さくする必要はありません。 Mendixマイクロサービスは、ほぼ中規模企業の中核システムになり得ます。

マイクロサービスはあなたにとって何を意味しますか?

マイクロサービスが適切に実行されれば、ビジネスと IT の連携が促進され、運用プロセスの柔軟性が向上します。以前のパラダイムでは、ビジネス プロセスの変更が非常に困難だったため、ほとんどの既存企業にとってデジタル化は非常に困難でした。DevOps とマイクロサービス アーキテクチャは、決定と開発をローカライズすることでこの問題を解決します。DevOps チームはビジネスと直接連携し、自律的に決定を下します。マイクロサービスは依存関係を最小限に抑えて個別に開発され、自律的なユニットとして個別に展開されます。

Mendix マイクロサービスに関するオンサイト ワークショップとトレーニングを提供しています。当社は、意思決定のサポートを提供し、各ビジネス上の問題に対する最適なソリューションの検討を通じて、多数のお客様の新しいプログラムや取り組みを支援してきました。 詳細はお問い合わせください.