クラウド移行の成功: 飛躍する
おそらくご存知ないかもしれませんが、今日私たちが知っているクラウドは、2006 年 8 月に当時の Google CEO であった Eric Schmidt 氏によって初めて定義されました。 正直に言えば、ずっと後になるまで誰もこのアイデアを真剣に受け止めませんでした（少なくとも実用的な意味では）。
わずか 5 年後には、クラウドが重要視されるようになり、レガシー アプリケーションをクラウド プラットフォームに移行することの影響について多くの検討がなされました。 実際、プラットフォーム移行に関してこれまでに学んだ教訓の多くは、現在でも当てはまります。
以前このフォーラムでお話ししたように、簡単なことは何もありません。クラウドへの移行を決意すると、本当の仕事が始まります。
移行作業を成功させるには、移行をサポートする包括的な戦略の開発だけでなく、事前に難しい決定を下す力も必要です。 最も魅力的な決定は、このステップを完全にスキップして、移行アクティビティにすぐに飛び込むことですが、その「簡単な」決定はクラウドへの移行を失敗に導く可能性があります。
ベスト プラクティス モデルを採用した IT プロフェッショナルは、望ましい結果と、その過程における成功を検証および測定するメカニズムを理解することから始めます。 その時点から、移行するアプリケーションを適切に評価し、移行の目標 (パフォーマンスの向上、レイテンシの削減、スケールなど) を把握できるようになります。
フェーズ I – 本当にこれをやりたいですか?
クラウド フレームワークは宣伝され、低コスト モデルが約束されていますが、すべてのビジネスやすべてのアプリケーションがクラウド フレームワークに移行すべきというわけではありません。 誤解しないでください。多くのアプリはクラウド展開に適しており、アプリによっては他のアプリよりも移行が簡単ですが、ビジネスへの影響を慎重に検討する必要があります。 経営幹部が、それが何を意味するのかよく理解せずに IT 部門に「クラウドへの移行」を命じるという恐ろしい話をよく耳にします...そして、あなたも私と同じなら、よく理解することほど良いことはありません。 より良いアプローチは、全体的な戦略で設定した目標に関して実際のビジネスケースを作成することです。 「なぜこれをやっているのか？」という質問に答えます。 そして、正直に言うと、コスト削減の魅力だけが考慮される基準であるならば、それは間違いである可能性があります。
フェーズ II – 何を移動すべきか、その理由は?
さまざまな専門家がこの段階をさまざまな名前で呼んでいますが、実際には既存の環境の棚卸しを行うことが目的です。 たとえば、オンプレミス環境の VMware フレームワークでアプリケーションを実行する利点があり、さらに拡張性を求めている場合は、先ほど発表されたF5/VMware/IBM Cloud の組み合わせを利用するのが最適かもしれません。 F5 の BIG-IP 仮想サービススイートだけでなく、VMware ソリューション ポートフォリオ向けの IBM Cloud との自動プロビジョニングと統合も活用する検証済みソリューションを提供することで、クラウドへの移行がはるかに容易になります。
このソリューションを活用することで得られるメリットは次のとおりです。
- ダウンタイムを削減するスケーラブルなアプリケーション配信
- F5のプログラマビリティへの既存の投資を活用して市場投入までの時間を短縮
- 迅速なワークロード展開の障害を排除
- オンプレミスとIBM Cloud間でワークロードの移植性を実現
- シームレスなアプリケーションフェイルオーバーでダウンタイムを排除
- F5のエンタープライズグレードのパフォーマンス、可用性、セキュリティサービスの一貫した適用
異なるフレームワーク内で運用している場合は、基盤となるサポート設備 (コンピューティング、ストレージ、インフラストラクチャなど) とソフトウェア ライセンスに関連する制限を慎重に検討してください。
このフェーズでの良い経験則は、アプリケーション自体について（それを実行するのに必要なものに加えて）真剣に考えることです。 ほんの数年前に開発されたアプリケーションを移行することは理にかなっているかもしれませんが、10 年間使用されてきたアプリケーションを移行しようとすることはあまり意味がありません。 技術的負債の負担を決して忘れないでください。確かに、これは最近よく使われる用語ですが、本当の課題は、新しい領域ではもちろん、それを正常に実行するために必要なドメイン固有の知識です。 CTR/IBM のトーマス・ワトソンが 1911 年に言ったように、「考えろ!」そうすれば大丈夫だ。
フェーズ III – 「やってやるぞ!!!」
デザイン。 デザイン。 デザイン。 移行します。 検証します。 繰り返す。 この簡単なアドバイスに従えば、成功する可能性は高くなります。 今日、多くの企業がクラウド展開に CI/CD (継続的改善、継続的デリバリー) 戦略を採用しています。
ほとんどの取り組みは、本質的に比較的単純なアプリケーションから始まり、そこから学習します。 私も、このアプローチは自分のチーム内で使用する場合にも最も効果的だと感じています。 反復的なプロセスは、製品とサービスの両方の迅速かつ継続的な改善に役立ちます。この場合、クラウドでのアプリケーションの成功につながります。 最初の動きである程度成功した後は、学習するにつれて動きが簡単になります。
もちろん、新しくデプロイされたアプリケーションをテストし、すべてが正常に動作し、宇宙が終わっていないことを確認したら、レガシー システムをシャットダウンするための戦略を明確にしておく必要があります。
このフェーズに関する最後のアドバイスは…個人的には、アプリケーション開発チームとネットワーク運用チームの両方がうまく連携し、プロセス全体を通じて連携して作業する展開が最良 (かつ最も成功) であることがわかりました。
フェーズIV – 最新のクラウド指向のプラクティスを採用する
クラウドへの第一歩として、そして最初のアプリケーションを廃止するレガシー システムから移行するときには、現代の IT はタスク レベルの取り組みではなく、システム レベルの考え方であるということを念頭に置いてください。 なる ボタンを押すだけの人ではなく、ボタンを作成する人です。
次の投稿では、実際の移行オプションに関するより具体的なアイデアをいくつか紹介します。 乞うご期待。