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

.NET (以前の .NET Core) はオープンソースの開発プラットフォームで、Linux および Windows で実行される、クロスプラットフォームのクラウドおよびコンソール・アプリケーションを構築できます。

.NET には、.NET Core、.NET Framework、Xamarin/Mono という 3 種類のプラットフォームがあり、異なる場所で .NET コードを実行できます。.NET Core はクロスプラットフォーム実装で、Windows、Linux、macOS 上のどこでも実行できます。.NET Framework は .NET のオリジナルの実装で、Web サイト、サービス、デスクトップ・アプリケーションなどの Windows 上での実行をサポートします。Xamarin/Mono はモバイル向け .NET で、iOS および Android を含めた、すべての主要モバイル・オペレーティングシステム上でアプリケーションを実行します。

マイクロソフトが Linux を重要なプラットフォームとして受け入れるまで、.NET は元々クローズドソースで Windows 専用でした。

モダナイゼーション戦略を計画する

今では .NET はオープンソースになり、複数のプラットフォームで利用できるようになりましたが、既存のソリューションが .NET Framework (Windows 環境でのみ動作) である場合には問題が発生します。.NET Framework は、最終的には Linux 環境にモダナイズする必要があります。 

多くの企業は、レガシーワークロード、基盤となるプラットフォームやテクノロジー、従来の開発手法が、ビジネスの俊敏性とイノベーションを妨げていると感じています。これは、レガシーシステムが、クラウド・コンピューティングやクラウドネイティブの開発プラクティス、Linux コンテナなどの最近の技術が登場する前に開発されたものだからです。しかし、これらのワークロードの多くは依然としてビジネスクリティカルな位置を占めており、簡単に交換したり終了させたりすることができない重要な長期投資として活用されています。

このため企業は、これらのシステムを維持する必要性と、革新したい、顧客からの新たな期待に応えたい、新しい機会に取り組みたいといった欲求との間でバランスを取る必要があり、難しい立場に置かれています。これらのレガシー・アプリケーションは、維持するために非常に多くの時間、予算、リソースを必要とする可能性があるため、イノベーションの大きな障害となります。

ワークロード・モダナイゼーションの目的は、レガシーワークロードにアジリティを復活させることです。これを実現するために、レガシーワークロードを最新のプラットフォームに移行し、モノリスをマイクロサービスのような保守しやすい小さなコンポーネントに分割し、最新のソフトウェア開発とデプロイメントの手法を適用し、古いものと新しいものを統合します。

メリット

既存の .NET ワークロードをより先進的なプラットフォームに取り込めるかどうかは、開発者がどの程度の作業量を引き受け、その過程でチームがどの程度変化を受け入れられるかにかかっています。こうしたことを念頭に、ワークロードをモダナイズすると以下のようなメリットがすぐに実現します。

• スケーラビリティの改善：.NET ワークロードは需要に応じてスケーリングできるようになります。 
• 信頼性の向上：.NET ワークロードは、安定性とレジリエンスが向上した環境で、より高い信頼性で実行されるようになります。 
• セキュリティの強化：.NET ワークロードは既存のクラウドプラクティスに従い、セキュリティ対策を強化できます。
• コストの削減：混在環境への自動化の導入を強化して、コストを削減できます。 

コンテナ化と Kubernetes は十分開発が進んできたので、.NET を任意のサーバー上でコンテナ化することができるようになりました。ビジネスニーズに基づいて、最適なモダナイゼーション戦略を選択できます。予算と制約によっては、ワークロードの種類ごとに異なる戦略が必要になる場合もあります。この取り組みのメリットをすべて引き出すために、ユーザーからフィードバックを収集してモダナイゼーションへの投資の妥当性を証明するという段階的なアプローチが適している場合もあります。
既存の .NET アプリケーションをモダナイズするには、以下の 3 つの方法があります。

1. リホスト：業界では「リフトアンドシフト」と呼ばれるリホストは、オンプレミス・アプリケーションを修正することなくクラウドに移行し、クラウド・インフラストラクチャ対応のプラットフォームに移動させるプロセスです。この移行アプローチでは、現行のオンプレミス・アプリケーションは Infrastructure-as-a-Service (IaaS) プラットフォームに移行またはリホストされます。アプリケーションの構成は以前とほぼ同じですが、クラウド内の仮想マシン (VM) にデプロイされています。この戦略が使用されるのは、短期間で製品を発売する、オンプレミス・データセンターを廃止するなど、特定のビジネス目標を満たすために大規模アプリケーションを移行する場合がほとんどです。
2. プラットフォーム再構築：このレベルでは、コンテナや追加のクラウドマネージド・サービスなどの先進的テクノロジーでアプリケーションをクラウドで実行することからさらなるメリットを得られます。コードを大幅に変更することなくクラウドに対して最適化できます。この成熟度モデルでは、コンテナを IaaS または Platform-as-a-Service (PaaS) にデプロイしながら、データベース、Cache-as-a-Service、監視、継続的インテグレーション/継続的デプロイメント (CI/CD) パイプラインに関連する追加のクラウドマネージド・サービスを使用できます。.NET アプリケーションを Windows コンテナとしてプラットフォームの再構築を行うと、 .NET アプリケーションのコア・アーキテクチャを変更せずにコンテナ・テクノロジーのメリットを得られます。
3. 再構築：再構築により、PaaS サービスを使用してアプリケーションを PaaS コンピューティング・プラットフォームに移行します。クラウドネイティブ・アプリケーションとマイクロサービス・アーキテクチャを実装することで、長期的なアジリティを備えたアプリケーションを進化させ、デマンドに応じて容易にスケーリングすることができます。この種類のモダナイゼーションでは一般に、新規コードを作成してクラウド専用に構築することが必要になります。このアプローチでは、モノリシックでオンプレミスのアプリケーション環境では達成が困難なメリットを実現することができます。モノリシック・アプリケーションを小規模なサービスに分割することで、各サービスが 1 つの目的について機能し、コンテナとしてデプロイされます。マイクロサービスベースのアプローチに準拠できれば、コンポーネントが .NET で構築されていようと Java で構築されていようと、すべて RHEL と OpenShift Container Platform でサポートされた共通プラットフォ－ム上で実行できます。

既存の手法、ツール、プロセスについて Windows Server を標準的に使用しているなら、Linux、コンテナ、Kubernetes を加える必要があるでしょう。これは画期的ですが、既存のビジネスに影響を及ぼす可能性がある変更を伴うため、腰が引けることもあります。 

Red Hat は、変更が必ずしも簡単でないことを理解しています。Red Hat のビジネスの本質は、テクノロジーの変化に直面するお客様が戦略とソリューションを導入してビジネス目標を達成し、チームが環境、テクノロジー、プロセスの変更に対処できるように支援することです。

お客様がどのようなモダナイゼーション戦略を選び、制約に基づいてどのような種類のメリットを求めているかにかかわらず、Red Hat は Microsoft Azure Red Hat OpenShift (ARO) などの製品とサービスを提供します。