最新ハイブリッドクラウド管理製品の見落とせないポイント：Computer Weekly製品ガイド
クラウド管理問題の解決を目指す企業が考慮すべきさまざまな要因を解説する。
ハイブリッドクラウド管理（HCM）市場は長期にわたって停滞気味だったが、最近その状況が変わった。
クラウド管理やガバナンスの課題に取り組むにはHCMツールの調達が必要であるという結論に至る企業はあまりに多い。だがそうした企業の多くはまだ、クラウド管理の負荷が支出を正当化できるほどの痛みを伴う状況には至っていない。HCMベンダーから調達できる選択肢について掘り下げる前に、HCMで本当に自分たちの問題が解決できるかどうかを問い掛ける必要がある。
関連記事
機能セット
この市場の初期段階において、「第1世代」という用語は、この用途専用に開発された製品ではなく、用途を切り変えた製品を指すものだった。一例として、「BMC Cloud Lifecycle Management」「IBM Cloud Orchestrator」「Micro Focus Cloud Service Automation」などが挙げられる。
第1世代製品のベンダーは他の製品を売り出したり、革新的なアップデートを開発したり、さらに新しい世代の製品を打ち出したりしている。
直近になると、3つの中核的課題に注目が集まるようになった。すなわち、複雑なハイブリッドクラウドの利用を想定した機能の
- 「幅広さ・奥深さ」対「使い勝手の良さ」
- 「フル機能の奥深さ」対「クラス最高の代替製品への組み立て可能性」
- 「外部ツールと連携させる手段としてのAPI」対「プラグイン」
という課題だ。
ツールの世代について検討する際は、機能の奥深さと幅広さ、組み立て可能性、インテグレーションに目を向ける必要がある。奥深さと幅広さという観点においては、第1世代の重い製品は損失と価値の両面においてシンプル性に欠ける。
そうした製品は、機能の奥深さと幅広さを保ちながら、大幅に現代化され、改善されてきた。その目的は、膨大な数のハイパーバイザーとクラウドプラットフォームの管理を視野に入れた、複雑な用途に対応することにある。
高度に複雑化した大企業やサービス事業者は、きめ細かいガバナンス機能やオンプレミスプラットフォームに対するサポートの奥深さを求めて第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/spv/1905/09/news01.html
AWSの独走状態に陰り？ クラウドトップ3に変化の兆し
https://techtarget.itmedia.co.jp/tt/spv/1801/23/news01.html
「クラウド間の容易なシステム移行」は幻想にすぎない
Copyright © ITmedia, Inc. All Rights Reserved.