Java アプリケーションをデプロイするために適切な Azure サービスを選択する
この記事では、Java アプリケーションのデプロイに Azure サービスを使用する方法について説明し、多様な Java テクノロジとアーキテクチャに対する Azure のサポートを中心に説明します。 「リフト アンド シフト」、コンテナー化、サービスとしてのプラットフォーム (PaaS) などの展開方法の概要を説明します。これは、さまざまな制御とシンプルさのレベルに合わせて調整されています。
この記事では、A + B の考え方を支持し、固定の A または B の選択よりもアプリケーションのニーズに基づいてサービスを選択することをお勧めします。 これは、柔軟なアプローチのために、ユース ケース、ビジネス目標、セキュリティ、予算を検討することを提案します。 この記事では、開発者エクスペリエンスを強化するための Java エコシステム リーダーとの Microsoft のパートナーシップについて説明し、ソース、バイナリ、コンテナーのいずれとしてでも、Java アプリケーションをデプロイするための Azure サービスをお勧めします。 この微妙なアプローチは、デプロイ戦略に最適な Azure サービスを Java アプリケーションに提供し、効率、スケーラビリティ、およびコスト効率を最大化するという Microsoft のコミットメントによってサポートされるイノベーションに集中するのに役立ちます。
確実かつ簡単に Java アプリケーションをデプロイする
Java エコシステムには、Java SE、Jakarta EE (Java EE と J2EE の後継)、Spring、多数のアプリケーション サーバー、その他のフレームワークなど、さまざまなテクノロジが含まれています。 Java を使用して行っているあらゆること (アプリの構築、フレームワークの使用、アプリケーション サーバーの実行など) について、Azure は豊富な選択肢でそのワークロードをサポートします。 同様に、Azureは、VM またはコンテナーで実行しているモノリシック アプリケーションからフル マネージド サービスで実行しているクラウド ネイティブのマイクロサービス ベースのアプリケーションまで、あらゆるアプリケーション アーキテクチャをサポートしています。
Azure には、さまざまなレベルの制御とシンプルさに合わせて調整された、クラウドで Java アプリケーションを実行するための次の 3 つの主要な方法が用意されています。
「リフト アンド シフト」アプローチを使用すると、既存のアプリケーションを Azure Virtual Machines に直接最小限の変更で移行できます。
コンテナ化は柔軟性を提供します。Azure Kubernetes Service (AKS) と Azure Red Hat OpenShift は、コンテナ化されたアプリを調整するためのメイン プラットフォームです。
サービスとしてのプラットフォーム (PaaS) は、容易さと効率性の頂点を表し、最適な開発者の生産性と運用管理性を提供し、多くの場合、最も経済的な総保有コストと組み合わせて提供します。
Java アプリケーション開発の段階に関係なく、Azure には要件を満たす互換性のあるクラウド ソリューションが用意されています。 これらのオファーの詳細については、「自信を持って簡単に Java アプリケーションをデプロイする」を参照してください。
Java アプリケーションの完全な移植性: どこでもシームレスにデプロイ
Java アプリケーションに対して選択する Azure サービスに関係なく、アプリケーションの柔軟性が保証されます。 Java コードとそのコンパイル済み出力があるため、ローカルの開発マシン、ビルド サーバー、オンプレミス環境、または任意のクラウド プラットフォーム上の任意の場所にアプリケーションを自由にデプロイできます。 アプリケーションの移植性が手に入ります。
もちろん、選択肢が非常に多い場合は、ジレンマに直面します。
ジレンマ – Java アプリケーションにサービス A または B を使用する
Azure のオファーに移動すると、Java アプリケーションを実行するために最適な Azure サービスを選択するジレンマが発生する可能性があります。 この選択は、リソース計画、予算、プロジェクトタイムライン、そして最終的にはアプリケーションの市場投入までの時間に影響するため、非常に重要です。 この決定は、初期デプロイ コストだけでなく、継続的なメンテナンス コストにも影響します。
以前、組織は、ソフトウェア アプリケーションの 2 つのプラットフォーム、テクノロジ、または競合するソリューションを選択せざるを得ないとよく感じていました。 たとえば、WebLogic または WebSphere for Java Enterprise アプリケーション、コンテナ管理用の Docker Swarm または Kubernetes、デプロイ用のコンテナと仮想マシン (VM) のどれを使用するかを組織が決定する必要がありました。 この意思決定プロセスは「A または B の考え方」と呼ばれ、A/B テストとは大きく異なります。これは、2 つのバージョンの Web ページまたはアプリを相互に比較して、どちらが優れているかを判断する方法です。 代わりに、このコンテキストでの A または B の考え方は、アプリケーションのデプロイ用にプラットフォームまたはテクノロジを選択することです。 これは、パッケージ化されたソフトウェア配信モデル、インフラストラクチャとソフトウェア ライセンスへの多額の先行投資、アプリケーション プラットフォームの構築とデプロイに必要な長いリード タイムなどの要因によって決定が制約されることが多い、従来のオンプレミスのプラクティスに由来します。
この考え方を Azure に導入すると、すべてのアプリケーションに対応しようとする単一のプラットフォームの作成に過剰な時間がかかる可能性があり、遅延や非効率性が生じる可能性があります。 ただし、Azure はより有利なアプローチを提供し、この制限の厳しい考え方から両方の世界のベストを受け入れるものへの移行を促進し、最終的に投資収益率 (ROI) を向上させます。
Azure に移行すると、クラウド環境には柔軟なパラダイムが用意されており、ニーズに応じてリソースをプロビジョニングおよびプロビジョニング解除できるため、別のサービスを選択する必要がなくなります。 この柔軟性は、より広範で包括的な考え方を奨励することで、従来の A または B の考え方から逸脱する戦略である A+B アプローチを導き出します。 Azure では、複数のサービスの利点を組み合わせて、A +B の考え方を採用することが簡単でコスト効率の高い方法で、この移行を容易にします。 このアプローチは、アプリケーションの特定のニーズに最も合ったサービスを選択するという原則を強調しています。基本的には、手元のジョブに適したツールを選択することを支持しています。
A+B の考え方への移行により、組織は意思決定プロセスと技術戦略を広げ、この考え方が提供する新しい可能性と機会を受け入れることが可能になります。 この記事では、A + B の考え方の原則を説明し、アプリケーションの要件に最も効果的に関連する Azure サービスを慎重に選択できるようにします。 Azure Spring Apps、Azure App Service、Azure Container Apps (ACA)、Azure Kubernetes Service、Virtual Machines のいずれであっても、A+B の考え方によって、アプリケーションをホストするための Azure サービスの配列から評価および選択できる緯度が付与されます。 この理念は、言語とフレームワークの境界を超越して、普遍的に適用可能です。 ここでは Java アプリケーションが中心ですが、A + B の考え方は、任意のプログラミング言語で開発されたアプリケーションにも同様に関連性があり、有益です。
A +B の考え方を採用することで、事前に定義された 1 つのサービスに限定されることはありません。 代わりに、アプリケーションの固有の要求に最も適した方法でサービスを組み合わせることができます。 このアプローチにより、柔軟性とスケーラビリティが向上するだけでなく、コストと運用効率も最適化されます。 このアプローチにより、技術的な戦略は、運用しているクラウド環境と同じくらい動的で適応可能になります。
サービス A または B について考える必要がない理由
アプリケーションに適したクラウド サービスを選択することは、クラウドが提供するオプションの柔軟性と幅の広さ (特に Azure) により、サービス A とサービス B の間で二項決定である必要はありません。 次のセクションでは、従来の「一方または他の」選択肢にこだわりを持つ必要がない理由と、より流動的なアプローチを採用することで運用にメリットがある理由を説明します。
古い習慣から新しい柔軟性まで
従来、IT システムの展開には、長いセットアップ時間と共に、ハードウェアとソフトウェアに多大な先行投資が必要がありました。 この環境では、1 つのプラットフォームを慎重に選択し、その周りのすべてを最適化してコストとリソースを節約することが論理的になりました。 ただし、Azure を含むクラウド環境では、オンデマンドで柔軟な性質を持つパラダイム シフトが導入されています。 使用した分だけ支払いを行い、ニーズに合わせてリソースを調整することは、初期資本支出の負担なしに簡単になります。
クラウドへの移行
クラウド、特に Azure に移行すると、インフラストラクチャとプラットフォームの責任の管理方法が大きく変わります。 次の図に示すように、以前は組織が担う最も難しくて手間がかかる部分の多くが Microsoft に移行します。 この変更により、操作が簡略化され、アプリケーションの管理に必要な労力が削減されます。 複数のプラットフォームを管理する制約に縛られるのではなく、余分なコストや複雑さを気にすることなく、各ジョブに最適なツールを選択できます。
次の図は、顧客とクラウド プロバイダー間の共同責任モデルを示しています。
各ニーズに最適な選択
この新しいクラウド中心の世界では、意思決定プロセスでは、すべてのニーズを 1 つの事前に定義されたサービスに適合させるのではなく、適切なジョブに適したツールを選択します。 Azure Kubernetes Service と Azure Spring Apps for Spring Boot アプリケーション、またはその他のサービス セットのどちらを選択する場合でも、フォーカスは各特定のアプリケーションの要件を最もよく満たすものに移行します。
マイクロサービスの増加
マイクロサービスの導入により、この柔軟なアプローチがさらにサポートされます。 設計上、マイクロサービスは各サービスに最適なテクノロジの使用を奨励し、A+B の考え方に自然に合致する技術的多様性を促進します。 このアプローチでは、さまざまなサービスの長所を使用して、より堅牢で効率的でスケーラブルなアプリケーション アーキテクチャを構築します。
A +B を採用する利点
A +B の考え方を採用すると、いくつかの重要な利点が得られます。 これにより、機敏性と柔軟性が向上し、運用の各側面に最適なツールとサービスを選択できます。 このアプローチは、リソースとコスト効率の向上につながるだけでなく、製品の市場投入までの時間を短縮します。 最終的に、このアプローチは、テクノロジの選択をビジネスのニーズと目標に合わせて調整することで、運用的卓越性を促進します。
要約すると、クラウドと Azure は、アプリケーションのデプロイと管理に関する新しい考え方を提供します。 制限の厳しい A または B の選択から離れ、A +B の考え方を採用することで、アプリケーションの特定のニーズに合った意思決定を行い、効率、機敏性、コスト削減を実現できます。
A+B の考え方への移行に関する実用的なガイダンス
次の一覧は、A + B の考え方に移行し、それを続行するためのガイドラインとして使用できるいくつかの重要な原則を一覧しています。
ソリューションからユース ケースなく、ユース ケースからソリューションの順に進めます。 多くのソフトウェア チームは、最初にテクノロジを決定し、ユース ケースと設計を強制的に適合させようとします。 多くの場合、このアプローチでは、コスト、開発時間、リソース、運用コストの面で大きなオーバーヘッドが発生します。 ソリューションに進む前に、機能と非機能の両方でユース ケースと要件を明確にします。
ビジネス目標、ビジネスと競争の性質、新機能を運用環境にロールアウトする必要がある頻度を理解します。 ビジネスの目標と目標を達成するために、常にソリューションを設計する必要があります。
セキュリティとコンプライアンス要件を把握します。 インターネット経由ですべてがアクセスされるクラウドの時代には、セキュリティは非常に重要であり、交渉不可能です。 また、サービスを提供する業界によっては、アプリケーションが特定のコンプライアンス要件を満たす必要がある場合があります。 高度なセキュリティ攻撃に対処し、コンプライアンス要件を満たすようにソリューションを設計する必要があります。
予算とタイムラインを理解します。 初期開発、進行中の運用、および将来のリリースに関する予算を明確に理解してください。 さらに、タイムラインを理解します。 遅延プロジェクトのコストは、多くの場合、余分な費用とビジネスへの悪影響の両方の点で、過小評価されがちです。 予算とタイムラインの両方を満たすようにソリューションを設計します。
必要に応じて、クラウドネイティブと考えてください。 クラウドネイティブのアーキテクチャとテクノロジは、クラウドに組み込み、クラウド コンピューティング モデルをフル活用するワークロードを設計、構築、運用するためのアプローチです。 クラウドネイティブを使用すると、アプリケーションを構築して運用環境に迅速にデプロイできます。 クラウドには、弾力性、世界規模、高度な分析、AI、機械学習 (ML) 機能など、オンプレミスでは不可能な機能も用意されています。 可能な限りクラウド ネイティブ テクノロジに基づいてソリューションを設計します。
DevOps 文化について考える。 DevOps とは、ただのツールやプロセスではなく、開発と運用の間の連携を促進するソフトウェア開発プラクティスで、ソフトウェア配信にかかる時間を短縮し、信頼性を高めます。 この DevOps は、一般に「文化」と呼ばれ、継続的に価値を提供するために、人、プロセス、およびテクノロジを結び付けます。
ビジネス要件と非機能要件を満たすソリューションを選択します。1 つは次のとおりです。
- 最速で実装できます。
- スキルアップ、構築、デプロイ、運用に関連するコストの観点からコスト効率が高くなります。
- 操作が簡単です。
- 自動化と完全に互換性があります。
- 設計による DevOps のサポート。
これらの原則は、ソリューションを所定のプラットフォームに強制的に適合させるのではなく、ビジネス目標を満たすソリューションを構築する上で、必要な場所に焦点を合わせ続けるのに役立ちます。
例外
他の場合と同様に、A + B には例外があります。 以下の一覧は網羅的ではありませんが、発生する可能性のあるいくつかの例外に関する方向性のガイダンスを提供します。
エンタープライズ戦略。 たとえば、一部の企業では、複数のプログラミング言語を使用し、すべてのアプリケーションを統合された方法でビルドしてデプロイする必要があるため、コンテナーのエンタープライズ全体の導入を使用してアプリケーションをビルドおよびデプロイしています。
実行にあたり極端に未来的です。 A + B 分析を実行する前に、ソリューションを選択する場合があります。 既にソリューションの実行に深く取り組んでいる場合は、続行しますが、次のアプリケーションでは、A + B の考え方の原則を使用して、ユース ケースに適したソリューションを選択します。
大規模なデータ センターの移行。 クラウドへの移行を加速するために、企業は一般的に、Azure Migrate などのツールを使用してサーバーを一括で (アプリケーションをホストする) サーバーを Azure に移行する「リフト アンド シフト」と呼ばれる戦略を使用します。 このアプローチを使用して、データ センターを Azure に移行し、効率的でコスト効率の高い方法でシャットダウンする場合があります。 このシナリオでは、A + B の考え方を使用して、Azure に移行した後でアプリケーションを最新化することをお勧めします。
重要な考慮事項
考え方のフレームワークと、アプリケーションに適した Azure の宛先を選択するために使用できる原則を提供しました。 すべてに適合する 1 つのサイズではありません。 A または B ではなく、A + B です。
次の図は、任意のアプリケーションに対して Azure サービスを選択するための主な考慮事項をまとめたものです。
Java アプリケーションに対して適切な Azure サービスを選択する
Azure 上の Java アプリケーションの多数のテクノロジ オプションの中で選択プロセスを効率化するために、開発者、顧客、システム インテグレーターが最適な Azure サービスを利用できるように、シンプルなデシジョン ツリーを作成しました。
非機能要件を検討するための実用的なガイダンス以外に、技術的な観点から考慮すべき最初の問題は、インフラストラクチャを制御する必要があるかどうかです。 そうでない場合は、管理対象サービスが最適で、最も推奨されるルートです。 アプリケーションの性質 (Spring または App Server ベースかどうか) は、Spring アプリケーションが Azure Spring Apps と一致し、Azure App Service は Tomcat または JBoss EAP アプリケーションに適しています。
インフラストラクチャ制御が必要な場合は、マルチクラウド テクノロジの優先設定に応じて選択できます。Azure Virtual Machines は単純な移行を提供し、Tanzu と統合されている場合は、IaaS マーケットプレースの Tanzu オファーが理想的です。 Kubernetes に投資するお客様には、Azure Kubernetes Service と Azure Red Hat OpenShift のオプションがあります。 この意思決定フレームワークは、お客様の要件と Azure の最適なソリューションを組み合わせることで、選択を簡素化するように設計されています。
Microsoft は、次の分野のパートナーを含む多数のパートナーと共同作業を行っています。
- Oracle、Broadcom、Red Hat、IBM、OpenAI などの主要な Java エコシステム パートナー。
- MySQL、PostgreSQL、MongoDB Labs、DataStax、Redis Labs、Confluent、Elastic などの主要なデータベースとツール組織。
- New Relic、Dynatrace、AppDynamics、Grafana Labs、Datadog などの監視専門企業。
- IntelliJ、Maven、Gradle などの開発ツール。
当社の投資は、よりスムーズな開発者エクスペリエンスを実現し、データベース、キャッシュ、メッセージング、ディレクトリなどの重要なサービスとのシームレスな統合に加えて、監視のための包括的なツールを提供します。 自動化、負荷分散、自動スケーリングにより、インフラストラクチャ管理の負担を軽減することを目指しています。 このサポートにより、基になるシステムが堅牢でスケーラブルであるという知識に自信を持って、コードを通じてビジネス価値を生み出すことに集中できます。 これらの理由から、Java アプリケーションの種類をホストして実行するには、特定の Azure サービスを使用することをお勧めします。
Java アプリケーションをソースまたはバイナリとしてデプロイする
Azure 上の Java アプリケーションでは、ソース コードから直接デプロイするか、コンパイル済みバイナリ (JAR、WAR、EAR ファイル) としてデプロイするかにかかわらず、これらの目的専用に設計された Azure の包括的なサービス オファリングにより、デプロイが合理化されます。 Java アプリケーション固有の移植性は、Azure が独自のデプロイ戦略と運用ニーズに合わせてさまざまなサービスを提供できることを意味します。 この柔軟性により、Java アプリケーションの仕様に関係なく、要件に完全に適合する Azure サービスが確保されます。
次の 3 つの例を考えてみます。この例では、Azure がさまざまな Java アプリケーション デプロイ シナリオにどのように対応するかを示します。
Spring アプリケーション。 Spring アプリケーションを使用する開発者のために、Microsoft Azure は Spring オープンソース プロジェクトのリーダーである Tanzu by Broadcom と協力して、Azure Spring Apps と呼ばれる優れたクラウド サービスを提供しました。 このコラボレーションにより、IntelliJ、VS Code、Maven、Gradle などの一般的な開発ツールと、Azure DevOps、GitHub Actions、Jenkins などの自動化ツールを統合することで、開発者エクスペリエンスが向上します。 Application Insights、New Relic、Dynatrace、App Dynamics、Grafana、Log Analytics、Elastic、Splunk などの監視ツールもサポートされています。 セキュリティは最優先事項であり、シークレットと TLS/SSL 認定資格証を処理する Key Vault の統合、マネージド ID を介したバッキング サービスによる「パスワードレス」認証、Azure ロールベースのアクセス制御 (RBAC) により、クラウド内の Spring アプリのセキュリティで保護・合理化されたデプロイ プロセスが保証されます。
JBoss EAP 上の Java アプリケーション。 同様に、JBoss EAP を使用する Java アプリケーションでは、Microsoft Azure チームと Red Hat JBoss EAP チームのコラボレーションにより、調整されたエクスペリエンスがあります。 このパートナーシップにより、Azure App Service のサポートが強化され、JBoss EAP アプリケーション用に設計された豊富な機能セットが提供されました。 このサポートにより、Microsoft と Red Hat の専門知識を組み合わせて使用できるため、Java アプリケーションを Azure でスムーズで、安全、効率的に実行できます。
WebLogic 上のエンタープライズ Java アプリケーション。 Oracle WebLogic で実行される従来のエンタープライズ Java アプリケーションにも、Azure への専用パスがあります。 Microsoft Azure チームと Oracle WebLogic チームのコラボレーションにより、Azure Virtual Machines へのデプロイを最適化する道が開きました。 このパートナーシップは、仮想マシン、ストレージ、ネットワーク、ロード バランサーなどの基本的な IaaS 機能との統合にまで拡張され、Azure 上のエンタープライズ Java アプリケーションの強固な基盤を提供します。 この調整された取り組みにより、アプリケーションは WebLogic の堅牢性と Azure インフラストラクチャのスケーラビリティと柔軟性の両方からメリットを得られます。
これらのシナリオでは、さまざまなフレームワークとアーキテクチャに対応する、柔軟で安全で効率的な Java アプリケーションのデプロイ環境を提供することに対する Azure の取り組みが強調されています。 また、Azure では、Tomcat や WebSphere で実行されている Java アプリケーションなど、他の Java アプリケーション用の特殊なサービスも提供されるため、あらゆる種類の Java アプリケーションに適した Azure サービスが用意されています。
開発者とオペレーターは、これらのカスタマイズされた Azure サービスを使用して、Java アプリケーションを簡単に自動化してセキュリティで保護することで、スムーズで生産性の高いクラウド デプロイ エクスペリエンスを実現します。 ただし、代替のデプロイ オプションを選択する場合は、これらの重要な開発者およびオペレーター エクスペリエンスの構築とメインの管理を自分で処理する必要があります。
次の図は、ソースまたはバイナリとしてデプロイされるすべての Java アプリケーションの種類に対して推奨される Azure サービスを示しています。
この図で参照されているサービスの詳細については、次の表のリンクを使用してください。
Java アプリケーションをコンテナとしてデプロイする
Java アプリケーションのデプロイに関して言うと、コンテナ化は、企業全体のコンテナ作成、管理、ガバナンスの自動化を強化する最先端のアプローチを表します。 この課題は、コンテナを安全かつ確実に構築することにあります。これは、高品質のコンテナ化されたソフトウェア アプリケーションを迅速に提供するための重要なステップです。 このプロセスは、最初から開始するか、既存のコンテナ システムを使用して、コードとバイナリをコンパイルして格納するツールを統合して、コンテナの更新と管理を効率化できます。 このような統合は、継続的デリバリー/デプロイメント (CI/CD) パイプラインに適合するために不可欠であり、コンテナ形式の Java アプリケーションに柔軟なデプロイ方法を提供します。
Azure サービスは、コンテナ化されたアプリケーションの配信を容易にするだけでなく、ソースまたはバイナリからデプロイするための明確なパスを提供することに長けています。 この 2 つのアプローチにより、開発者への影響を最小限に抑え、インフラストラクチャまたはプラットフォーム オペレーターの負荷を軽減します。 Java 固有の移植性を考えると、Azure の幅広いコンテナー サービスの選択により、デプロイ戦略とニーズに最適な結果が得られます。
次の 2 つの例を考えてみます。この例では、Azure がコンテナ化された Java アプリケーション デプロイ シナリオにどのように対応するかを示します。
Spring アプリケーション。 Azure Spring Apps は、コンテナ化された Spring アプリケーションに最適です。 ソース、バイナリ、コンテナ イメージなど、複数のデプロイの種類がサポートされています。 この柔軟性により、デプロイ方法を簡単に移行できます。 コンテナから始めることもありますが、後でソースまたはバイナリとしてデプロイすることにします。 このオプションは、コンテナの継続的な構築とメンテナンスの必要性を回避するため有利です。これは、面倒で反復的で時間がかかる可能性があります。
Tomcat 上の Java アプリケーション。 Azure App Service は、Tomcat で実行するように設計された Java アプリケーションをコンテナ化するのに適しています。 バイナリやコンテナ イメージなど、さまざまなデプロイの種類に対応します。 Azure Spring Apps と同様に、このサービスではデプロイ戦略を柔軟に代替できます。 コンテナのデプロイを開始したり、後でバイナリ (WAR と JAR) のデプロイに切り替えるオプションを維持したりできます。 この多様性により、特定のシナリオで最も効率的なデプロイ方法を選択でき、開発とデプロイのプロセスが合理化されます。
これらの例は、従来の方法でも最新のコンテナ化でも、Java アプリケーションをデプロイするための汎用性が高く、効率的で開発者に優しい環境を提供するという Azure の献身性を強調しています。
次の図は、コンテナとしてデプロイされるすべての Java アプリケーションの種類に対して推奨される Azure サービスを示しています。
この図で参照されているサービスの詳細については、次の表のリンクを使用してください。
まとめ
Azure では、Java アプリケーションのデプロイをナビゲートする際に、微妙な A + B アプローチを採用し、あらゆるアプリケーションのニーズに合わせて調整されたさまざまなサービスを提供します。 Microsoft と Java エコシステム リーダーとのコラボレーションにより、一連の Azure サービスが提供され、それぞれ、ソース、バイナリ、またはコンテナとしてデプロイされる特定の Java アプリケーションの種類に対して推奨され、デプロイ プロセスが合理化され、最適なパフォーマンスが確保されました。 この焦点は、最も適切な Azure サービスとの一致デプロイ戦略に焦点を当てることで、ジョブに適したツールを柔軟に選択できる Microsoft の献身性を強調しています。 Java アプリケーション固有の移植性は重要な利点であり、運用効率と機敏性を高めるために、オンプレミス システムとさまざまなクラウド プロバイダー間でシームレスな移行を可能にします。 このより広範で包括的な選択プロセスを提唱することで、Microsoft は Java アプリケーションのクラウド工程を簡素化するだけでなく、スケーラビリティ、セキュリティ、監視、およびコスト効率を最大化します。 最終的に、Microsoft のガイダンスにより、開発者と企業は Azure のエコシステムを使用でき、各 Java アプリケーションがニーズに最も適したクラウド環境で確実に繁栄します。
次のステップ
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示