この記事の要点：
- マイクロサービスは手段であり、目標ではありません
- 分散型はデカップリングを保証しません
- コントラクトテストは、マイクロサービスアーキテクチャの重要な部分です
- フロントエンド、バックエンド、統合レイヤー、およびビジネスロジックを分解する必要があります
- 企業がマイクロサービスを迅速かつ独立してリリースする能力を持たない場合、マイクロサービスの利点の多くは失われます
昨年11月のQConPlusで、マイクロサービスが失敗する可能性のあるいくつかのパスについて説明しました。私はIBMコンサルタントであり、私の仕事の一部は、ビジネスがクラウドネイティブになるのを支援することです。この記事で言及されている問題は、私の経験から導き出されたものです。残念ながら、実際には非常に一般的です。
私が最初に目にする問題は、問題が何であるかさえわからないことがあるということです。マイクロサービスを実行する必要があると考えましたが、なぜそれを実行するのかを理解するのに十分な時間を費やしていませんでした。
私たちはどのような問題を解決しようとしていますか？現在、どのような問題が発生していますか？マイクロサービスを実行した後、何が改善されますか？人々は常に新しいことを試みる傾向があり、特に私たちの技術者にとってはそうです。私たちは解決策に飛びつきたい、光沢のある新しいガジェットで遊んでみたい。悲しいことに、私たちが解決しようとしている問題を理解することは非常に重要ですが、新しい解決策を試すよりもはるかに楽しいことではありません。
コンテナは、魔法のテクノロジーであり、優れたソリューションであるため、新しいソリューションを試す傾向を加速させます。それらはとても軽く、とても持ち運び可能で、多くのものをより良くします。結局、私たちは決心しました。「私はすでに非常に多くのコンテナーを持っているので、1つのコンテナーでアプリケーションを実行することは、コンテナーの電力の大きな浪費になります。できるだけ多くのコンテナーで実行する必要があります。それです！」残念ながら、「コンテナが足りない」というのは意味のある問題の説明ではありません。
主導的な開発を再開する
私が目にするもう1つの問題は、履歴書主導の開発です。履歴書を見てみると、「マイクロサービス」と書かれているはずの空白がありました。これでは十分ではないように思われるので、「会社の技術スタックをリファクタリングすることでこれを修正できます」と言います。あなたはおそらく「いいえ、それは誇張です、ホリー。確かに誰も彼らの履歴書のために建築上の決定を下さないのですか？」と思っているでしょう。
コンテナベースの開発努力のトップドライバーを調べたRedHatによる最近の調査では、キャリアアップが最大のドライバーであることがわかりました。いわゆるキャリア開発は、履歴書主導の開発の非常に感情的な知性の声明です。
マイクロサービスは現在の新しい標準であるため、履歴書にマイクロサービス開発の経験がないことは大きな問題です。エピデミック以来、私たちが出発の波に加わっていなくても、また現時点で新しい仕事を探していなくても、私たちは外れ値になりたくありません。周りを見回して、他のすべての人がマイクロサービスを実行しているように見えると、もちろん疑問に思います。全員がマイクロサービスを実行していて、私が実行していなかった場合はどうなるでしょうか。私はこの心理学を「マイクロサービスの羨望」と呼んでいます。
マイクロサービスは目標ではありません
「マイクロサービスの羨望」は問題です。マイクロサービスは私たちが羨ましがるべき種類のものではないからです。私たちのコンサルタントの1人はコツを持っています。クライアントがNetflixについて話していて、マイクロサービスに移行したい場合、彼はパートナーシップに何か問題があることを知っています。彼らがマイクロサービスに移行する正当な理由はほぼ確実にありません。会話がもう少し深くなり、結合や結束などがカバーされる場合、彼はコラボレーションの方向性に問題がないことを知っています。
マイクロサービスの変革の出発点は、マイクロサービス自体であってはなりません。マイクロサービスは、ビジネスの俊敏性/回復力などのより高いレベルの目標を達成するための手段です。実際、マイクロサービスは唯一の手段ではなく、単なるオプションです。
分散モノリス
尋ねなければならない1つの質問：「マイクロサービスを行っているのか、それとも数百のGitリポジトリにモノリスが広がっているのか？」残念ながら、これは私たちが常に目にしていることです。それは分散型のモノリスであり、ひどい存在です。推論するのは難しいです。通常のモノリスよりもエラーが発生しやすくなります。すべてが単一の開発環境内に含まれている従来のモノリスでは、コンパイル時のチェックやIDEリファクタリングのサポートなどのいくつかの利点があります。プロセスでは常に操作を実行しているため、関数は確実に実行されます。これらの分散コンピューティングのバグをわざわざ覚えておく必要はなく、サービスディスカバリについて心配する必要もありません。また、呼び出そうとしているものが存在しなくなった状況に対処する必要もありません。通常のモノマーのさまざまなものは比較的安全です。対照的に、モノリスのセキュリティを削除してもその結合を維持すると、クラウドネイティブのスパゲッティになります。
分配はデカップリングと等しくない
数年前、私は問題のあるプロジェクトの救助任務に呼ばれました。私が到着したとき、チームが私に最初に言ったのは、「1つのマイクロサービスを変更するたびに、他のサービスは中断する」ということでした。マイクロサービスのさまざまな約束に注意を払ってきたのであれば、これは想定されていることとは正反対であることをご存知でしょう。マイクロサービスは独立していて、互いに分離されている必要があります。ただし、システムを分散させるだけの場合、デカップリングは無料ではありません。「分散」と「分離」は、どちらもDで始まることを除いて、共通点はありませんが、同じものではありません。
完全に絡み合って結合されたまま、分散のすべての苦痛を伴う高度に分散されたシステムに巻き込まれるのは簡単です。これが上記の場合に起こったことです。彼らのコードベースを調べ始めたとき、私はすべてのリポジトリで同じコードを見続けました。このアプリケーションのオブジェクトモデルはかなり複雑で、約20のクラスがあり、そのうちのいくつかには70のフィールドがあります。これは複雑なパターンです。
マイクロサービス開発の原則の1つは、DRYを手放し、結合のソースである共通ライブラリの使用を避けることです。この場合、中央オブジェクトリポジトリの結合を回避するために、各マイクロサービスのコードにはオブジェクトモデルのカットアンドペーストコピーがあります。ただし、ドメインパターンがまだ共有されている場合は、結合は避けられません。オブジェクトコードを複製しても、結合は削除されません。コンパイル時のチェックの可能性がなくなるだけです。フィールド名を変更してもすべてが破損しますが、破損は実行時まで発生しません。
この悲しい話は、マイクロサービスにおけるドメイン駆動設計の原則の重要性を示しています。私たちが達成したい理想は、各マイクロサービスがドメインにきちんとマッピングされることです。これの副作用、およびあなたがそれを正しく行っているという兆候は、あなたのマイクロサービスが小さなインターフェースを持つことです。ドメインの境界ではなくテクノロジーの境界に沿って分解すると、私が見たようなものになります。すべてのマイクロサービスには、巨大で壊れやすいインターフェースがあります。結果はスパゲッティの混乱になります。
マーズクライメイトオービター
技術的にはマイクロサービスプラットフォームではなく宇宙船ですが、火星気候オービター宇宙船は、分散とデカップリングの違いの良い例です。NASAは、火星の気候を研究することを使命として、1998年に火星気候オービターを打ち上げました。悲しいことに、宇宙船は火星の周りをうまく周回できませんでした。代わりに、プローブは火星の大気圏に突入しました。NASAの死後調査では、問題は異なるチームによって構築された2つの異なる制御システム間の関係に起因することがわかりました。ほとんどの場合、ステアリングは検出器自体のシステムによって行われます。数日ごとに、オービターが地球の視界に入ると、フロリダの監督管理システムがコース修正を発行します。これはおそらく、システムが実行できる最も分散した設計であり、その一部は宇宙を飛行しています。しかし、2つのシステム間の領域は実際には似ています。どちらもエンジン推力の計算を扱います。2つのチームは、インターフェースがどのように見えるかについてよくわかっていなかったため、異なる測定単位を使用することになりました-宇宙部分のメートル法、地球部分の帝国法、そして災害が発生しました。この場合、システムは非常に分散していると言っても過言ではありませんが、この分散によるメリットはほとんどありません。
消費者主導の契約テスト
上記の微妙なコミュニケーションの問題は、複数のチームが開発に関与しているシナリオでよく発生します。幸いなことに、有用な緩和策があります。それは、消費者主導の契約テストです。IDEがタイプのチェックに役立たないシステムでは、さまざまな統合をテストする必要がありますが、包括的な統合テストを最小限に抑えたいと考えています。統合テストは重く、実行に費用がかかり、脆弱で、本質的に結合されています。マイクロサービスの開発に投資した場合、テスト時に巨大な統合モノリスに頼りたくないことは確かです。では、私たちが構築しているものが実際に機能していることをどのように確信できるでしょうか。
モックは一般的な解決策ですが、独自の問題があります。モックを設定するために、制作チームと消費チームは、開発の開始時に優れたインターフェイスがどのように見えるかについて話し合います。彼らは合意に達し、消費者はモックを書き込もうとします。これは、制作チームがコードがどのように見えるかを示していると彼らは考えています。理想的には彼らはうまくいくでしょう。問題は、彼らがモックを書いたので、彼らがモックに彼ら自身の仮定を入れ、それが彼らが書いたコードではないので、他のコードがどのように見えるべきか、またはそれがどのように振る舞うべきかを知らないかもしれないということです。
運が良ければ、彼らは正しい結果を得るでしょう。ユニットテストはすべて合格であり、統合フェーズでも緑色のライトが続き、すべてが順調です。残念ながら、この運は毎回来るわけではありません。実際の実装は、制作チームが考えを変えたため、または誰かが間違った仮定をしたために、消費チームが理解しているものではない場合があります。この場合、テストは引き続き合格します。ただし、実際に実際のサービスの統合を開始すると、失敗します。問題は、モックの動作が実際のサービスによって検証されていないことです。制作チームは、モックが作成されたのを見たことがない可能性があります。
より良いオプションは、消費者主導の契約テストを行うことです。コントラクトテストの利点、およびそれがモックとどのように異なるかは、両方の当事者がコントラクトテストと対話することです。消費者にとって、契約テストは便利なモックのようなものです。
一方、コントラクトテストはプロバイダーにとって便利な機能テストです。これは、OpenAPIのような単なる構文チェックよりも深い検証手段です。コントラクトテストは、実際にはセマンティックおよび動作チェックでもあり、プロバイダーチームが機能テストを作成する時間を節約します。
すべてに互換性があり、適切に機能している場合、すべての契約テストに合格します。実行が安価で軽量であるため、チームの信頼をすばやく高めることができます。プロバイダーチームが何かを壊した場合、テストは失敗し、壊れた変更が統合環境に逃げる前に早期警告を出します。APIが変更された場合、契約の新しいバージョンが両側（またはそれらを接続するブローカー）で展開されます。
現在、市場にはいくつかの契約テストシステムがあります。春のエコシステムにいる場合、春の契約はうまく機能します。広く手を出す場合は、使用する可能性のあるほぼすべての言語にバインドされているPactをお勧めします。
企業の毛玉
もちろん、すべてのテストの問題を解決したとしても、ビジネスロジックレイヤーに分離されたマイクロサービスの優れたセットがあったとしても、成功する保証はありません。システムには、本当にクリーンなマイクロサービスアーキテクチャを設計するときに考慮しなかった可能性のある他の多くの要素があります。私たちはビジネスロジックにとても興奮し、フロントエンドとバックエンドのこと、そしてすべての接着剤を忘れています。接着剤はエンタープライズアーキテクチャで特に一般的であり、非常に粘着性があります。私たちのアーキテクトの1人は、この状況をエンタープライズヘアボールと呼んでいます。
すべての機能分解作業をビジネスレイヤーに集中させると、モノリシックフロントエンドとモノリシックデータベースレイヤーの間に挟まれた、分離されたマイクロサービスのきちんとした束になってしまう傾向があります。これらのタイプのシステムでは、変更を加えるのが難しい場合があります。ただし、業界の観点からは、データベースをさらに細かく分類して個々のマイクロサービスにマッピングし、さまざまなマイクロフロントエンドを開発しています。
しかし、私たちはまだ分解を終えていません。システムがそれほど複雑でなければ、統合レイヤーがあります。この層はメッセージングを担当する場合もあれば、複雑なシステムをまとめる他の統合ソリューションである場合もあります。アーキテクチャの残りの部分が近代化された後でも、統合レイヤーはモノリシックで柔軟性がない傾向があります。チーム自体は大きなプレッシャーにさらされる可能性があります。私の同僚はそれを「パニックサンドイッチ」と呼んでいます。統合レイヤーはモノリシックであるため、すべての変更を慎重にスケジュールする必要があり、それが他のすべての作業の妨げになります。
この現象は、特に統合チームにとって、多くのフラストレーションを生み出す可能性があります。外の世界には、彼らの努力にもかかわらず、彼らは無反応で遅いように見えます。結合の問題を解決するには、モジュラー統合パターンを採用する必要があります。
統合レイヤー、データベース、フロントエンドレイヤーを分離しないとどうなりますか？私たちのマイクロサービスが望ましい効果を達成しないことはほぼ確実です。毛玉のパーツ間の依存関係により、パーツがすばやく移動できなくなります。ビジネスレイヤーのマイクロサービスを個別にデプロイすることはできず、デプロイのペースは著しく断続的になります。
解放を妨げる負担
これが起こるのを見た人は何人いますか？あなたは本当に一生懸命働き、いくつかの素晴らしいものを作成しました。あなたはユーザーがそれを気に入るはずだということを知っています、しかしそれはまだ彼らの手にありません。価値は棚にあり、あなたの素晴らしい結果を発表することはできません。マイクロサービスアーキテクチャとリリースボードがある場合でも、それについてできることはあまりありません。他のすべてのマイクロサービスは、一緒にテストする必要があるため、同時にリリースする必要があります。テストの大規模なバッチを除いて、それを行うにはコストがかかりすぎます。リリースチェックリストに記入するだけでも費用がかかります。過去に低品質のリリースから学んだため、企業はリリースを恐れています。リリースチェックリスト、リリースボード、シングルスレッドテスト、およびその他のリリースマントラはすべて、認識されるリスクを軽減することを目的としています。リリースの締め切りは組織全体で統一されていたため、締め切り前にすべての機能を詰め込むために時間と競争することになりました。もちろん、これによりリリースのリスクも高まります。誰かが、本来よりも結合されているすべてのマイクロサービス間の依存関係を持つスプレッドシートを追跡しています。もちろん、リリース日も縁起の良い日でなければなりません。マイクロサービスアーキテクチャを選択したとき、このようなジレンマになるとは思っていませんでした。これらの善意のプロセスはすべて面倒であり、ユーザーに価値をもたらすプロセスを遅くし、多くの場合、実際のリスクを高めます。
テスト自動化
なぜこれが起こるのですか？通常、私たちが公開を非常に恐れている理由は、公開プロセスに多くの手作業が含まれているためです。本当に自信を与えるテストが自動化されていないことが特に重要です。そのため、アプリケーションが正しく機能しているかどうかを確認するために多くの作業を行う必要があります。クライアントを訪ねて「テストが自動化されていない」と不満を言うのを聞くと、「コードが現在機能しているかどうかわかりません。問題ないかもしれません。前回手動でQAを実行しました。それでも正常に動作することを願っています。」これは悲しい状況です。
あなたがそれを気にするなら、それを自動化してください-あなたが気にかけるべきなのは品質です。特に、アーキテクチャがスパゲッティになり、カップリングが忍び込んだ場合、ブレークポイントが発生する可能性があります。スパゲッティに行くのは難しいので、迅速なフィードバックを提供できる場所の早い段階でブレークポイントを見つけたいと思います。スパゲッティを作る場合は、少なくともテスト済みのスパゲッティを作ってください。
リリースサイクル
人間によるテストは、リリースプロセスの一部にすぎません。規制対象の業界またはコンプライアンスに重点を置いた業界では、ほとんどの場合、手動のコンプライアンスジョブが多数発生します。コンプライアンスは私たちが非常に気にかけていることなので、自動化する必要があります。
これらすべての手動プロセスとすべての面倒さにより、クラウドにデプロイしているにもかかわらず、クラウドネイティブが約束するメリットを享受できないことを意味します。私たちが使用している雲は、美しい雲のようには見えません。皮肉なことに、クラウドでは、私たちが行った良いこと、良いアイデア、私たちをより安全にしたことは、実際に私たちを傷つけています。レガシーガバナンスメカニズムはクラウドでは機能しません。それは私たちが望むビジネス成果をもたらさず、クラウドが持つべきビジネス上の利点の多くを私たちから奪います。
企業のリリースサイクルを見れば、企業がクラウドコンピューティングによって約束されたメリットを実現しているかどうかを簡単に確認できます。数年前、私の同僚が大手の伝統的な銀行と営業会議を行いました。彼らの市場シェアは、フィンテック企業や新興のチャレンジャーバンキングのライバルに食われています。ビジネスはまた、なぜ彼らが負けているのかを知っていました-彼らは市場に十分な速さで追いつくことができなかったからです。彼らは私たちのところに来て、たくさんのCOBOL資産を持っていると説明し、それが彼らを引きずり下ろしているのです。（これはおそらく真実です。）次に、他のすべての人がマイクロサービスを実行しているため、明らかにすべてのCOBOLを削除してマイクロサービスに移行する必要があると付け加えています。それから彼らは彼らのリリース委員会は年に2回しか会合しないと言います。この時までに私の同僚の心は半分寒かった。リリース委員会が6か月ごとにのみ開催される場合、リリースのリズムは6か月ごとになることがわかります。独立してデプロイ可能なマイクロサービスがいくつあるかは関係ありません。このような遅いペースは、敏捷性を得ることができないことを意味します。
この銀行が必要とする支援は、実際には技術的なものではありません。リスクについての考え方や運営方法を変える必要があります。リリーススケジュールは完全に見直す必要があり、多くの自動化が必要です。継続的デリバリーにおける規律の欠如が彼らを阻んでいるのです。COBOLはただの犯人です。
「デカップリングしたい」は一般的なクライアントの要求ですが、デカップリングは複数のことを意味します。これは、分離されたアプリケーションが必要な場合のモジュール性を保証するものではありません。時々それは混乱がより広く広がっていることを意味します。面倒なリリースボードや時代遅れのプロセスなど、外部の制約がある場合は、それらの問題を解決するまでデカップリングするかどうかは関係ありません。