ハイブリッドクラウドに対する5つの対抗戦略

業界の専門家と IT リーダーが、ハイブリッド クラウド戦略を採用する組織向けの逆説的な戦術をいくつか共有します。これらの環境が成熟するにつれて、人々は一貫性、コスト、学んだ教訓について学ぶことができます。しかし、時には良いアドバイスが簡単に無視されてしまうこともあります。

[[338307]]

これはハイブリッド クラウドのアーキテクチャと戦略にも当てはまります。逆の考え方を取り入れると、メリットがあるかもしれません。ハイブリッド クラウドという用語や、その定義方法さえも、見直す価値があります。

ハイブリッド クラウドの採用が拡大し、既存のハイブリッド環境が成熟しつつある（そして経験と教訓から学びつつある）時代に、これは熟考する価値のある質問です。

ハイブリッド クラウド戦略: 考え方を変える 5 つの方法

業界の専門家が、ハイブリッド クラウドの定義によってさまざまな環境で矛盾が生じる可能性がある方法や、ハイブリッド クラウド戦略を変革する方法など、従来の考え方に反するヒントを共有します。

（１）ビジネスの現実に基づいたハイブリッドクラウド戦略

ハイブリッド クラウドを純粋に技術的な選択と考えるのは自然なことです。これは、マーケティングやブランディング戦略ではなく、ソフトウェア、インフラストラクチャ、データの問題です。これは、クラウド コンピューティング ベンダー間の M&A 活動とはまったく関係がなく、ハイブリッド クラウドと HR 戦略について話し合うのに適した場でもないと思われます。

コンサルティング会社キャップジェミニの副社長兼北米クラウドセンターオブエクセレンス責任者であるライアン・マーフィー氏は、むしろ、ビジネス目標、人材、テクノロジー（ハイブリッドやマルチクラウドなど）によって推進されるべきだと語った。

「焦点はビジネスと目標を達成する手段に置かれるべきだ」とマーフィー氏は語った。 「買収ですか、それともスピンオフですか? 新しい事業部門ですか? コスト削減ですか? これらの重要な質問に答えることで、従来の資産に関するテクノロジーの決定を下すための基盤が築かれます。目標が異なればビジネス属性も異なるため、それをサポートするには異なるテクノロジー属性が必要です。」

ハイブリッド クラウドなどの主要なテクノロジーとアーキテクチャの決定に対してビジネス中心のアプローチを採用すると、テクノロジー戦略の大きな変化に対応するために事後にチームの俊敏性を高めることを要求するだけでなく、今日の IT チームがますます必要としている俊敏性を最初から高めることにも役立ちます。

「ビジネスはそれぞれ異なり、要件も異なりますが、まずは『可能性の芸術』、つまり望ましいビジネス成果とは何かから始めましょう。これにより、アプリケーション、インフラストラクチャ、人材の基盤が築かれ、ビジネスの統合と相互接続も強化されます。これが、迅速で機敏で、応答性が高く、効率的なビジネスとそうでないビジネスの違いです」とマーフィー氏は語った。

「可能性の芸術」の意味は、現在ではビジネスや経営を含め、さまざまな文脈で解釈されてきました。今日の言葉で言えば、これは目標を達成するための実際的な「物事を成し遂げる」アプローチと考えるのが最も適切です。つまり、最も理想的な結果を主張するのではなく、制約内で実際に可能なことを達成するよう取り組むことです。

（２）ハイブリッドクラウドは標準化を向上できる

ハイブリッド クラウドやその他の異機種混合インフラストラクチャは多くの場合より複雑であり、処理しなければならないものが増えるという事実には、ある程度の真実があるかもしれません。

適切なツールとプロセスを導入し、DevOps や DevSecOps などの文化的変化を取り入れることで、標準化と一貫性を実際に高めることができます。リバティ・ミューチュアルのシニアアーキテクトであるエリック・ドロビエフスキー氏は、あらゆるインフラストラクチャにわたる開発、運用、セキュリティの一貫したモデルを構築することが、同社がクラウドコンピューティング戦略で活用している価値の1つであると述べた。これは、混合環境にある企業にとって避けられない選択です。コンテナ化とオーケストレーションは重要です。

「当社はクラウド変革に向けて順調に進んでいますが、オンプレミスやプライベート クラウドでも多くのワークロードを実行しています」とドロビセフスキー氏は述べています。 「これにより、パブリック クラウドとプライベート クラウドのギャップを埋めるのに役立つクラウド コンピューティング テクノロジーが重要な要件となります。Kubernetes は、ハイブリッド マルチクラウド環境全体に展開できる共通ファブリックを作成する上で不可欠な要素となり、開発者が最新のクラウド ネイティブ ワークロードを展開し、既存のアプリケーションを最新化するための一貫したモデルを提供します。」

Kubernetes は、運用およびセキュリティ専門家の重要な作業を合理化および標準化する上でも不可欠なものとなっています。

「エンジニアリング チームと運用チームは宣言型プロビジョニングと構成の自動化を活用しており、これによりさまざまなインフラストラクチャ プロバイダーやバックエンド サービスとのやり取りが大幅に簡素化されます」と Drobiewski 氏は述べています。 「また、アドミッション コントローラーとオープン ポリシー エージェントを活用することで、一貫したソフトウェア定義のポリシー主導型アプローチを通じて、セキュリティ制御とガバナンスを向上させることができます。」

CloudBolt の CTO である Rick Kilcoyne 氏は、多くの人がどのクラウド プラットフォームを使用するかを気にしないかもしれないと指摘しました。むしろ、テストに使用されるラップトップから本番環境まで、場所を問わず環境間の一貫性を重視します。従来のアプローチでは、開発者がクラウドに特化した専門知識を持つことが求められるため、一部のクラウド展開では依然として構成の問題が残るとキルコイン氏は言う。

「抽象化は、マルチクラウドおよびハイブリッドクラウド環境への俊敏かつ安全で最適化されたアクセスの鍵となる」とキルコイン氏は述べた。 「開発者が開発環境にアクセスするために、認定されたクラウド専門家である必要はないはずです。」

（３）「ハイブリッドクラウド」の定義にとらわれない

「ハイブリッド クラウド」を構成するものを判断するのは難しい場合があります。この用語は一般に、パブリック クラウド、プライベート クラウド、またはオンプレミス (ベア メタル) サーバーの組み合わせを指し、通常、これらの環境間で何らかのレベルの統合またはオーケストレーションが行われます。

しかし、この定義にこだわりすぎないでください。実際、ハイブリッド クラウドにはオンプレミス サーバーがまったく含まれない場合もありますが、それはそれほど問題ではありません。

Red Hat のテクニカルエバンジェリスト Gordon Haff 氏はこう語った。 「ハイブリッド クラウドには、企業が所有および運営する施設内であろうと、コロケーション データ センター環境内であろうと、オンプレミスにあるサーバーを含める必要はありません。」

ハフ氏は、ハイブリッド クラウドにはオンプレミス サーバーがいくつかあるという前提について、次のように説明しています。「これは、2011 年に米国国立標準技術研究所が発表したクラウド コンピューティングの元の定義に遡ります。」

ハフ氏は、この定義ではクラウドコンピューティングは電力網に似た標準化されたコンピューティングユーティリティとして捉えられていると述べた。 「ハイブリッド クラウド」は、一時的な負荷の急増に対処するためにプライベート クラウドからパブリック クラウドに「バースト」したいというアイデアに基づいています。しかし、過去 10 年間で多くのことが変化しており、多くのハイブリッド環境にオンプレミス インフラストラクチャが含まれているものの、実際にそうする必要はありません。

「クラウド コンピューティングは一般に、米国国立標準技術研究所が当初特定した特性の多く (セルフサービス、柔軟性、拡張性など) を保持していますが、クラウド プロバイダーによって異なる、より豊富なクラウド ネイティブ サービスのセットを含むように拡張されています」とハフ氏は述べています。 「ハイブリッド クラウドには通常、オンプレミスのコンピューティングとストレージがある程度含まれますが、必ずしもそうである必要はありません。代わりに、パブリック クラウド プロバイダー、SaaS、コンテンツ配信ネットワーク (CDN)、およびその他の種類のアウトソーシングされた機能と機能の組み合わせを指す場合があり、多くの場合、ある程度統合されています。」

企業が詳しく検討する必要がある重要な領域は 2 つあります。ワークロードの移植性と予期しないコストです。

（4）すべてをクラウドで実行する必要はない

ハイブリッド クラウドやマルチクラウド (または単にクラウド コンピューティング) などの用語は、企業がワークロードのほとんどまたはすべてをクラウドに移行するという前提を暗示することがあります。同様に、そのようなルールがない場合、コンテナ内で実行するためにアプリケーションを移行または構築するからといって、企業がすべてをコンテナ化する必要があるわけではありません。

「さまざまなクラウド プロバイダーの中から選択するか、オンプレミス インフラストラクチャを引き続き使用するかの決定は、環境内のすべてのワークロードの客観的な「クラウド適合性」評価を行った後に行う必要があります」と、Brillio のクラウド変革サービス担当副社長である Fahim Khan 氏は述べています。 「また、1 つのクラウド ベンダーにすべて移行するか、ワークロードを複数のクラウド ベンダーに分散するか、一部のワークロードをオンプレミス インフラストラクチャ上に保持してハイブリッド クラウド環境で実行するかを検討する必要があります。」

「クラウド適合性」評価を構成する要素はさまざまですが、カーン氏はいくつかの基本原則を指摘しています。

• セキュリティとコンプライアンス。
• ワークロードとデータの移植性。
• コスト (異なる環境で実行されているワークロードの比較)。
• パフォーマンスとレイテンシに関する考慮事項 (たとえば、相互依存するワークロードを同じ環境にグループ化してレイテンシを削減する)。

（５）コストとパフォーマンスの最適化は自動ではない

ハイブリッド クラウドなどのマルチクラウド環境戦略は、多くの場合コスト最適化と関連付けられており、組織はワークロードにさらに多くのオプションを提供することで、インフラストラクチャ コストの適正価格を実現できます。ただし、これは設定された目標ではなく、予期しない出来事によってこの目標が損なわれる可能性があります。たとえば、データをクラウドに移動するとコストが削減される可能性がありますが、データをクラウドから移行すると予期しない費用が発生する可能性があります。

「パブリッククラウドベンダー間、およびプライベートクラウドとパブリッククラウド間のデータ送信コストは、計画されていない場合は増加する可能性があります」と、エアロスパイクの最高戦略責任者、レンリー・ヘンサリング氏は述べています。 「データ サービス上に API を定義して転送されるデータ量を最適化すると、コストを大幅に削減できます。アーキテクチャと設計の段階でこのコストを計画し、全体的なビジョンを持つことが重要です (オンデマンド インスタンスの実行コストに細かく焦点を当てるのではなく)。」

「設計時には、ソリューション全体のコストプロファイルも考慮する必要があります」とヘンサリング氏は言う。 「たとえば、大量のデータを扱う安定したワークロードの場合、オンプレミスのデータ ソリューションをマイクロサービスにバックアップする弾力性のあるフロントエンドを用意する方がよいでしょう。パブリック クラウド プロバイダーは弾力性のあるソリューションを提供しており、アプリケーションの拡張に合わせてインフラストラクチャを提供することができますが、そのコストは通常​​非常に高くなります。そのため、どのワークロードに弾力性が必要か、また、いくら支払ってもよいかを判断することが、物事を正しく進める上で重要です。」

ヘンサリング氏は、パフォーマンスの問題は、予期せぬ事態を避ける必要がある、あるいは少なくとも、同じパブリック クラウド プラットフォーム内であっても、パフォーマンスが一貫して最適であると過度に広く想定してはならない、という別の領域であると指摘しました。

「同じインスタンス クラス内であっても、インスタンス間の違いは非常に大きくなる可能性があります」と Hensarling 氏は述べています。 「ネットワーク帯域幅も大きく変動する可能性があるため、それを考慮して設計する必要があります。一貫して高いパフォーマンスを必要とするワークロードの場合、アプリケーションまたはその重要な部分をデータセンターまたはプライベート クラウドに配置することをお勧めします。そうすることで、インフラストラクチャとその管理をより適切に制御できます。」