アプリケーションのモダナイゼーションとは

現在、アプリケーションのモダナイゼーションに関する議論の多くは、モノリシックなオンプレミス・アプリケーション（通常はウォーターフォール開発プロセスを使用して更新および保守される）と、それらのアプリケーションをクラウド・アーキテクチャーとリリース・パターン（つまりマイクロサービスとDevOps）に組み込む方法に焦点が当てられています。

アプリケーションのモダナイゼーションを行うメリットには、一般的に、新機能を提供するまでの時間を加速できること、既存アプリケーションの機能を公開してAPI経由で他のサービスが利用できるようにすること、アプリケーションのスケールとパフォーマンス、および長期的なデータセンターとIT戦略を目的としてアプリケーションをオンプレミスからクラウドに再プラットフォーム化すること、などがあります。

アプリケーションのモダナイゼーションの課題は、一般的にコストと複雑さに関連しています。ROIを考慮せずにアプリケーションをオンプレミスからクラウドに移行するなら、単にアプリケーションを移行するだけです。しかし、アプリケーションによっては、プラットフォームの再設計や再アーキテクチャー化によって大きなメリットを得られるかもしれませんが、既存のシステムやインフラストラクチャと非常に密接に結びついているため、モダナイゼーションの複雑さがメリットを上回る可能性があります。

アプリケーションのモダナイゼーションを成功させる鍵は、他のほとんどのことと同様に、クラウド、スピード、パフォーマンス、スケール、新機能の開発などのメリットが、特定のアプリケーションに顧客体験とROIの向上への明確な道筋を提供するアプリケーション・モダナイゼーション・プロジェクトを選択すること、そして戦略にかかっています。

レガシー・アプリケーションも、多くの場合モノリシック・アプリケーションです。モノリシック・アプリケーションには、更新が難しく、拡張が困難でコストがかかるという2つの特性があるため、モダナイゼーションがお勧めです。

モノリシック・アプリケーションは、アーキテクチャー上の理由から更新が困難です。アプリケーションは付随するコンポーネントが同時に出荷されるため、複雑さと統合による課題と関連したオーバーヘッドを考慮すると、機能の追加は困難かつコストがかかります。

同様の理由から、スケーリングは困難でコストがかかります。アプリケーションの1つのコンポーネントでも負荷とパフォーマンスの課題に直面している場合は、最も要求の厳しい1つのコンポーネントに対応するためだけにアプリケーション全体をスケールアップする必要が生じる可能性があります。このアプローチでは、かなりのコンピューティングが無駄になります。

アプリケーションをマイクロサービス・アーキテクチャーにモダナイズすることで、コンポーネントはより小さくなり、疎結合になり、互いに独立してデプロイおよびスケーリングできるようになります。独自の課題はありますが、このアプローチにはモダナイゼーションのコア価値の多くが見出せます。

アプリケーションのモダナイゼーション・プロジェクトを開始する最も重要な方法は、アプリケーションの評価です。現在所有しているものの一覧を作成することは、このようなトランスフォーメーションに着手する第一歩として重要です。

リストを作成したら、すべてのアプリケーションを容易さ/難易度と、モダナイズした場合の潜在的な価値の増加をx、y軸に対してプロットすることができます」また、「潜在的な」価値とは、アプリケーションが顧客体験や組織の将来にとってどれほど重要であるかということと考えることもできます。

このグリッドの右上の象限、つまり高価値かつ低労力の象限に該当するアプリケーションは、アプリケーションのモダナイゼーション・プロジェクトを開始する理由となることに疑いの余地はないでしょう。

最も難しい決定は、移行が難しい高価値アプリケーションに関するものです。こうしたアプリケーションでは、初日からオール・オア・ナッシング戦略を取る必要もありません。このような場合、リスクとコストを削減しながらポートフォリオを正しい方向に進めることができるアプリケーションのモダナイゼーションのためのアプローチがあります。

アプリケーションのモダナイゼーションには、プラットフォーム、アプリケーションのアーキテクチャー、API経由でのアプリケーションの機能の公開の組み合わせに重点を置いた、よく知られたアプローチがいくつかあります。

アプリケーションのモダナイゼーションで最も一般的なアプローチは、モノリシック・アプリケーションをリファクタリングして、疎結合された小さなマイクロサービスのコレクションに分割するものです。

上記のマイクロサービス・アーキテクチャーの例では、小売アプリケーションが単一のn層アプリケーションから、アプリケーション内のすべての個別のサービス（それぞれにデータベースとデータ・モデルがある）のマイクロサービスのコレクションに分割されました。

この分野での1つのアプローチは、「ストラングラー・パターン」として知られています。ストラングラー・パターンでは、モノリスを一度にすべて分解するのではなく、アプリケーションを少しずつ分解し、最初に最も簡単で価値のある部分を取り出します。このアプローチが進むにつれて、最終的にモノリスは何も残りません。

多くの場合、マイクロサービスへのリファクタリング、アプリケーションの再プラットフォーム化、または再ホスティングは、モダナイゼーション・プロセスの一部です。大幅な書き換えを行わずにアプリケーションを単にリフト・アンド・シフトすることは可能ですが、多くの場合、コンテナとKubernetesを活用して、クラウド・モデルをより有効に活用できるようにアプリケーションを再構築することに価値があります。（クラウド移行の詳細については、こちらをご覧ください。）

最後に、モダナイゼーションのもう1つのアプローチとして、アプリケーションをそのまま残しながら、その機能やデータをAPI経由で安全に公開する方法があります。このアプローチは移行よりも統合を重視しており、新しいクラウドネイティブアプリケーションが既存のシステムとデータの機能を簡単に利用できるようになります。

ほとんどの組織が進めている近代化プロセスを促進できるテクノロジーのポートフォリオは多岐にわたります。

パブリッククラウドはあらゆるモダナイゼーション戦略の重要な部分ですが、プライベートクラウド、ハイブリッドクラウド、マルチクラウド戦略も、セキュリティー、レイテンシー、アーキテクチャー上の理由から極めて重要です。

さまざまな理由から、組織はデータセンターからパブリッククラウドに直接移行する準備ができていない場合があります。他のクラウド・モデルは、特定のワークロードの固有の特性に基づいて、そのワークロードを配置する場所と関連したアーキテクチャーとポリシーの複雑さをすべて解決するのに役立ちます。

コンテナとKubernetesは、クラウド内の汎用コンピューティングの形態として仮想マシン（VM）の代替テクノロジーとしてだけでなく、ハイブリッドクラウドとアプリケーションのモダナイゼーション戦略を実現する重要なテクノロジーとして登場しました。

コンテナ化により、アプリケーションを一貫性のある軽量な方法でパッケージ化できるため、デスクトップ、クラウド、オンプレミスの環境で一貫して実行できます。このような柔軟性は、クラウドで前進する道筋を計画している組織にとって大きなメリットとなります。