今日のITチームは多くの課題を抱えている。非構造化データは年間35％増加しているが、そのデータを担当するITチームは、人員、予算、データセンターの縮小を目の当たりにしている（データセンターは実際には縮小していないかもしれないが、間違いなく大きくはなっていない）。本記事は、企業の戦略担当者、マネージャー、管理者がワークロードをクラウドに移行する際に直面する課題と機会、そしてメリットとデメリットを考察するシリーズの4回目である。
これまでの投稿では、クラウドサービスを統合するかどうか、またどのように統合するかを決定する際に、企業が考慮しなければならない一般的な要因について説明してきた。また、さまざまな戦略の長所と短所、そしてそれらを相互に比較検討し、企業にとって最善の方法を決定する方法についても説明した。
次回のシリーズでは、データをクラウドに移行する際の一般的な戦略を、リスクを管理（最小化）する方法という観点から分析する。
始める前に、企業によっては本質的にリスク許容度が他の企業よりも高い場合があることに注意することが重要である。
これは、御社の事業内容や関連要因（例えば、規制上の期限や保護すべき個人情報（PPI）の有無など）に影響されます。場合によっては、規制の期限を守らなかったり、PPIを漏えいさせたりすると、甚大な影響が出る。
うっかりHIPAA法に違反した保険会社を想像してみてほしい。下流への影響には、金銭的な罰則、民事罰、悪評、そして場合によっては刑事罰さえも含まれる可能性がある。金融、医療、保険、その他の規制の厳しい企業は、システム、ソフトウェア、アーキテクチャの変更に関して、クラウドへの移行と同等のリスク許容度をはるかに低く持つことになる。
クラウドのコンピュートとストレージの見通しは、多くの企業システム管理者に興味深い難問を突きつけている。それは、将来に向けて革新するビジネスの必要性をサポートすることと、現在のビジネスを維持するために既存のサービスとワークフローを確実にオンラインに維持する必要性という、相反するプレッシャーである。
クラウド導入戦略を成功させるには、慎重なバランスが必要である。計算されたリスクを取って新しいプラットフォームやテクノロジーを導入し、成長とイノベーションを実現すると同時に、明かりを灯しビジネスを継続させるのだ。
非現実的な戦略
何をすべきかを考える前に、何をすべきかについて説明しよう。 違う すべきことがある。その第一は、ビジネスを維持するアプリに関して不必要なリスクを取らないことだ。
大規模アプリケーションのリファクタリング
多くの組織は、重要なファイルベースのワークロードをクラウドネイティブ・アーキテクチャにリファクタリングすることを少なくとも検討するだろう。これには、ファイル・データではなくオブジェクト・ストレージを活用するようにアプリケーションを書き換える必要がある。このアプローチには、クラウド運用の柔軟性が高まったり、AWSやAzureで利用可能なプロバイダー固有のクラウドネイティブサービスとの統合が強化されたりといった長期的なメリットがあることは認めるが、留意すべき重大な欠点もいくつかある。
この戦略の初期コストは高い。アプリの規模や複雑さにもよるが、1つのアプリを書き直すのに300万ドルから3000万ドルの変換コストがかかるかもしれない。
そう、1つのアプリに3,000万ドル以上かかるのだ。しかも、それが成功すればの話だが。
大規模な障害が発生するリスクは非常に高いだけでなく、最悪の場合、問題を診断し修正する間、ビジネス全体が停止してしまう可能性もある。プロジェクトが完了するまでに2年以上かかるかもしれない中で、あなたの組織はどれだけの失敗を許容できるだろうか？
文脈からリスクを認識する
上記のシナリオが実際に許容できるリスクとみなされる正当な状況もある。次のことを考えてみよう：
ビジネスクリティカルで、ファイルに依存するアプリの1つが、新しいベンダーに購入され、そのベンダーが、ある日をもって段階的にサポートを終了すると発表したとします。突然、あなたは次のことをしなければならない立場に立たされます。 何か そのいずれもが、失敗や事業の中断につながる可能性がある。
もしかしたら、あなたの組織は、ベンダーが次のバージョンはクラウドネイティブになると発表したサードパーティアプリに依存しているかもしれない。あなたやあなたの組織がその発表についてどう感じようと、リスクは関係なく存在し、それを回避しようとするのではなく、最小限に抑え、軽減するのはあなたの責任だ。
また、大規模なビジネス変革であれば、クラウドに移行するリスクを相殺することもできる。大規模なブランド再構築やビジネスモデルの転換を行う場合、a)すでに他の障害が発生するリスクが高いが、b)クラウドに移行することで、これまでオンプレミスに保管されていた以前のデータの一部を救済できる可能性がある。
このような場合、クラウド移行が許容できるリスクと考えられるかどうかを上回る外部要因が十分にある。
Y2Kバグのことを覚えている古い人は、「許容できるリスク」の方程式を変える外的要因の完璧な例を持っている：何もしないリスクは、ミッションクリティカルなレガシーアプリでさえ、再設計、移行、または交換するための行動を取るよりも高かった。
しかし確かに、上記のシナリオはほとんどの人に当てはまらないだろう。ビジネス・クリティカルなアプリのリファクタリングに関して言えば、多くの組織は成功の可能性の低さと失敗した場合のコストの高さを天秤にかけ、アプリをそのままにしてクラウドが追いついてくるのを待つ方が理にかなっているという正しい結論を下す。
やり過ぎ
クラウドに移行する際のもう1つの非現実的な戦略は、あまりに速く移行しようとすることだ。アプリケーションを壊してしまうだけでなく、オンプレミスのデプロイメントに戻すか、クラウドで前倒しで修正するまで、水の泡になってしまう。
アプリケーションを評価し、徹底的にテストするために、ゆっくりと必要な時間を取らなければ、移行後の待ち時間の問題、データエラー、スループットの欠点が発生する危険性があります。ある閾値を超えると、これらは完全なマイグレーションの失敗につながるかもしれません。オンプレミスからクラウドへのスムーズな移行に必要な時間と労力をかければ、こうしたエラーが発生するリスクは大幅に減少します。
では、ワークロードをクラウドに移行するための現実的な戦略にはどのようなものがあるのだろうか。我々がどのようなアプローチを推奨するか、次回をお楽しみに。