ああ、そうだ。 それは起こっている。 プロセスの負担を軽減するために、これを包括的なクラウド戦略の一部にすることを検討してください。
次の共通点は何でしょうか? サーモン、カナダガン、オオカバマダラ、およびアプリケーション。
これらすべてが、ある場所から別の場所へ移動するものだと推測できたなら、自分を褒めてあげてください。
通常、クラウド移行について話すときは、オンプレミスからオフプレミスへの移行について話します。 十分な理由があります。 パブリック クラウドの利用の採用が増加していることを示すデータは数多くあります (当社独自のデータも含む)。 私たちがほとんど話題にしないのは、逆方向に起こる移住についてです。 今、「異端だ!」という叫び声が聞こえてきそうですが、現実的に考えてみましょう。それは起こり得ることであり、あなたが思っているよりも頻繁に起こります。
例えば:
パブリック IaaS を本番環境で導入した回答者の 42% が、「今後 4 年以内、または継続的なプロセスとして、現在の戦略から移行する予定である」と回答しました。 回答者の 70% は、「プライベート クラウド ソリューションのみに切り替えるのではなく、ハイブリッド クラウドへの移行を予定しています。」
理由? 最も一般的な要因はコストの削減(67%)であり、次いでセキュリティと安定性でした。 これは、Pubmatic のパブリック クラウドからプライベート クラウドへの移行に関する次のようなストーリーによって裏付けられています。 コストが大きな要因でした。
しかし、私たち全員が聞いているように、反対方向に移住している人もいます。 たくさん。 プライベート IaaS プラットフォームを使用している回答者の 57% が「パブリック クラウドまたはハイブリッド クラウドへの移行を予定しており、回答者の 77% がハイブリッド アプローチを採用する予定であると回答しています。 」
彼らの理論的根拠は? スケーラビリティ(71%)、次いで柔軟性が続きます。 コストは回答者の50%で3位となった。
スケーラビリティが人々をパブリック クラウドへと駆り立て、長期的なコストが人々をプライベート クラウドへと呼び戻すようです。
現実には、ほとんどの組織は「パブリック クラウド」ショップでも「プライベート クラウドのみ」ショップでもありません。 アプリを移動した後でも、マルチクラウドです。 この現実は、 Cap Gemini の「クラウド ネイティブの成熟」レポートで報告されているような開発トレンドを調べることで証明できます。このレポートでは、「回答者の企業の新しいアプリケーションの 6 分の 1 (15%) が現在、クラウド ネイティブ環境で構築されている」と述べられています。
15% がクラウド ネイティブである場合、残りの 85% はクラウド ネイティブではないということになります。 おそらくメインフレームも含まれます。 そしてクライアントサーバー。 そして 3 層の Web アプリ。 ああ、コンテナ化された環境におけるマイクロサービスもあります。
現代の企業組織はマルチクラウドであるだけでなく、アプリケーション アーキテクチャの点でも多世代化しています。
つまり、何らかのアプリをオンプレミス (プライベート) からオフプレミス (パブリック) へ、またはその逆へ移行する可能性はかなり高いということです。クラウド ネイティブ アプリよりも、そうしたアプリの方が多いためです。 重要なのは、その前提をクラウド戦略に組み込むことです。 言い換えれば、(おそらく避けられない)プロセスの苦痛を軽減するために事前に何ができるかを理解する必要があります。
最初に考慮すべきことの 1 つは、移行するアプリの予想寿命です。 長期的な場合は、将来的にクラウド間の移行の候補となります。 そうでない場合(プロモーション、マーケティング、またはイベントベースの場合)は、このリストの最後までスキップして展開できます。
アプリの寿命を長くすることを決定したので、アプリをどのように拡張し、保護するかについて検討する必要があります。
セキュリティソープボックスサイドバー アプリが入力やタッチデータを受け入れない場合でも、何らかのセキュリティが必要です。 アプリのセキュリティはスタックであり、両方を保護しないと、侵害を受ける可能性があるプラットフォームとプロトコルがあります。 メタデータ操作攻撃 (HTTP ヘッダーをターゲットとする攻撃) は、カスタム コードによって引き起こされる脆弱性と同じくらい (おそらくそれ以上に) 危険です。 セキュリティに関しては、すべてのアプリが重要です。 |
アプリがクラウドネイティブである場合の簡単な答えは、「クラウドプロバイダーのサービスを使用する」です。 これは有効なオプションです。アプリがオンプレミスのプライベート クラウドで稼働する場合、「これまで使用してきたものを使用する」というオプションも有効なオプションです。 ただし、どちらのオプションも、サービスやポリシーをあるクラウドから別のクラウドにスムーズに移行できないという潜在的なリスクを伴います。 スケールとセキュリティのために現在使用しているものを徹底的に見直し、それらのアプリケーション サービスがアプリとともに双方向に移行できるかどうかを判断するときが来ました。
企業がアプリを配信し、保護するために平均 16 個のアプリケーション サービスを使用していることを考えると、これは、マルチクラウドの世界でアプリをサポートすることは言うまでもなく、移行する可能性のあるアプリをサポートする能力を大幅に妨げる可能性がある領域です。 これら 16 のサービスのうちいくつかはクラウド ネイティブ サービスである必要があることに注意してください。 基本的に、データ パスが企業、共有アプリケーション サービス、およびアプリごとのサービスで構成されていると見なすと、アーキテクチャの区分が、パブリック クラウド プロバイダーがインフラストラクチャ層で引いた線とほぼ一致していることがわかってきます。 これは完璧な区分ではありませんが、どのサービスが「マルチクラウド」である必要があり、どのサービスがクラウド ネイティブまたは従来のデータ センター サービスに依存できるかについてのガイダンスを提供する論理的な分離を提供します。
クラウド間で使用するアプリケーション サービスの一貫性が高ければ高いほど、制約が少なくなるため、2 つ (または 3 つ、4 つ、あるいはそれ以上) のクラウド間での移行が容易になります。 このアプローチには、自動化の取り組みをパブリック クラウドにまで拡張し、少なくとも個別の運用スタッフと手順の維持に関連する運用コストを企業から軽減するという追加の利点があります。
雲は避けられませんでした。 マルチクラウドも同様です。 それは、最終的には両者の間で移住が起こることを意味します。 アプリをどこにデプロイするかという最初の決定を行う前に、依存関係に注意し、クロスクラウド アプリケーション サービスを使用することで、プロセスの負担を軽減できます。
少なくとも、クラウドからクラウドへの移行のアイデアをトップレベルのクラウド戦略の一部にしてください。 準備をしておけば、後で面倒な(そしてコストのかかる)移行を避けることができます。