CIOが対処すべきハイブリッドクラウドの課題

ハイブリッド クラウドから真のメリットを得るには、IT チームがアプリケーション開発に標準化されたアプローチを採用する必要があります。これを実現するための鍵となるのは、コンテナと Kubernetes かもしれません。

[[316556]]

CIO はハイブリッド クラウドを導入する際に、現実的な課題に直面します。パブリック クラウドの弾力性を活用しながら、データ センター、セキュリティ、コンプライアンスのルールに対応するアプリケーション モデルを作成する必要があります。

クラウド コンピューティングの最大の利点は俊敏性、つまり壊れたコンポーネントを交換したり、過負荷のコンポーネントをスケールアウトしたりできることです。しかし、CIO は、クラウド フロントエンドをハイブリッド クラウド アーキテクチャに組み込むと、予想よりも回復力が低くなることを発見しています。これは、これらのアプリケーションのバックエンドのデータセンター部分が、同じ俊敏性で問題に対応できないためです。実際、スケーラブルなクラウド コンピューティング フロントエンドは、オンプレミスのレガシー アプリケーションに過負荷をかけ、パブリック クラウドのメリットを相殺する可能性があります。

サードパーティベンダーとクラウドプロバイダーは、これらのハイブリッドクラウドの課題に対処するために、さらに多くのコンテナおよび Kubernetes サービスを追加していますが、オンプレミスモデルとパブリッククラウドモデル間の断絶は、今日の CIO にとって依然として大きな障害の 1 つです。

CIO がコンテナ、Kubernetes、PaaS モデルに注目する理由

コンテナ化されたアプリケーションと Kubernetes デプロイメントの組み合わせは、従来のモノリシック アプリケーションからマイクロサービス ベースのクラウド コンピューティング アプリケーションまで、さまざまなシナリオに適用できます。この戦略により、ハイブリッド クラウド全体での展開と再展開のプラクティスを統合できます。また、すべての主要なパブリック クラウド プロバイダーがコンテナーと Kubernetes をサポートし、マネージド Kubernetes サービスを提供しているため、マルチドメイン Kubernetes アプローチにより、複数のパブリック クラウドにわたるデプロイメントを統合することもできます。

ただし、コンテナ/Kubernetes アプローチはまだ不完全です。クラウドネイティブ コンポーネントの関係の複雑さを考えると、アプリケーションの展開にはワークフローの接続性とサービス検出のための完全なモデルが必要です。ただし、このようなモデルを実装するには、企業は開発フレームワークを必要とします。

企業は、Kubernetes コンポーネントのすべてについて共通の認識を持つ必要があります。

現在、PaaS はハイブリッドおよびマルチクラウド向けに再定義されています。プログラミングには、アプリケーションがハードウェア、ソフトウェア、およびネットワーク リソースにアクセスできるようにする言語と API セットが依然として必要だからです。 API はプラットフォーム、仮想コンピュータ、オペレーティング システムを定義します。この場合、これらはデータ センターとパブリック クラウド リソースの組み合わせを表します。新しい PaaS モデルが明確に定義されるまで、ハイブリッド クラウド ユーザーは、進化するアドオン セットを最適化して、独自の統合モデルを構築する必要があります。

修正された PaaS モデルの最も直接的な欠点は、ミドルウェアの一貫性の欠如です。企業には、サービスを検出し、コンテナーをワークフローにバインドし、負荷に応じてアプリケーションを拡張できるように条件を監視する標準化された方法が必要です。

組織全体で、異なるツールやプラクティスに依存するさまざまなアプリケーションが見つかることは珍しくありません。これらのアプリケーションがサービスとマイクロサービスを共有すると、全体的な運用コストと複雑さが増し、最終的には互換性の問題が発生します。

Kubernetesドメインを使用してハイブリッドおよびマルチクラウドの制御を一元化

オンプレミスとクラウドベースの資産を同期する最適な方法は、ハイブリッド クラウド インフラストラクチャを一連の Kubernetes「ドメイン」と考えることです。Kubernetes ドメインとは、通常、ドメイン内でコンポーネントが拡張および再デプロイされる Kubernetes クラスターです。そのため、複数のクラウド間またはクラウドとデータ センター間で拡張する場合は、境界ドメインのセットを定義する必要があります。これらには、ホストの拡張や弾力性などの側面を処理するために企業がパブリック クラウドとプライベート クラウドの境界で使用するリソースが含まれます。したがって、企業はこの分離をサポートするツールを選択する必要があります。

この新しい PaaS アプローチでは、企業の運用チームが独自の課題に直面することがよくあります。 Kubernetes を使用して開発する場合、ユーザーは特定のリソース要件やコンプライアンス リスクを定義する必要はなく、オペレーターが事後にこれらのコンテナーを分類してテストすることはほぼ不可能です。完全な PaaS レイヤーがないため、運用チームはポリシー制御をハイブリッド化する必要があります。

ドメイン分離されたクラスターはこの問題に対処し始めることができ、同様のコンテナ化されたアプリケーションのリソース ポリシーを定義して適用する方が簡単になります。ドメインに独自のセキュリティまたはコンプライアンス要件を持つコンテナがある場合は、ノードにラベルを付け、ポリシーを使用してポッドを適切なノードにフィルター処理するか、許容範囲を使用して回避ポリシーを適用する必要があります。

一貫性のあるKubernetesエコシステムの構築

Amazon Elastic Kubernetes Service や Google Kubernetes Engine などのマネージド Kubernetes サービスは、モバイルや Web の最新化の一環としてオンプレミス アプリケーション用のクラウド フロントエンドをデプロイするための魅力的なツールです。これらのサービスはすべて Kubernetes を中心に構築されていますが、各サービスが提供する要素が多すぎるため、プラットフォーム全体でアプリケーションを統合することが困難です。これにより、クラウド間のバックアップを増やしたり、環境間で拡張したりしたい企業にとって問題が発生します。

このハイブリッドおよびマルチクラウドの課題に対処するには、次の手順が必要です。

• アプリケーション モデルを定義します。
• Kubernetes エコシステムのアセンブリを一元化します。
• アプリケーション、インフラストラクチャ、Kubernetes エコシステムのトレンドを監視します。

開発モデルは、環境に多少固有の API から始まる場合もありますが、目標はハイブリッド フレームワークとマルチクラウド フレームワークにまたがるアプローチを作成することです。その他のすべての問題は、アプリケーションのニーズと仕様に合わせてプロセスを調整することで簡素化できます。

そこから、Kubernetes ツールキットを一元化して、企業のすべてのドメインにアプリケーションを展開します。これには、企業が使用を計画している Kubernetes および Kubernetes 関連ツールのセット全体が含まれる必要があります。企業は、ニーズに基づいて、最も広範なエコシステム フォーム ファクターで Kubernetes を網羅する単一の戦略を開発できます。

ツールやサービスを検討する際には、Red Hat や VMware などのオンプレミス ベンダーや、Google Cloud、Microsoft Azure、AWS などのクラウド コンピューティング プラットフォームを検討してください。必要に応じて、サービス検出、サービス メッシュ、監視と管理、マルチドメイン Kubernetes サポートを追加します。これらの機能は、マネージド Kubernetes サービスにますます含まれるようになっています。

これらのタスクを完了した後も、関連する最新のトレンドに注目し続けてください。以前の選択が最善ではなかったことがわかった場合は、戦略を調整する準備をする必要があります。急速に進化するこの分野では、先進技術を常に最新の状態に保つ必要があります。そうしないと、更新にかかる時間とコストが企業が負担できる範囲を超えてしまう可能性があります。