オーケストレーション抽象化

　このアプローチの目的は、リソースを同じように見せるのではなく、リソース管理を同じように見せることだ。ある意味、オーケストレーション抽象化はクラウドプロバイダー同士の違いを取り除くのではなく吸収する。このマルチクラウド管理モデルの目標は、アプリケーションライフサイクルの各タスクを標準的かつ一貫した方法で行えるツールを使用して、オーケストレーションと自動化の手順を作成することだ。この管理モデルには、使用するホスティングプロバイダーやクラウドプロバイダーの組み合わせは関係しない。リソース抽象化は、ある意味、アプリケーションライフサイクルのプロセスより「下位」で行われる。これに対して、オーケストレーション抽象化は、単純に汎用のプロセスを特定のクラウドやデータセンターインフラに適応させる。

　最初の種類のオーケストレーション抽象化ツールは、広く利用されている仮想化フレームワークの拡張機能として提供される。例えば、「Kubernetes」はコンテナ向けにオーケストレーション抽象化を提供し、OpenStackはパブリックやプライベートのIaaSプラットフォームに抽象化を提供する。

　もう1つの種類のツールは、DevOpsの取り組みから生じる。こちらの方が「純粋な」オーケストレーション抽象化を提供する。DevOpsの目的はアプリケーションのデプロイの自動化にある。そのため、これを拡張して複数クラウド間のデプロイを標準化できる。一部のDevOpsツール、中でも「Chef」はアプリケーションライフサイクル管理（ALM）に関連するプロセスを標準化する。Puppet Labsの「Puppet」、Red Hatの「Ansible」のようなツールは、定義済みの運用状態に基づく。ソフトウェアは、構成を変えてその運用状態を実現する。業界ではこの2つ目のアプローチが好まれる傾向にある。そのため、ITチームはこのモデルを利用する方が簡単にマルチクラウドのオーケストレーション抽象化に適応させることができる。

　優れたオーケストレーション抽象化ツールは2つのレベルで機能する。まず、アプリケーションライフサイクルの各作業を一連の汎用（はんよう）プロセスで定義する。次に、プラグイン、つまり機能の2つ目のレイヤーが、この汎用モデルを特定のクラウドプラットフォームやデータセンターの具体的なニーズに適応させる。新しいクラウドプロバイダーを追加する場合は、新しいプラットフォーム上で機能の2つ目のレイヤーを定義するだけだ。

2つの抽象化モデルのどちらを選ぶか

　2つの抽象化アプローチのいずれかを選ぶ場合、各モデルの仕組みよりも既存のツールセットに注目する。既にDevOpsデプロイツールやALMツールを利用している企業であれば、それらのツールを拡張して、単一のクラウドやマルチクラウドのワークロードをホストするのが合理的な選択肢になる。新しいホスティングテクノロジー、中でも特にコンテナを利用する企業であれば、新しい仮想化やコンテナモデルと適切に対応するリソース抽象化を検討することになるだろう。

　プライベートクラウドとパブリッククラウドが混在するマルチクラウド環境を自社の最終目標にしている場合（実際に多くの企業に当てはまる）、結局全ての抽象化ツールが共通モデルに収束する可能性が高い。ただ、オーケストレーション抽象化がある程度リソース抽象化も提供する場合は、マルチクラウドにはオーケストレーション抽象化が適していると考えられる。純粋なリソース抽象化アプローチではホスティング機能の違いに対応できない。