Chefが今日(米国時間6/14)、Habitatをローンチした。それはアプリケーションを、いろんなインフラストラクチャの上でそのまま動けるようにパッケージする、オープンソースのプロジェクトだ。
Habitatは基本的に、アプリケーションを独自の軽量ランタイム環境で包み、それらをどんな環境でも動けるようにする。ベアメタルのサーバー、仮想マシン、Dockerコンテナ(+そのコンテナ管理サービス)、Cloud FoundryのようなPaaSシステム、などなど。
“アプリケーションをインフラストラクチャへの依存性から解放して、DevOpsが本来の仕事をできるようにすべきである”、とChefの協同ファウンダーでCTOのAdam Jacobが今日の声明で述べている。“オープンソースソフトウェアは世界中でこれからもどんどん作られていく。そんな中へHabitatを送り出すことは、たいへんすばらしい。アプリケーション中心の自動化が、現代の開発チームに彼らが本当に望むものを与える。それは、新しいアプリケーションを作ったら、ややこしいインフラの工事をいっさいしなくても、それをすぐに動かせることだ”。
Chefのチームによると、最近のソリューションはどれも、あまりにもエンタープライズへ視野狭窄していて、どの企業の環境も独自に深くサイロ化しているので、“われわれはソフトウェアを個々のサイロに合わせていちいち再設計しなければならない”、という。一方GoogleやFacebookのようなWebスケールの企業は独自のプラットホームをスクラッチから作り、それを作ることが彼らのビジネスになっているが、それはどんな企業にもできるやり方ではない。
そこでHabitatは、アプリケーションの見地から見て、アプリケーションを作り、デプロイし、管理するためのベストの方法は何か?、という問に答えようとする。それは、インフラストラクチャを定義するのではなく、アプリケーションが動くために何を必要とするか、を定義し、そこから出発する。そして、一種の“スーパーバイザー”であるHabitatがデプロイを担当し、またあなたがそこにデプロイしたいと考えている環境の、アップグレードやセキュリティポリシーの面倒も見る。
Chefのチームによると、レガシーのアプリケーションをHabitatに移植するのは、かなり簡単だそうだ。
Habitatのそんな約束は、そもそも、かねてからコンテナについて言われていたことと似ている。でもChefによると、Habitatはコンテナ体験を改良し、コンテナ管理の複雑性を大幅に減らした。そこで、ある意味ではこのプロジェクトは、コンテナに対するChefの反応のようでもある。コンテナは、少なくとも部分的には、同社のコアビジネスを脅(おびや)かしているのだ。そして当然ながらHabitatは、Chefの既存のDevOpsツールと問題なく併用できる。