クラウド アプリケーション移行の困難を回避する方法

企業がビジネスクリティカルなアプリケーションをクラウドで実行することに決めたら、他のプロバイダーに切り替えることはほとんどありません。その大きな理由は、選択したベンダーのエコシステムに縛られていることが多いからです。ガートナーのクラウドサービスおよびテクノロジー担当副社長シド・ナグ氏は、移行コストがあまりにも高すぎると語った。 「しかし、計画をしっかり立てておけば、アプリケーションをあちこち移動させる必要はありません」と彼は言う。

企業を正しく位置づければ移行は可能ですが、重要なのは、オープン プラットフォームとフレームワークを戦略的に採用し、クラウド プロバイダーをインフラストラクチャ層の役割に委ねることです。このアプローチは学習曲線が急ですが、中期および長期的にはより好ましい結果が得られます。重要なのは、ビジネスの境界を描き、特定のベンダーとの関わりが少ないソリューションを作成できる、プラットフォーム中立のソフトウェア アーキテクトを導入することです。

USPTO の CIO である Jamie Holcomb 氏は、もう少し微妙な見解を示しています。彼は、クラウド プロバイダー間でアプリケーションを移動するオプションを開いたままにしておきたいと考えており、すべての主要なクラウド プロバイダーで市場調査を行っていますが、そのためには、アプリケーションを初めてクラウドに移行する前に事前に計画を立てる必要があります。

ロックインのリスクを最小限に抑える

各ベンダーのクラウドネイティブ サービスを活用する場合、トレードオフを慎重に検討する必要があります。特定のサービスに依存しないためにクラウド プロバイダーのネイティブ サービスを使用しないことを選択した場合、より優れ、より安価で、より高速なビジネス ケース メトリックの多くを失うことになります。ベンダー ロックインに代償があるように、不可知論にも代償があります。

クラウドベンダーロックインには 3 つの形式があります。プラットフォーム ロックインは、完全なクラウド インフラストラクチャ構成 (リソースのグループ化、ポリシー、RBAC、ハイブリッド接続、監視、コンプライアンスなど) がある場合に発生します。新しいプラットフォームでこれらすべてを再作成する複雑さにより、別のプラットフォームへの移行が困難になります。

アーキテクチャのロックインとは、アプリケーションがクラウド プロバイダーの複数の管理サービスに依存するようになることであり、この場合、移行する前にアプリケーションを再構築する必要があります。

さらに、法的なロックインがあり、事前に決められた期間にわたってエンタープライズ サービス契約を締結することになりますが、これらの契約は解除が難しく、移行が困難になります。

CIO がベンダー ロックインを回避するために最大限の努力を払ったにもかかわらず、ベンダー ロックインが発生することがあります。合併や買収により、企業はマルチクラウド アーキテクチャを採用することが多く、CIO は統合を望んでいるものの、コストが高すぎてそれを正当化できないことがよくあります。ほとんどの場合、これらの CIO は、ロックインされているため、マルチクラウド モデルに留まることに決めます。

障害があるにもかかわらず、企業が IaaS プロバイダー間を移行する十分な理由がある場合があります。最も一般的な理由は、価値と運用コストのコスト比率を改善するため、競合するクラウド サービス プロバイダーからの大幅な割引を利用するため、企業が信頼性を向上させたい場合にマルチクラウド アーキテクチャを利用するためです。

将来の移行の可能性に備えて計画を立てる

重要なアプリケーションをクラウド プロバイダー間で移動したいという要望 (ガートナーはこれを「クラウド回帰」と呼んでいます) は、企業がアプリケーションをオンプレミスのプライベート クラウドに戻す目的で、手頃な価格のクラウド ネイティブ ミドルウェアと開発ツールを使用することを決定した場合でも、多くの場合、計画不足の結果です。

計画を立て、クラウドに移行する適切なアプリケーションを確実に選択するために、MSP またはシステム インテグレーターのサービスを活用することをお勧めします。これは、アプリケーションを移行するとプラットフォームにロックされることに同意することになるので重要です。

金融サービス会社 USAA は、各ワークロードと一般的なビジネス アプリケーションをホストするために、4 つのクラウド サービス プロバイダーから 1 つを慎重に選択しました。 「当社は、クラウドプロバイダーを、彼らが最も得意とするビジネスサービスやテクノロジーサービスと連携させています」と、上級副社長兼最高技術責任者のジェフ・カルシンスキーは述べています。

同局のマルチクラウド戦略は、同氏が「設計によるオープン」原則と呼ぶものに根ざしている。 「オープンスタンダードが存在する場合はそれを使用します。これにより、ベンダーロックインの可能性が減ります」と彼は語った。しかし、オンプレミスのサービスの中には、ロックインの可能性と比較検討する必要がある魅力的な価値提案を提供するものもあると認めた。

さらに、オープン設計の原則は、ロックインの観点からのみ機能します。これは、最新のサービスを使用する場合でも、各プラットフォームでの実装が異なるためです。例: Amazon の EC2 は Google の GCP と同じことを行いますが、EC2 で実行されるアプリケーションは、多大なコストのかかるやり直しを行わない限り、GCP では実行できません。 Kubernetes は業界標準ですが、Azure Communication Service や Google Kubernetes Engine などの実装は同じようには動作しません。

ただし、クラウド プロバイダーとアプリケーションの間には抽象化レイヤーが出現しており、ネイティブのクラウド プロバイダー サービスを使用している場合でも移行を簡素化できます。これらのサービス (pub/sub、サービス呼び出し、シークレット管理、状態管理など) は、クラウド プロバイダーに関係なく、アプリケーションのコンポーネントを抽象化します。つまり、結局のところ、選択肢はまだ残っているが、あるクラウド プロバイダーから別のクラウド プロバイダーに移行するには、まだ何らかの作業が必要だ、と彼は言いました。

データ要件は、慎重な計画を必要とするもう 1 つの領域です。クラウド間でアプリケーションを移動するには、関連するデータも移動する必要があり、データの送信には非常にコストがかかるため、コストがかかります。

したがって、事前に準備しておく必要があるとホルコム氏は付け加えた。 「データをどのように取り出すか、またそれらのソフトウェア サービスを他の場所でどのように複製するかがわかる契約を結ばない限り、プロバイダーと契約しないでください」と彼は言いました。

構造化された方法と使用可能な形式でプロバイダー間でデータを移動できるようにするための適切な ETL 戦略を導入している場合でも、このような計画は存在しないことがよくあります。クラウド サービス プロバイダーは、理論的には使いやすいオープン プラットフォームとデータ アクセス プロトコルの使用を重視していますが、これらのサービスにアクセスする際のネットワークの制限とセキュリティは見落とされがちです。

企業は、どのクラウドネイティブ サービスを使用するかを決定する際に選択の余地がない場合があり、セキュリティはその良い例です。セキュリティ ニーズが高い場合、一般的なネットワーク セキュリティでは不十分な可能性があり、ニーズが具体的であればあるほど、ベンダー ロックインの点でサービスが厳しくなります。データ集約型のビジネスを展開する企業は、ストレージと帯域幅の両方の問題に直面しており、PaaS および IaaS プロバイダーは、これらの両方の問題を競争上の優位性として活用しています。両方の高い性能を同時に活用しようとすると、難しいです。

トウヒが枝を幹の近くに保っているのと同じように、カスタム製品をできるだけ「スリム」に保つことで、ロックインが軽減されるだけでなく、企業が過負荷で高価なバージョン管理パスによって圧迫されることがなくなります。

ほとんどの PaaS オプションには、コア機能と一連の補助機能があり、補助機能の数を考慮してコア機能に重点が置かれています。

同じことは SaaS ベースのアプリケーションにも当てはまり、彼のチームが Remedy から ServiceNow および Salesforce に移行する際に従った信念です。カスタマイズしすぎず、必要なときに交換するだけです。それらに制約されないでください。これは構造的に優れたプラットフォームですが、最適化が詰め込まれていると行き詰まってしまいます。

移行に伴う潜在的な問題を回避する

クラウド プロバイダー間の移行には、互換性の問題、セキュリティ上の懸念、アプリケーションの大規模な再構成の必要性、新しい環境にシームレスに統合されないレガシー オペレーティング システムや古いテクノロジ スタックに基づくイメージの処理など、無数の課題があることは明らかです。大量のデータを転送すると、ダウンタイムや潜在的なデータ損失が発生する可能性もあるため、移行中に一貫したパフォーマンスとスケーラビリティを確保することが重要です。これらの課題に対処するには、慎重な計画、徹底したテスト、明確に定義されたロールバック戦略が必要です。

さらに、PaaS 移行の主な失敗点としては、コストやビジネスの期待を満たさないこと、リソース スキルが不十分であること、標準化とセキュリティ基盤が欠如していること、クラウド ネイティブ機能を活用していないこと、セキュリティとコンプライアンスの問題、クラウド運用モデルを採用していないことなどが挙げられます。

クラウド プロバイダー間の移行を検討している企業には、6 段階のアプローチが推奨されます。まず、サブスクリプション モデルを評価して ROI 目標と一致していることを確認し、ハイブリッド クラウド アプローチを採用し、可能な限りクラウドに依存しないソリューションを使用し、将来の移行オプションをオープンにし、ネイティブ クラウド サービスを使用する場合は抽象化レイヤーを使用してアプリケーションを設計し、データ移行の計画、テスト、およびバックアップ戦略に投資してリスクを軽減し、必要に応じてライセンス契約を確認して調整します。

選択肢を慎重に検討する

クラウド プロバイダーの移行を検討するときは、常に移行コストとデータの所有権を考慮してください。

ロックインを増やすネイティブ クラウド サービスの使用と非依存の維持との間でバランスを取る場合、正しい答えはなく、ビジネスとそのミッションに最適な答えがあるだけです。問題は、クラウドベースのアプリケーションがビジネスの使命と一致し、長期にわたってその使命を達成する上で最高の価値を提供するかどうかです。コスト インフラストラクチャが過度に複雑だと、ビジネス モデルの変化に合わせて変更することができず、選択肢が限られてしまいます。

クラウド移行戦略を策定する際には、価格モデルに注意を払うことが重要です。潜在的なコスト削減イニシアチブを検討し、データ転送コストを考慮することは、クラウド運用費用の予期しない急増を防ぎ、予算の制約との整合性を確保するために重要です。移行戦略を実行する際に考慮すべき 2 つの追加要素があります。まず、クラウド サービス プロバイダーは移行を容易にするためにどのようなサービス (マイクロサービスやサーバーレスなど) を提供していますか?カスタム ソリューションを使用するか、ベンダー ロックインのリスクが生じるクラウド プロバイダーが提供するマネージド サービスを使用するかを決定する必要があります。 2 番目に、クラウド プロバイダーはアプリケーションの移行に対してインセンティブ プログラムを提供することがあり、大規模な移行の場合は大幅な割引が受けられる場合があります。

クラウド移行は本質的にリスクを伴う可能性がありますが、CIO が事前に計画を立ててプロセスを継続すれば、よりコスト効率の高いクラウド サービスと価格モデル、より優れたスケーラビリティとリソース割り当て、パフォーマンスと応答性の向上を実現できる可能性があります。ベンダー ロックインを削減すると、俊敏性とイノベーションが向上します。最終的には、クラウドへの移行により、競争力、イノベーション、効率性が向上します。