" SANDER HUGENDORN（オランダ） -メンター、トレーナー、ソフトウェアアーキテクト、プログラマー、スピーカー、ライター。
彼は大規模なITコンサルティング会社と20年間協力しており、現在Capgeminiで働いています。 さまざまな国からの多数のクライアントが、彼をソフトウェア開発の革新の「アクティベーター」として評価しています。
サンダーは、組織、チーム、プロジェクト、および個人のコーチでした。 アジャイル、スクラム、かんばん、ソフトウェア評価、ソフトウェアアーキテクチャ、マイクロサービス、デザインパターン、モデリングとUML、コードの作成とテストなど、さまざまなトピックに関する過去15年間の300を超えるトレーニングコースを開催しました。
英語の元のインタビューは、 Sanderのブログに掲載されています。
マイクロサービスを使用する必要がありますか？
Andrey Gordienkov：あなたの記事では「マイクロサービス。 あなたは、開発のさまざまな側面を説明しました。 読者は、マイクロサービスアーキテクチャを使用すると次のようになると思われるかもしれません。
- 企業にはさまざまな技術の専門家が必要です。 これは、従業員数の増加またはトレーニングのコストの増加につながる可能性があります。つまり、予算に影響します。
- 個々のコンポーネントの相互作用と統合のセットアップの難しさは時間がかかる場合があります。
- 会社には、さまざまな技術と実践の経験を持つアーキテクトが必要です。 つまり、そのような専門家を見つけるか「成長させる」必要があります。 そのような専門家は高価になることがあり、会社は彼に依存するようになりますが、そのような専門家の負荷は十分ではないかもしれません。 また、病気の休暇などに行くと、プロジェクトが中断する危険もあります。 マイクロサービスの使用は、費用がかかりすぎ、リスクが大きすぎるようです。 プロジェクトを台無しにすることさえできます。
質問は次のとおりです。マイクロサービスを使用する価値があるのか、なぜマイクロサービスがアーキテクチャの未来なのか？
Sander Hugendorn：マイクロサービスアーキテクチャの使用は、ソフトウェア開発だけではありません。 多くの異なる役割が密接に連携して、構築中のシステムを設計、構築、テスト、展開する学際的なアプローチが必要です。 これには、アーキテクトだけでなく、アナリスト、デザイナーも含まれます。そのタスクは、ドメインを限定されたコンテキストに分解し、コンポーネントが提供するAPIを設計することです。 また、システムを運用環境に展開する作業も含まれます。 これは1回限りのイベントではなく、新規および更新されたアプリケーションとコンポーネントの継続的なストリームです。 そのため、マイクロサービスアーキテクチャを実現するには、モデリング、ソフトウェアアーキテクチャ、自動テスト、APIの設計と展開、主題指向の設計、継続的デリバリーなど、多くのトピックに関するさまざまなスキル、知識、経験が必要です。 最後に重要なことですが、各コンポーネントは異なる言語とテクノロジーを使用して構築できるため、最終的にテクノロジーのパッチワークになります。 ただし、上記の考慮事項のため、これはお勧めしません。 多くの異なる言語とテクノロジーの使用は必須ではありません。
マイクロサービスへの移行の適切性は、自分でどこにアクセスするかに大きく依存します。 私のクライアントの1人が、メインフレームを削除しようとしています。 メインフレームから新しいマイクロサービスアーキテクチャまで、すべての機能を徐々に再構築しています。 彼らにとって、システムの小さな部分を次々に供給する能力は非常に貴重であり、それを行う方法に関連した進行中の研究とコストを正当化します。 別のクライアントにとって、マイクロサービスの最も重要な部分は、700万行のコードで構成される複雑にサポートされたシステムを、単一のシステム内の限られたコンテキストに付随するよりもはるかに優れた数に分割できることです。 個々のデプロイ可能なコンポーネントには移行しません。
最初にモノリシックシステムを構築する方が良いと思いませんか？
A.G。：最近のブログ投稿で、Martin Fowlerは最初にモノリスを構築する方が良いと述べました。ドメインの境界を理解し始めたら、アプリケーションを最適な方法でマイクロサービスに分割できます。 このアドバイスについてどう思いますか？ あなたの練習でそれを使用しましたか？
S.Kh。：前の質問への回答で述べたように、マイクロサービスが適用される場合と適用されない場合が多くあります。 マイクロサービスのために努力するかどうかを決めるのに役立つ黄金律はないと思います。 私が言及したクライアント-メインフレームを削除したいクライアント-は、最初にモノリスを構築しません。彼らは試しましたが、システムが非常に大きく、メンテナンスが難しく、プロジェクトが失敗しました。 また、この試みでは限られたコンテキストを認識できなかったためです。
マイクロサービスの良いところは、小さなコンポーネントと限られたコンテキストの観点から考えることです。 私の意見では、これは、すべてを個別にデプロイするか、システムをモジュールに分割するために使用するかに関係なく、このアーキテクチャスタイルを使用する最大の利点の1つです。 マーティン・ファウラーは当初、文字通りモノリスを構築することを意味していなかったのではなく、ドメインをモジュールに分割することが重要であることを強調しようとしました。
アプリケーションを小さなパーツに分割すると、マイクロサービスアーキテクチャになりますか？
A.G。：アプリケーションを小さな部分に分割し、同時に動作する場合、どのように関係なく、マイクロサービスアーキテクチャと呼ぶことができますか？ それとも単なるパッチワークですか？ マイクロサービスアーキテクチャを真のアーキテクチャにしているものは何ですか？
S.Kh。：個人的に、何かがマイクロサービスアーキテクチャであるかどうかはあまり気にしません。 プロジェクトが「柔軟」であるかどうかを本当に気にしないように。 問題は、提案されたアイデアやコンセプトを活用できるかどうかです。 アジャイルが連続的な優先順位付け、短い反復、および学際的なコマンドを使用する場合、それらがスクラム、XP、スマート、またはクリスタルクリアと呼ばれるかどうかはあなたにとって本当に重要ですか？
私の意見では、大規模なシステムを小さな独立した部分に分割し、それらの間に明確な境界を定義することは価値があります。 また、これにより、安定性メカニズムやデータベースのタイプなど、さまざまなテクノロジーを選択できます。 いずれにせよ、デプロイ可能なコンポーネントは継続的な配信を促進し、高いスケーラビリティを提供しますが、すべての人に適しているわけではありません。 したがって、マイクロサービスアーキテクチャと呼ぶことができるかどうかに関係なく、アイデアと概念を活用してください。
マイクロサービスを開発する際に適切なツールを使用することの価値はどれくらいですか？
A.G。：マイクロサービスの開発において、適切なツールを使用することがどれほど価値があるかについてのビジョンを共有できますか？ マイクロサービスアーキテクチャの適切な管理と開発を支援およびガイドできますか？ 悪名高いパターンを避けるために、おそらく、コンポーネントがどのように相互接続されており、この大きな汚れのボールが実際にどのように機能するかを少しも考えていない場合、理解できますか？ 「特効薬」はないことは知っていますが、開発者が開発中に優れたAPIを使用してガイドするのと同じように、ツールは開発者を支援できます。 Swagger、APIary、ネームストレージ、MQブローカーを意味します-あなたはアイデアを得ると思います。 メモ帳でコードを書くことはできますが、逆効果です。 繰り返しになりますが、ツールは開発者を導き、バカな間違いを避けるのに役立ちますか？
S.Kh。：まず第一に、あなたのために仕事をするツールはありません。 マイクロサービスアーキテクチャを実装するときは、よく考えて、さまざまな方法とテクノロジを多数使用する必要があります。 マイクロサービスはかなり新しいものであるため（はるかに長く存在すると主張する人もいますが）、メーカーが収益を上げる機会を見つけたときに役立つツールが登場します。 Go-CDなど、展開パイプラインの継続的な配信と構成を整理するための新しいツールが既に登場しています。 SwaggerのようなAPIとドキュメントを開きます。 メーカーは、主にクラウドに基づいたマイクロサービスアーキテクチャの実装に関するプロセスを完全に自動化するためのツールを作成し始めると思います。 統合開発環境（IDE）は、最高のマイクロサービス開発サポートを提供します。 しかし現在、ほとんどの組織はかなり柔軟なプロジェクトですでに知っているかなり伝統的な開発ツールを使用しています。
マイクロサービスアーキテクチャトレーニングに参加する価値があるのはなぜですか？
A.G .: 9月25日にモスクワで、 「マイクロサービスアーキテクチャの設計、開発、テスト、展開」に関するトレーニングを実施しています。 なぜ訪問する価値があるのか、マイクロサービスに切り替えない企業にとってどのように役立つのかを説明してもらえますか？ 結局のところ、サムニューマンの本「Building Microservices」を購入して、指示に従うだけです。 それで十分でしょうか？
S。 したがって、本は良いスタートです。 しかし、マイクロサービスへの道で遭遇する問題の実例を見るために、私のようなトレーニングコースに参加することは常に役立ちます。 トレーニングコースでは、マイクロサービスの基本、その利点と欠点を紹介します。 マイクロサービスの使用を検討する場合としない場合のさまざまなシナリオについて説明します。 コンポーネントとサービスの設計、ビジネスプロセスの自動化、「スマート」ユースケース、限られたコンテキストでのサブジェクト指向の設計など、企業環境でマイクロサービスを使用するアプリケーションの作成に焦点を当てます。設計および構築。 自動テストの使用など、APIの設計とマイクロサービスのテスト方法について詳しく説明します。 展開パイプラインのセットアップとマイクロサービスの展開について説明します。 これらはすべて、実際の例（および面白いジョーク）で説明されます。 ですから、マイクロサービスを（まだ）作成していなくても、私のトレーニングコースから多くのことを学ぶことを願っています。