クラウド移行計画を設計する際に考慮すべき 7 つの要素

企業は、アプリケーションが移植可能であり、複数のクラウド コンピューティング プロバイダーのクラウド サービス間を簡単に切り替えられることを望んでいます。これを実現するには、企業は適切なクラウド移行計画を策定する必要があります。

今日では、クラウドでワークロードを実行することに躊躇する人はおらず、多くの企業にとってデフォルトの展開戦略となっています。数年前、IT チームはクラウド コンピューティング アプリケーションを作成する必要性を正当化する必要がありました。現在、状況は逆転しており、IT チームはアプリケーションがクラウドに展開されない理由を正当化する必要があります。

[[251033]]

企業がクラウド コンピューティングを導入することは必要ですが、ワークロードの移行が簡単であることを意味するわけではありません。最も重要なことは、企業はベンダーロックインに注意する必要があるということです。クラウド コンピューティングの約束は、常に、現在のインフラストラクチャの従来の制約の外で展開できることです。しかし、現実には、クラウド コンピューティング アプリケーションを導入すると、ほとんどの企業はプロバイダーの選択を変更することに消極的になります。

クラウド移行計画を複雑にしているのは、Microsoft Azure などの一部のクラウド コンピューティング ベンダーがオンプレミスのプライベート クラウド オプションを提供し始めているという事実です。これらのパッケージを使用すると、パブリック クラウドからプライベート クラウドへの移行が容易になりますが、エクスペリエンスはシームレスとは程遠いものになります。アプリケーションの移行は簡単かもしれませんが、それでも時間がかかり、労力がかかり、困難な場合があります。

クラウド アプリケーションを移植可能にし、異なるクラウド プロバイダーのプラットフォーム間で移動するには、企業はいくつかの重要な要素を念頭に置く必要があります。調査会社ガートナーによると、2022年までに企業のIT支出の28%がクラウドコンピューティングに移行し、クラウドコンピューティングの決定は依然として重要な問題となっています。

クラウド移行計画は慎重に検討する必要がある

クラウド移行計画を実現可能にするには、企業はクラウド展開を設計する際に移植性を考慮する必要があります。しかし、すべてが順調に進むというわけではありません。

クラウド移行計画を策定する際に、企業は以下の点を考慮する必要があります。

（1）ワークフロー企業はアプリケーションのワークフローを理解する必要があります。入力または出力が同じクラウドで実行されている別のアプリケーションまたはビジネス プロセスに関連付けられている場合、ビジネスを別のプロバイダーのクラウド サービスに移行することは問題があり、お勧めできません。

（２）作業負荷クラウド プロバイダーは、ワークロードのニーズに合わせてプラットフォームを最適化または設計していますか?たとえば、政府アプリケーションは、政府機関のセキュリティとアクセシビリティの要件を満たすように特別に設計されたクラウド プラットフォーム上でより簡単に実行できる可能性があります。

（３）アプリケーションと言語。インフラストラクチャ・アズ・ア・サービスなどの場合には、オペレーティング・システム、ミドルウェア、ランタイム・ライブラリを制御することが可能です。 Platform as a Service では、この制御は失われ、クラウド プロバイダーがこれらの領域の多くを決定します。このアプローチでは、アプリケーションと言語のサポートが制限される可能性があります。

（４）ツールこれは Amazon Web Services が優れている分野です。同社は、多くの点で競合他社を凌駕するツールと API を提供し、開発者の作業を容易にしています。しかし、この利点には代償が伴います。 AWS から別のクラウドプロバイダーへのクラウド移行計画では、アプリケーションの書き換えや、AWS 製品に統合されるサードパーティの機能の追加が必要になる場合があります。クラウド プロバイダーが提供するツールセットが優れているほど、顧客の忠誠心は高まります。

（５）ネットワーキング見落とされがちですが、ネットワークはクラウド コンピューティング アプリケーション、特にオンプレミス アプリケーションやユーザーのデータ センターに戻される可能性のあるアプリケーションと通信する必要があるアプリケーションの重要なコンポーネントです。アプリケーションをクラウドに移行する企業は、オンプレミス展開用とクラウドベース展開用の 2 つのネットワーク スタックを維持する必要があります。クラウド ベンダーの Big Switch Networks は、クラウド アーキテクチャによってこの問題に対処し、アプリケーションがどこにあってもオンプレミスの展開と同じように見える単一の基盤を提供します。ユーザーは、オンプレミスまたは AWS クラウドにファブリックを展開し、標準的なネットワーク管理ルールと設定のセットを利用できます。

（６）データ構造データ構造はアプリケーションに大きく依存するため、これはおそらくあまり議論の余地のない問題の 1 つです。しかし、実際の移行ではデータ構造が複雑になります。この時点で、期待どおりに動作しないアプリケーションのデバッグに何時間も費やすことになります。この障害は、データ構造自体に何らかの問題があり、アプリケーションが期待どおりに機能しないことが原因で発生する可能性があります。

（７）保管クラウド移行計画における重要な考慮事項はストレージです。企業はコストとデータの保存方法を考慮する必要があります。さらに、レガシー アプリケーションから別のプロバイダーがホストする新しいアプリケーションにデータを移行する方法も検討する必要があります。ほとんどのクラウド コンピューティング プロバイダーは、データをクラウドに取り込むことを簡単かつコスト効率よく、効率的に行えるようにしていますが、データを取り出したり、データに対してアクションを実行したりすると、コストがかさみ始めます。

アプリケーションを移行する際には移植性が重要

これらの点はいずれも、2 つのクラウド ベンダー間でアプリケーションを移動することに反対するものではありません。これらは、クラウド戦略を構築する際に考慮すべき重要な指標にすぎません。

クラウド移行計画をスムーズに進めるには、移植性を考慮してクラウド コンピューティングの展開を設計する必要があります。しかし、すべてが順調に進むというわけではありません。さらに、ビジネスと技術のトレードオフも考慮する必要があります。

アプリケーションが AWS 内に存在し、別のプラットフォームに移行する柔軟性が必要な場合、一部の AWS ツールや機能を使用できない可能性があります。一部の組織では、このトレードオフは実行可能な場合があります。ただし、多くの場合、これらのツールを活用してアプリケーションをそのまま維持することで、運用コストに関係なく、アプリケーションの長期的な価値を最もよく理解できるようになります。

価値とコストのトレードオフは、アプリケーションごとに、特にクラウド コンピューティング プロバイダーごとに異なります。ただし、これは、IT チームが長年行ってきた構築と購入の議論と何ら変わりありません。

しかし、これはもはや当てはまりません。 IT チームは、どこに構築するか、どこに留まるか、どのように移転するか、あるいは購入するかについての議論に対処します。重要なのは、企業が導入後数か月または数年後に行動を起こすのではなく、プロジェクトの開始時に適切な判断を下すことです。