組織にとっての問題は、DevOpsの成長が急であり、トップダウンでの管理ではなくボトムアップの成長である点だ。DevOpsツールの多くはオープンソースソフトウェアだ。組織内の個人が、自分にとって魅力のあるツールをダウンロードして使い始めることに、何の障害もない。

　多くの開発あるいは運用担当者にとって、このチャンスに背を向けるのはあまりに惜しい。開発者は、今ある統合開発環境（IDE）と連携できるダウンストリームシステムを求めてきた。それは「IBM Rational Software Architect」や「Microsoft Visual Studio」のような商用製品だったり、「Eclipse」や「Anjuta」のようなオープンソースだったり、「Atlassian Jira Software」や「CA Project Portfolio Management」のようなソフトウェアプロジェクト管理ソフトウェアだったりすることもある。

　それは開発や運用スタッフによる「Jenkins」「Chef」「Puppet」のようなツールの利用増大につながった。Jenkinsはソフトウェアのバージョン管理プロセスを自動化できる。また、「Perforce」「CVS」「Subversion」「Git」「AccuRev」といった既存のバージョン管理ツールと連携できるプラグインや、継続的なデリバリーのためのスリム化されたプロセスを備える。ChefとPuppetは、DevOpsの「Ops」側に重点を置いてスタートしたツールで、構成管理定義を使って作成した機能パッケージを自動的に運用環境にプロビジョニングできる。

選択肢の拡大

　こうしたツールの機能は、初めて市場に登場したPuppet（2005年）、Chef（2009年）、Jenkins（2011年）以来、大幅に進歩した。

　それぞれの機能は互いに交差する部分が増え、完全なDevOps環境を構築するために別のポイントツールを導入する必要性は以前に比べると薄れている。

　チームワークとフィードバックループに対するサポートが強化されたことで、当初は個人のためのポイントツールだったものがグループに完全対応するようになり、業務委託先やコンサルタントといった会社を横断して、分散した拠点間で連携するグループにも対応できるようになった。

　この3大ツールの他にも、各種オープンソースライセンス下で利用できる同じ分野のツールとして「Ansible」や「Salt」などがある。「Docker」や「Kubernetes」のコンテナソフトウェア管理システムのようなツールもある。「Ubuntu」を統合したエンタープライズサポート型のアプローチ向けには、Canonicalが「Juju」を通じて独自のKubernetesディストリビューションを提供している。コンテナオーケストレーションの分野において、Kubernetesは急速に新しい勢力になりつつある。Kubernetesを支援するCloud Native Computing Foundation（CNCF）には、Amazon Web Services（AWS）、Google、Microsoft、IBM、Intel、Twitterなどがメンバーとして名を連ねる。

　もう1つのオープンソースシステムである「Cloud Foundry」も、前述した他のほとんどのオープンソースツールと同様に、やはり有償サポート付きのシステムが提供されている。Cloud FoundryはDevOpsにうまく合った一連の自動化機能を提供し、他のアップストリームおよびダウンストリームシステムに高いレベルのサポートを提供できる。Cloud FoundryもCNCFのメンバーで、ある程度Kubernetesと重複する部分はあるものの、コンテナ化された環境を超えた到達度でははるかに先を行く。Cloud Foundry内の別のプロジェクトである「KuBo（Kubernetes on BOSH）」は、アプリケーションコードや仮想マシン、コンテナが混在する環境向けにCloud FoundryとKubernetesの統合スタックを提供している。

ツール過多

　個々の開発者やシステム管理者が独自の道を行く状況は、IT環境全体にさまざまなツールが混在する状況につながり、組織にとっては問題になりかねない。この状況には以下の2つのいずれかのやり方で対応できる。

1．規範を定める

　利用するツールを1つのセットに決めて徹底させる。開発者とシステム管理者全員が同じツールのセットを使わなければならない。残念ながら、このやり方は失敗に終わる確率が大きい。何しろ相手は開発者とシステム管理者だ。デスクの一番上の引き出しには、役立つと思った無許可のソフトウェアを収録したCD-ROMやUSBメモリが幾つも入っている。ツールを統一する必要性に同意しているように見えても、見られていないところで独自のやり方を続けている可能性はかなり大きい。

　ここで組織は正しさという概念に陥りがちだ。言われたことを守るよう全員に指示しておけば、それが守られると思い込む。そして何か問題が起き、事後調査の結果、問題が発覚する。まとまりのない機能が点在する状況に、単一の監視は行き届かない。

2．現実を受け入れる

　既に手遅れだという現実を受け入れ、個人がバラバラのツールを使用している混乱状態を、よりエンタープライズに対応した状況へと変える手段を見つけ出す。

　オープンソースツールの多くは、プラグインやオープンなAPIの使用を通じて、それなりのレベルから高いレベルで他のオープンソースツールと連携させることができる。

　さらに高いレベルのコントロールとエンタープライズレベルのサポートが求められる場合、オープンソースソフトウェアのディストリビューション（例えばJenkinsや追加のコンポーネント層をサポートした「CloudBees」など）を完全サポート込みでサブスクリプション契約すれば、組織が求める「エンタープライズ性」が提供される。

オープンソースシステムが実現する長寿性

　これに加えて、既存のツールにかなりの程度のオープン性を導入できる商用システムも存在する。具体例の1つとして、「CA Automic」はDevOpsプロセス合理化へ優れた自動化のアプローチを提供しながら、各種の基盤ツールをオープン方式で受け入れている。

　そうしたシステムでは、さまざまな基盤ツールを入れ替えられる点が重要だ。5年前にはChefやPuppetが話題になることはあまりなく、Kubernetesがリリースされたのはわずか3年前だった。5年後の市場はどんな様相になっているのか。もし、過度に行き渡った包括システムが閉ざされたシステムで、決められたツールにしか接続できないのであれば、いずれは取り残されかねない。もしそれがオープンソースツールで、機能のプラグインやプラグアウトが可能であれば、新しく登場するツールを取り込むことができる。

　DevOpsの分野に参入している企業は他にも数多い。例えばHashiCorpは複数のツールを提供しており、このうち「Terraform」や「Vagrant」は、DevOps環境をよりシンプルに運用する助けになる。Perforceは中核事業のバージョン管理から始め、幅広いDevOps機能を提供するツールのポートフォリオ「Helix」を立ち上げた。

　旧式のシステム構成管理ソフトウェアの世界も進化している。BMCは自動化スイート「BladeLogic」を提供する。クラウドやコンテナを取り入れて現代化した「BladeLogic Server Automation」は、「Atrium Orchestrator」「Control-M Automation」「TrueSight」のような他のBMC製品と組み合わせてDevOps機能を提供できる。

　HPEのインフラは、ハードウェアとソフトウェアの溝を橋渡しして論理プラットフォームを簡単に構成し、「OneView」を通じて物理／仮想あるいはコンテナ化されたソフトウェアをプロビジョニングできる。

　当然ながら、インザクラウドのDevOpsという選択肢もある。IBMは「Bluemix」で幅広い機能を提供している。AWS、Google、Microsoftはそれぞれのプラットフォームで直接的にツールを提供し、これまでに紹介したツールの多くも、こうした各社のクラウドでセルフサービスモードを介して実装できるようになっている。

　DevOpsは、企業が求め必要としているもの、すなわち必要に応じて迅速に提供できる新機能の継続的な開発を実現する中心的な手段になりつつある。なお、そうしたニーズや欲求は、開発者ではなくビジネスによって決定されるべきものであり、本来は「BusDevOps」と呼ぶ方がふさわしい。

　そうしたBusDevOps環境を最大限に活用するためには適切なツールが必要だが、規範や禁止を定めたルールを通してそれが入手できる公算は低い。現実を受け入れ、現状の混乱に秩序をもたらし、開発者やシステム管理者が自分たちにとって理にかなったやり方で作業できる包括的なシステムを提供する必要がある。

本稿筆者のクライブ・ロングボトム氏は調査会社Quocircaの創業者。