組織がビジネス機能の継続的な開発、デリバリー、統合のためにDevOpsに注目する中、綿密な管理が不可欠です
組織は、コードが定められた期間内に生成され、運用システム管理やアプリケーション管理と組み合わされる従来のウォーターフォール型およびカスケード型のソフトウェア開発から、よりアジャイルなアプローチへと移行しています。
継続的インテグレーション、継続的開発、継続的デリバリーによる迅速な機能提供へのニーズが高まるにつれ、多くの企業がDevOpsプロセスの導入を検討しています。
DevOpsは、開発、テスト、運用チームを統合し、コードと機能アプリケーションがこれら3つの領域間を効率的に移動することを目指しています。
しかし、プロセス全体が円滑に進み、ビジネスにとって最大のプラス効果を最小限のマイナス影響で実現するためには、適切なフィードバックループを備えた高度な管理が必要です。
開発者主導の移行
組織にとっての問題は、DevOpsが急速に拡大しているにもかかわらず、トップダウンではなくボトムアップで拡大していることです。
多くのDevOpsツールはオープンソースソフトウェアとして提供されており、組織内の個人が自分に合ったツールをダウンロードして使い始めるのに何の障壁もありません。
開発や運用に携わる多くのスタッフにとって、これは見逃せない絶好の機会です。開発者は、IBM Rational Software ArchitectやMicrosoft Visual Studioといった商用システム、あるいはEclipseのようなオープンソースシステムなど、既存の統合開発環境（IDE）に組み込めるダウンストリームシステムを探していました。https://www.eclipse.org/downloads/)** または **[アンジュタ](https://wiki.gnome.org/Apps/Anjuta（）**、またはAtlassian Jira SoftwareやCA PPMなどのソフトウェアプロジェクト管理ソフトウェア。
オプションの拡張
これらのツールの機能は、2005年（Puppet）、2009年（Chef）、2011年（Jenkins。Jenkinsは、2004年にSun Microsystemsが開始し、現在はOracleが所有するHudsonプロジェクトの成果を継承したものです）に市場に登場して以来、大きく向上しました。
これらのツールの機能は、わずか数年前と比べてはるかに相互に重なり合っており、完全なDevOps環境を構築するために他の個別ツールを導入する必要性は以前よりも低くなっています。
チームワークと完全なフィードバックループのサポートが強化されたことで、当初は個人向けの個別ツールだったものが、今ではグループ、さらには分散した拠点や、契約社員やコンサルタントなど複数の企業にまたがるグループまで、あらゆるグループを完全にサポートするようになりました。
これら3つの巨大ツールに加えて、AnsibleやSaltなど、同じ領域に属する様々なオープンソースライセンスのツールや、DockerやKubernetesなどのコンテナソフトウェア管理システムに組み込まれたツールも存在します。Ubuntuに統合されたエンタープライズサポートのアプローチとしては、Canonicalが独自のディストリビューションである**[JuJu経由のKubernetes](https://www.computerweekly.com/blog/Open-Source-Insider/AppScale-FastStart-for-Google-Compute-Engine-AWSKubernetesは、DevOps環境で活用できるコンテナオーケストレーション分野において、急速に新たな勢力として台頭しています。Cloud Native Computing Foundation（CNCF）がKubernetesをサポートしており、CNCFにはAmazon Web Services（AWS）、Google、Microsoft、IBM、Intel、Twitterなどがメンバーとして名を連ねています。
Cloud Foundryもまたオープンソースシステムであり、前述の多くのオープンソースツールと同様に商用サポートも提供されています。Cloud FoundryはDevOpsに適した自動化機能を提供し、上流および下流のシステムに対して高度なサポートを提供できます。Cloud FoundryもCNCFのメンバーですが、Kubernetesと機能的に重複する部分もあります。しかし、コンテナ環境を超えた幅広い範囲に対応できるという点で、Kubernetesよりもはるかに優れています。Cloud Foundry内のKuBo（Kubernetes on BOSH）と呼ばれる別のプロジェクトは、異種アプリケーションコード、仮想マシン（VM）、またはコンテナ環境で作業するユーザー向けに、Cloud FoundryとKubernetesを統合したスタックを提供します。
ツールの多さ
個々の開発者やシステム管理者がそれぞれ独自のやり方でIT環境を構築し、様々なツールが混在する状況は、組織にとって大きな問題となり得ます。この問題への対処法は主に2つあります。
まず、指示を出すことです。使用するツールセットを1つに絞り、すべての開発者とシステム管理者が同じツールセットを使用するよう徹底します。しかし、残念ながら、これはほぼ失敗に終わるでしょう。相手は開発者やシステム管理者であることを忘れてはなりません。彼らの机の引き出しを開けてみれば、日々の業務で個人的に利用している非公式ソフトウェアが入ったCDやUSBメモリがいくつも見つかるはずです。彼らはツールを1つに統一する必要性については同意しているように見えても、あなたが目を離した隙に独自のやり方を続ける可能性は十分にあります。
そして、組織は「自分は正しい」という思い込みに陥ります。全員に指示通りに行動するよう命じた以上、それが当然のことだと信じ込んでしまうのです。そして、何らかの問題が発生し、事後検証によって問題点が明らかになります。それは、機能がバラバラに分散し、統一された監視体制が全く存在しない状態です。
次に、現実的な対応が必要です。もはや手遅れであることを受け入れ、個別に使用されているツール群を混沌とした状態から、よりエンタープライズレベルのシステムへと統合する方法を模索しなければなりません。
多くのオープンソースツールは、プラグインの利用拡大やオープンなアプリケーションプログラミングインターフェース（API）の活用により、他のオープンソースツールからの入力を高い精度で受け入れることができます。
より高度な制御と、エンタープライズレベルの包括的なサポートが必要とされる場合は、Jenkinsやその他のレイヤードコンポーネントをサポートするCloudBeesなど、オープンソースソフトウェアのディストリビューションのフルサポート付きサブスクリプションを利用することで、組織が求める「エンタープライズレベル」を実現できます。
オープンシステムは長期的な運用を可能にする
さらに、既存のツールをサポートするために高いオープン性を備えた商用システムも存在します。例えば、CA Automicは、DevOpsプロセスの効率化に優れた自動化アプローチを提供すると同時に、様々な基盤ツールをオープンな形で受け入れます。
このようなシステムにおいて、様々な基盤ツールを柔軟に切り替えられる機能は非常に重要です。5年前には、**[ChefとPuppet](**について語る人はほとんどいませんでした。**https://searchitoperations.techtarget.com/tip/How-the-Puppet-architecture-manipulates-configurationsKubernetesがリリースされたのはわずか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環境を最大限に活用するには、厳格なツールが必要となりますが、これは規定的なルールや禁止的なルールによって実現できるものではありません。現実的なアプローチを取りましょう。既存の混乱に秩序をもたらす包括的なシステムを提供し、開発者やシステム管理者がそれぞれにとって最適な方法で作業できるようにすべきです。
