そうした製品は、機能の奥深さと幅広さを保ちながら、大幅に現代化され、改善されてきた。その目的は、膨大な数のハイパーバイザーとクラウドプラットフォームの管理を視野に入れた、複雑な用途に対応することにある。

　高度に複雑化した大企業やサービス事業者は、きめ細かいガバナンス機能やオンプレミスプラットフォームに対するサポートの奥深さを求めて第1世代製品に目を向けることもある。他の製品はクリーンなインタフェースを採用し、導入スピードで差別化を図っている。

　もし一般的な技術を使ったシンプルな利用場面が想定されるのであれば、全般的な使い勝手の良さを提供する軽量ツールの方がニーズに合っている。

組み立て可能性

　包括ツールにはあらゆる機能が搭載されおり、インテグレーションのシンプル化を図ることができ、1つのツールで多くの問題を解決できる。半面、複数のレベルでその技術に囲い込まれることになる。

　企業は今、独立性やソリューションを横断する標準性、各機能分野についてそれぞれ最高の性能を求めて、組み立て可能性に目を向けるようになった。

　機能性に欠けるベンダーは組み立て可能性を重視して、既存の技術を再発明しないスタンスに脚光を当てることによって自分たちに欠ける機能を補っている。

　もっと年季を積んだベンダーは、製品の中で「ユーザーが選択できる」ソリューションを提供し、特定の機能を代替の機能と入れ替えられるようにしている。

　「Red Hat Ansible」「Chef」「Helm」「Kubernetes」「Puppet」「Splunk」「Terraform」といった人気ツールの取り込みや連携は、HCMベンダーの間で一般的になっている。

インテグレーション

　ベンダーは需要や必要性に応じて、顧客のためのインテグレーション構築に投資している。中核的な機能に欠けるベンダーが、インテグレーションを通じたサービスの補完を選ぶこともある。

　他にもリクエストに応じたインテグレーションや、競争力を保つためのインテグレーション、サードパーティーやパートナーが開発したプラグイン経由のインテグレーションもある。

　ただ、既成のプラグインに加えて、HCMツールの大部分は自身のAPIのほとんどについて文書を公開し、開発者やシステム管理者が独自のインテグレーションを構築できるようにしている。ユーザーからのプレッシャーが強まる中で、多くのベンダーはAPIを全て、例外なく全面的に公開するようになった。インテグレーションの構築は、追加的なサポートがなければ時間がかかるかもしれない。それでもベンダーよりも早く接続を提供できる可能性がある。

　ただしそのスピードは継続的なコストを伴う。こうしたインテグレーションは、いずれかの側がほとんどあるいは一切予告なしに行う変更に対して脆弱（ぜいじゃく）になる。そうしたインテグレーションを長期間にわたって維持する負担を考えた場合、インテグレーションを待つに値するかどうかを問い掛ける必要がある。

管理アプローチの選択

　クラウド管理には2つの異なるミッションステートメントが存在する。根底にあるクラウドが見えないようにすることと、クラウドリソースの管理がクラウドユーザーに見えないようにすることだ。

　HCMベンダーはこの選択肢を狭めるかもしれない。「見えないクラウド」のコンセプトは管理者と開発者の両方にとって、新しいリソースをプロビジョニングするための単一のコントロールポイントとしてのより大きな権限をプラットフォームに与える。

　このツールはクラウド利用の前面に出され、一つのエクスペリエンスとクラウドプラットフォームを横断する一連のルールをつくり出す。だがそこには開発者中心の思考が欠如している。ここでは開発者がこのエクスペリエンスを使って新しいリソースを立ち上げることを前提としているが、開発者は自分自身のエクスペリエンスとツールを選びたいと考える。

　多くのスペシャリストは、特に管理者中心の組織においては、「見えない管理」の方が現実的なミッションステートメントだと判断している。

　ほとんどのHCMベンダーは、「見えないクラウド」をデフォルトのオプションとしている。「見えない管理」を好む場合は、そのオプションを無効にできるようにしている。

　現実的には、見えないクラウドの提供は、ネイティブAPIからの抽象化につながる。最新のアプローチは、さまざまなAPIやフォーマットからデータソースを取り込めるAPIレイヤーを作成する。

　一部のHCM製品は、同じAPIレイヤーを使って、自分たちのコマンドをそのベンダーのネイティブAPIリクエストに変換する。特定のコンプライアンスルールやベンダーの決めた方向性を含む「shim」レイヤーを提供することもある。

標準化されたリソース

　shimにかかわらず、プロビジョニングされたリソースはクラウドプラットフォームのネイティブプラットフォームAPIの上に標準化される。HCM契約を解消した場合、ポリシーのshimがなくなるにすぎない。だが既存のリソースを搭載するためにはそのHCMフォーマットへのテンプレート変換を必要とする。

　見えないクラウド管理に目を向けると、異なるプラットフォームを通じたプロビジョニングを可能にするという一見単純な作業に難点がある。

　ほとんどのHCMツールは、管理ダッシュボードと開発者ダッシュボードの両方になろうとしている。異なるエクスペリエンスを使うためには、テンプレートを他のプラットフォームにエクスポートする必要がある。その方法は、ネイティブテンプレートを自分たちの事後のテンプレートに直ちに変換するか、ネイティブテンプレートを維持しながら、ポリシー違反があれば事後の是正措置を提供するかのいずれかになる。

　煩わしさの少ない事後是正の場合、コンプライアンスに遅れが生じて数多くの手作業が必要になり、代替アクセスによって追求した生産性の向上が相殺されることもある。ワークロードに対してHCMポータル経由で直接プロビジョニングしたものと同じ動作を保証するため、例えばワークロードの変換のように、もっと手間の掛かる手段が取られることもある。

　実用的なクラウドの時代が到来しつつある。どのツールが良さそうに見えるのか、どのベンダーに勢いがあるのかは問題ではない。最終的には、自分の組織に合ったソリューションが必要とされる。

　実際のところ、自分に課せられた仕事は世界最高のハイブリッドクラウド管理製品を選ぶことではない。自分の組織に重大な違いをもたらす機能もあれば、持っていても悪くない程度の機能もある。

　単純にコストが高過ぎるオプションもある。あらゆるクラウドプラットフォームやツールやサービスが、予算を獲得しようと競い合っている。クラウド管理に関しては、自分の会社の他のニーズのための予算に合致した、必要最低限の機能のみを備えた軽量ソリューションに落ち着くかもしれない。関連記事

https://techtarget.itmedia.co.jp/tt/news/1905/09/news01.html

AWSの独走状態に陰り？　クラウドトップ3に変化の兆し

https://techtarget.itmedia.co.jp/tt/news/1801/23/news01.html

「クラウド間の容易なシステム移行」は幻想にすぎない