アプリケーション・モダナイゼーションとは、既存のレガシー・アプリケーションを使って、それらのプラットフォーム・インフラストラクチャー、内部アーキテクチャー、機能をモダナイゼーションするプロセスです。 今日のアプリケーション・モダナイゼーションに関する議論の多くは、モノリシックなオンプレミスのアプリケーション（典型的には、ウォーターフォール開発プロセスを使用して更新し保守されるもの）と、それらのアプリケーションをクラウド・アーキテクチャーとリリースのパターンにどう組み込むか、つまりマイクロサービスとDevOpsに焦点を当てています。 

アプリケーション・モダナイゼーションのメリットは、通常、新機能の提供速度の向上、他のサービスがAPIを介して消費するための既存のアプリケーションの機能の公開、さらに、アプリケーションの拡張性とパフォーマンス、長期的なデータセンターとIT戦略を目的としたオンプレミスからクラウドへのアプリケーションのリプラットフォームと要約できます。

アプリケーション・モダナイゼーションの課題は、通常、コストと複雑さということになります。 ROIを考慮せずに、アプリケーションをオンプレミスからクラウドに移動するということは、アプリケーションをただ移動するために移動していることになります。 逆に、リプラットフォームやリアーキテクチャーから有意義なメリットが得られる可能性があるアプリケーションもありますが、既存のシステムやインフラストラクチャーと非常に密接に結合しているため、モダナイゼーションの複雑さがメリットを上回る可能性があります。

アプリケーション・モダナイゼーションを成功させるためには、他の場合と同様に、最終的に戦略とアプリケーション・モダナイゼーション・プロジェクトの選択が鍵となります。これらの戦略とプロジェクトでは、クラウドのメリット、スピード、パフォーマンス、規模、新機能の開発などが、特定のアプリケーションに顧客体験とROIの向上のための明確な道筋を示すものになります。

レガシー・アプリケーションは、多くの場合、モノリシック・アプリケーションでもあります。 モノリシック・アプリケーションには、モダナイゼーションを行うことが望ましいとされる2つの特徴があります。それは、更新が難しいことと、拡張が困難で費用がかかることです。

モノリシック・アプリケーションは、アーキテクチャー上の理由から更新が困難です。 1つのアプリケーションのコンポーネントがすべて一緒に出荷されるため、複雑さと統合の課題にかかる手間を考えると、機能を追加することは困難で、コストもかかります。

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

1つのアプリケーションを複数のマイクロサービス・アーキテクチャーへとモダナイズすることにより、各コンポーネントはより小さくなり、疎結合され、互いに独立したデプロイメントと拡張が可能になります。 このアプローチでは、複数の独自の問題が伴う一方、モダナイゼーションにおける重要な価値の多くを見出すことができます。

次の動画では、マイクロサービスのアーキテクチャーについて詳しく説明しています。

アプリケーション・モダナイゼーションのプロジェクトを開始する際に、最も重要なことは、アプリケーションを評価することです。 変革を始めるために、手持ちのインベントリーを使用することは当然と言えます。これはほぼすべての変革に当てはまります。

リストができたら、x 軸とy 軸で示す難易度と、モダナイズされた場合に増加する潜在的な価値について、すべてのアプリケーションをグラフに示していくことができます。 「潜在的な」価値とは、そのアプリケーションが顧客体験とお客様の組織の将来にとってどの程度重要であるかを示すものとも考えられます。

このグリッド・グラフは価値の高さと労力の少なさを示しており、その右上に分類されるアプリケーションは、アプリケーション・モダナイゼーションのプロジェクトを開始するための、明らかに有力で異論の少ない候補になります。

最も難しい決定は、移動が難しい高価値のアプリケーションに対するものなります。 こうした決定について、プロジェクト開始当初にやるかやらないかの二者択一の戦略を取る必要はありません。 このような場合、お客様のポートフォリオを正しい方向に進めながら、リスクを軽減しコストを削減できる、アプリケーション・モダナイゼーション向けアプローチが複数あります。

アプリケーション・モダナイゼーションについては、プラットフォームの組み合わせ、アプリケーションのアーキテクチャー、APIを介したアプリケーションの機能の公開に焦点を当てている、よく知られたアプローチが少数あります。

モノリシックからマイクロサービスへ。 アプリケーション・モダナイゼーションの最も一般的なパターンでは、モノリシック・アプリケーションのリファクタリングと小さく疎結合されたマイクロサービスへの分割が行われます。

上記のマイクロサービス・アーキテクチャーの例では、n層を持つ1つの小売アプリケーションがマイクロサービスのコレクションに分割されます。マイクロサービスはアプリケーション内の個々のサービスに対応し、それぞれ独自のデータベースとデータ・モデルを備えたものです。 

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

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

APIを介した機能の公開

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

ほとんどの組織が経験しているモダナイゼーションのプロセスを促進できるテクノロジーの幅広いポートフォリオがあります。

プライベートクラウド、ハイブリッドクラウド、マルチクラウド

パブリッククラウドがモダナイゼーション戦略の重要な部分であると同時に、プライベートクラウド、ハイブリッドクラウド、マルチクラウドの戦略も、セキュリティー、遅延、アーキテクチャー上の理由から非常に重要です。  

さまざまな理由で、組織がデータセンターからパブリッククラウドに直接移行する準備ができていない可能性があり、特定のワークロードをそれぞれの特性に基づいて稼動させる必要がある場合、そこに関連するアーキテクチャーとポリシーの複雑さをすべて解決するために、パブリッククラウド以外のクラウド・モデルが役立つことがあります。

コンテナとKubernetes

コンテナとKubernetesは、クラウド内の多目的コンピューティングの一形態としての仮想マシン（VM）に対抗するものとしてだけでなく、ハイブリッドクラウドとアプリケーション・モダナイゼーションの戦略の主要なイネーブラーとして登場しました。     

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