モノリシックアプリケーションの謎を解く

モノマーって不思議な響きですね。世界中の何千もの組織では、モノリシック アプリケーションが独立して並んで存在し、謎と畏怖に満ちていることがよくあります。モノリシック アプリケーションは現代のビジネスに不可欠な要素であり、バック オフィスからサプライ チェーン、顧客サービスからビジネス エンゲージメントまで、あらゆる重要なビジネス プロセスに重要な役割を果たします。

これらのモノリスは引き続きビジネスに大きく貢献していますが、これらのアプリケーションの最新化は、イライラさせられる、苦痛なトピックです。多くの組織は諦めましたが、一方で、一時的な対策として、再配置または再構築 (昔ながらの「リフト アンド シフト」) によってモノリス全体をクラウドに移行した組織もありました。 2022 年には、新たな希望、新たなテクノロジー、新たなアプローチにより、モノリシック アプリケーションを取り巻く謎が解明されます。

神話その1: モノリシックな近代化は失敗に終わる

すべてのクラウド プロバイダー、クラウド ネイティブ プラットフォーム、システム インテグレーターには、モダナイゼーション用語集のほぼすべての「R」を含むモデルがあります。当初、業界には近代化のための 5 つの R、つまり再ホスト、リファクタリング、再設計、再構築、または置き換えしかありませんでした。近代化が成熟し、より多くのコンサルタントが関与するようになるにつれて、再プラットフォーム化、書き直し、保持、廃止など、R の数が増加しました。これは混乱を招きます。モノリスの近代化プロセスには、データ、数学、自動化はほとんど適用されていません。書籍やベストプラクティスがあり、アドバイスや提供を喜んで行うコンサルタントやソリューション アーキテクトも多数います。これらは素晴らしいスタートですが、多くの場合、DIY アプローチまたは高価でリスクの高いアウトソーシングに重点が置かれます。

すべて DIY またはすべてアウトソーシングのオプション間のギャップを埋めるために、新しいツール、応用 AI、自動化の波が適用されています。これらのアプローチの基礎は、モノリスの実際のアーキテクチャ分析に基づいており、新しいバージョンに移行する必要のある基盤となるプラットフォーム コンポーネントだけでなく、実際のビジネス ロジック自体も含まれます。ビジネス ロジックはアプリケーションの中核であり、アーキテクトはここから、より明確なマイクロサービス ドメイン駆動設計につながる領域を特定し始めることができます。少なくとも、これらのサービスは、より独立したミニサービス、または単に排他性のレベルが高い共通サービスを表しています。基本的なデータ駆動型アプローチが欠如しているため、アプリケーション チームはモダナイゼーションから離脱し、暫定的な対策として移行戦略を選択することになり、これが落とし穴 2 につながります。

誤解その2: モノリスをクラウドに移行する = モダナイゼーション

アプリケーションをクラウドに移行することは魅力的な目標であり、IT チームとアプリケーション チームをより大きな目的に向けて結集させる「ムーンショット」ビジョンです。しかし、明確に言えば、移住は近代化と同じではありません。モノリスをクラウドに移行すると、DevOps とデータ センター削減の大きなメリットが得られます。これらの短期的な利益はほぼすべての組織によって実現され、その結果、企業のワークロードのクラウドへの移行を加速および簡素化したいと考えているクラウド プロバイダーに思わぬ利益をもたらしました。多くのテクノロジーリーダーが犯す間違いは、自分たちの仕事は終わった、私たちはもう現代的だ、と考えることです。

この誤解はすぐに払拭されました。クラウド内のモノリスは、オンプレミス展開と同じ厄介な問題、つまりエンジニアリング速度の遅さ、スケーラビリティの欠如、メンテナンスの難しさ、持続可能性の低さに悩まされていることが、今ではほとんどの組織にとって明らかです。コストが上昇し始め、クラウドのメリットが依然として手の届かないものとなっているため、多くの人がこの段階を「リフトアンドシフトの後悔」または「移行の後悔」と呼んでいます。

この誤解を解くには、移行をより大規模で戦略的な近代化戦略の文脈で検討し、計画する必要があります。包括的な近代化への足がかりである限り、移行は問題ありません。モノリスを最新化することで、コンテナやマイクロサービスから Kubernetes やサーバーレスに至るまで、クラウドネイティブ アーキテクチャの価値を最大限に活用できるようになります。これに、一般的な CI/CD、セキュリティ、DevSecOps 戦略とプラットフォームを活用するメリットを加えると、ビジネス ケースはすぐに整います。これが神話 3 につながります。

誤解その3: アプリケーションのモダナイゼーションに関する正確なビジネスケースを構築することは不可能である

ほとんどの組織にとって、アプリケーションのモダナイゼーションで最も難しいのは、モダナイゼーション プロジェクトの正確なビジネス ケースを構築することです。誤解 1 では、この問題を解決するために欠けている要素の 1 つ、つまり、時間と労力を予測するアーキテクトと予算とリソースを承認するビジネス リーダーの間で議論するためのデータに基づく基盤が欠如していることについて検討しました。共通の言語と測定基準が欠如していたため、リーダーシップと経営陣の間の信頼は双方向で崩壊しました。このサイクルを断ち切るには、まずデータと測定が必要です。

まず、測定モノリスの複雑さと、モノリスの変更に伴うリスクを分析します。複雑さを理解するには、まず依存関係のコミュニティまたはクラスターを特定する必要があります。これは、どの領域が独特で、マイクロサービスに抽出できるかを示します。複雑さは、クラス間の依存関係がどの程度絡み合っているかによって計算できるため、コードのモジュール性のレベルが低下します。リスクは依存関係チェーンの長さによって測定できます。依存関係チェーンの長さによって、アプリケーションの一部の変更が下流のアプリケーションの無関係な部分にどの程度影響するかが決まります。これらすべてを総合的に技術的負債スコアにまとめると、負債とイノベーションに対する現在の支出が示され、近代化プロジェクトの ROI と TCO のビジネス ケースのメリットが示されます。この強力な定量的スタンスにより、ビジネスの優先順位を合わせることがはるかに簡単になり、それが神話 #4 の打破につながります。

誤解その4: すべてのモノマーは同じように作られている

モノリスにはさまざまな形やサイズがあり、商業的価値も複雑さも大きく異なります。実際、モノリシック アーキテクチャは、さまざまなユース ケースに適した最新の設計モデルになります。簡単な最初のステップは、スタック内のモノリスを現在のビジネス価値に基づいて分類することです。ビジネス上の有用性とエンジニアリング負荷、機能のバックログ、メンテナンス コストを評価します。通常、チームの規模、バックログ機能の数、メンテナンス コストはエンタープライズ モノリスのビジネス価値と一致する必要があり、これらは一致している必要があります。実際、これらのモノリスは、企業やそれをサポートするエンジニアリング チームにとって第一級の存在であり続けるため、「レガシー」というレッテルを貼られることはありません。ビジネス価値が低下している老朽化したモノリスは、単純な再編成または最終的な廃止に最適です。

アプリケーションが依然としてビジネスに貢献できるものである場合は、その複雑さと最新化に伴うリスク (誤解 3 を参照) を徹底的に評価して、最善の計画を策定し、より正確なビジネス ケースを作成する必要があります。これらの重要なビジネス ユニットの複雑さ、リスク、および結果として生じる技術的負債を計算することで、AI ベースの自動化ツールを使用して、それほど複雑でない部分をより高速なアプリケーション モダナイゼーション プロジェクトに移行し、プロセスを加速できます。より複雑なモノリス (多くの場合「メガリス」と呼ばれます) では、より多くの時間がかかり、より反復的なリファクタリング アプローチに従う必要があります。つまり、ストラングラー パターンを使用してモノリスから新しいサービスに制御を切り替え、一度に 1 つまたは 2 つのマイクロサービスを選択的に抽出します。これらのモノリシック アプリケーションは、クラウド内であってもどこにでも存在できます。

誤解その5: モノリスは内部の問題である

確かに、この一枚岩の多くは今も内部に残っており、元のインフラストラクチャにしっかりと固定されています。しかし、ますます多くのモノリスがクラウドへの移行に成功し、クラウド プロバイダーの IaaS インフラストラクチャで実行され、プロバイダーのパワー、CPU、メモリを使用していますが、残念ながら、それらは依然としてモノリスとして実行されています。クラウド内のこれらのモノリスはしばらくは正常に動作するかもしれませんが、スケーラビリティの問題が発生すると、唯一の解決策は、コストを増大させてより大きなイメージ（より多くの CPU とメモリ）を購入することだけになります。これらには、より高価な予約インスタンスが必要になる可能性があり、クラウド エンジニアはこれを常にレッドライン レベルで実行する必要があります (弾力性や水平スケーラビリティはありません)。

上で説明したのと同じデータ駆動型の評価および優先順位付けのアプローチは、クラウド内のこれらのモノリスに完全に関連しており、おそらくそれ以上に関連があります。なぜ？データ駆動型評価、AI を活用した最新化、移行後のリファクタリングは、すべてのソリューションおよびソフトウェア アーキテクトに求められる重要な機能です。クラウド内のモノリスは、その現代的な運命を完全に実現することに非常に近づいています。モノリシック リファクタリング プロセスが完了すると、コンテナー、Kubernetes、DevOps、サーバーレス、サービス メッシュ サービスをクラウド上で起動できるようになります。

神話6: モノリシックな依存関係は解きほぐせない

責任下にあるモノリスの近代化はもちろん、維持管理を任されている建築家たちは、深刻な課題に直面している。ほとんどの場合、彼らは元の設計者や開発者ではなく、たとえそうであったとしても、モノリスは時間の経過とともに進化し、ますます多くの技術的負債を抱えることになり、元の意図の多くが埋もれてしまう可能性があります。これらの複雑なモノマーには多くの類似点があります。

AIが役立ちます。システムがモノリスの深い依存関係をグラフとして表現できる場合、グラフ機械学習は潜在的なドメイン アクティビティ コミュニティを形成するクラスターとリンクを検出できます。これにより、複雑さと変更リスクの理解から、潜在的なマイクロサービスとコミュニティ間の境界の実際の検出まで、さまざまな利点がもたらされます。それをサポートするグラフとモデルを構築するには、動的分析と静的分析を組み合わせる必要がありますが、最終結果はより効率的で効果的な近代化の取り組みになります。モノリスの近代化が可能になり、予測可能性と速度が向上します。

神話その7: モノリシックな近代化は決して終わらない

上記の 6 つの誤解を払拭した後、これらのヒントに従えば、時間と予算は近代化の要因にならないことが明らかになるはずです。ここで議論すべきは、ビジネス上の利益と成果をもたらすためにどのような近代化を達成できるかということです。明確な評価とデータに基づく計画によって、近代化へのアプローチ方法も決まるはずです。より複雑なアプリケーションでは、反復的で選択的なリファクタリング戦略に従う必要があります。これにより、それほど複雑ではないビジネスクリティカルなモノリスは、プロセスをより速く進めることができます。

過去 10 年間、アプリケーションの最新化は、広範なトレーニングと文化的および組織的な変更を必要とする、労働集約的なベスト プラクティスでした。これらのプラクティスは重要なスキルですが、自動化とサポートツールが不足しているため、スキルギャップと失敗疲れによりプロセスが停滞しています。ここでは、これらのアプローチを採用し、AI と自動化を通じて次のレベルに引き上げる新しいツールをいくつか紹介します。次のステップは、CI/CD パイプラインにプラグインし、アプリケーションのライフサイクル全体にわたって技術的負債を検出して修正する継続的なモダナイゼーション アプローチを展開することです。