適切なハイブリッドクラウド管理アプローチを選択する方法

ハイブリッド クラウド管理 (HCM) 市場は最近まで停滞していましたが、最近になって状況は一変しました。多くの組織がクラウド コンピューティング管理の課題に取り組み始めており、クラウド コンピューティング戦略を採用している組織のインフラストラクチャ意思決定者の半数以上が、使用状況を積極的に監視し、効果的なクラウド コンピューティング戦略を策定しています。

多くの企業は、クラウド コンピューティングの管理とガバナンスの問題を解決するために、ハイブリッド クラウド管理 (HCM) ツールを導入する必要があるという結論に達しています。しかし、多くの企業にとって、マルチクラウド管理の負担は、費用を正当化するほど大きくなっていません。組織が HCM ベンダーが提供するオプションを検討する前に、まず HCM が実際に問題を解決できるかどうかを理解する必要があります。

[[259537]]

機能セット

この市場の初期には、「第 1 世代」製品はハイブリッド クラウド管理 (HCM) 専用に設計されたものではなく、その目的のために再利用されていました。例としては、BMC Cloud Lifecycle Management、IBM Cloud Orchestrator、Micro Focus Cloud System Automation (CSA) などがあります。

現在、これらの製品の位置付けは曖昧になっており、第一世代製品のサプライヤーはそれらを完全に更新し、より多くの新世代製品を発売しています。

最近の会話は、機能の幅広さ/深さと、複雑なハイブリッド クラウドの使用例に対する明確な使いやすさという 3 つの主要なテーマに集中しています。フル機能の深さとクラス最高の代替品による構成可能性の比較。プラグインではなくアプリケーション プログラミング インターフェイス (API) を介して外部ツールに統合します。

結果として得られるツールを検討するときは、機能セットの深さ/幅、構成可能性、および統合に注目してください。第 1 世代の製品の数が膨大であるため、深さと幅の観点からは単純ではなく、それが製品の不利益と価値の両方に影響を及ぼしています。

これらの製品は、機能の深さと幅を維持しながら、大幅な近代化と改善が行われてきました。これは、多数のハイパーバイザーとクラウド プラットフォームを管理するための複雑なユース ケースに対応するためです。

高度な企業やサービス プロバイダーは、オンプレミス プラットフォームに対してきめ細かな管理機能と充実したサポートを提供する第一世代のツールを求めることがよくあります。他のソリューションは、明確なインターフェースを使用して差別化を図っています。

組織が一般的なテクノロジーを使用した単純なユースケースを持っている場合、より軽量なツールがニーズを満たし、全体的なエクスペリエンスも向上します。

構成

構成可能性の点では、包括的なツールは幅広い機能を提供し、統合を簡素化し、1 つのツールで多くの問題を解決できるようにします。しかし、これにより、組織は複数のレベルでテクノロジーを導入せざるを得なくなります。

企業は現在、独立性、ソリューション全体の標準化、各機能部分への依存性の最小化を伴う構成可能性を求めています。

機能が不足しているベンダーは、リエンジニアリングではなく、コンポーザビリティのスタンスを強調することで、機能不足を補うことに大きく依存しています。

経験豊富なベンダーは、製品内でユーザーが選択できるソリューションを提供しており、その機能を別の機能に交換することもできます。

Ansible、Chef、Helm、Kubernetes、Puppet、Splunk、Terraform などの一般的なツールとの統合は、今日のハイブリッド クラウド管理 (HCM) プロバイダーの間では一般的です。

ビルド統合

ベンダーは、需要または必要性に応じて顧客向けの統合の構築に投資し、コア機能が不足しているベンダーは、統合によってサービスを補完することを選択する場合があります。

その他の統合は、リクエスト、競争力を維持する必要性、またはサードパーティやパートナーによって開発されたプラグインを通じて実現されます。

ただし、事前に構築されたプラグインに加えて、ほとんどの HCM ツールでは API の多くが公開されているため、開発者やシステム管理者は独自の統合を構築できます。ユーザーからの圧力が高まるにつれ、多くのベンダーが使用中のすべての API を完全に公開するようになりました。追加のサポートがなければ統合の構築には時間がかかりますが、プロバイダーよりも速く接続できる可能性があります。

ただし、この速度には継続的なコストがかかります。これにより、統合はどちらかの当事者によってほとんどまたはまったく警告なしに変更される可能性が高くなるため、統合を待つことが、それらの統合を長期的に維持する必要がないという苦痛に見合う価値があるかどうかが問題になります。

管理方法を選択する

クラウド コンピューティング管理には、2 つの異なるミッション ステートメントがあります。基盤となるクラウドを見えなくすること。または、クラウド リソースの管理をクラウド ユーザーから見えなくすることもできます。

HCM ベンダーは、「目に見えないクラウド」というコンセプトにより、管理者や開発者向けに新しいリソースをプロビジョニングするための単一の制御ポイントとして機能する機能がプラットフォームに多く提供されるため、この選択肢を制限する場合があります。

このツールはクラウド コンピューティング時代以前に登場し、クラウド プラットフォーム上でエクスペリエンスとルールセットを作成しましたが、開発者中心の考え方が欠けていました。開発者は、この経験を活用して新しいリソースをリリースする必要がありますが、開発者は独自の経験とツールを選択したいと考えています。

インフラストラクチャとソフトウェアをサービスとして使用しようとしている組織にとって、コスト管理が優先されるべき理由を検討します。

ここでは、ハイブリッド クラウドによって管理が複雑なインフラストラクチャが作成される理由について説明します。多くの専門家は、特に開発者中心の組織では、「目に見えない管理」がより現実的なミッションステートメントであると考えています。

ほとんどのハイブリッド クラウド管理 (HCM) ベンダーでは、「インビジブル クラウド」がデフォルトのオプションとして含まれていますが、「インビジブル管理」が優先されるアプローチである場合は、これをバイパスできます。

実際には、これにより、クラウド コンピューティングを暗黙的にネイティブ API に変換する抽象化が提供されます。これを行う最善の方法は何ですか?さまざまな API と形式のセットからデータ ソースを取得できる API レイヤーを作成します。

一部の HCM ソリューションでは、同じ API レイヤーを使用して、その指示をそのプロバイダーのネイティブ API リクエストに変換し、プロバイダーによって指定された特定のコンプライアンス ルールや指示を含むシム レイヤーを提供することがよくあります。

標準化リソース

シムが存在するにもかかわらず、プロビジョニングされたリソースは、使用中のクラウド プラットフォームのネイティブ プラットフォーム API で標準化されます。 HCM 契約が終了した場合、それは戦略の一部に過ぎず、既存のリソースをオンボーディングするにはテンプレートを HCM 形式に変換する必要があります。

また、組織は目に見えないクラウド管理を理解する必要があり、異なるプラットフォーム間で構成するという一見単純なタスクを許可するのは難しいことです。

ほとんどの HCM ツールは管理ツールと開発ツールの両方になることを目指しており、さまざまなエクスペリエンスでテンプレートを他のプラットフォームにエクスポートする必要があります。ネイティブ テンプレートを独自の分析後モードに即座に変換します。または、ネイティブ テンプレートを維持しながら、ポリシーに違反した場合に事後修復を提供します。

あまり侵入的ではないアプローチでは、事後のコンプライアンスが遅れ、大量の手作業が必要になる可能性があり、求められている代替アクセスを取得するための当初の生産性が台無しになります。ワークロード変換などのより侵入的なアプローチが採用されることが多く、多くの場合、HCM ポータルから直接利用できるのと同じアクションをワークロードに対して実行できるようにします。

実用的なクラウドコンピューティングの時代が到来しました。どのツールが優れているか、どのベンダーが勢いを持っているかに関係なく、最終的には組織に適したソリューションが必要です。

実際には、組織は最適なハイブリッド クラウド管理製品を選択する必要はありません。一部の機能は大きな影響を与える可能性がありますが、他の機能は使用可能の範疇に収まります。

ハイブリッド クラウド管理オプションの中にはコストがかかるものもあり、各クラウド プラットフォーム、ツール、サービスが予算の大きな部分を奪い合うため、クラウド管理に関しては十分な機能を備えた軽量なソリューション、つまり組織の他のニーズをより適切に満たすソリューションが必要になる場合があります。