The makers of the configuration management platform Chef, typically mentioned in the same breath with Puppet, Salt, and Ansible, is taking on application automation applications. Habitat, its new open source project, lets apps take their automation behaviors with them wherever they run.
Habitat doesn't replace the existing galaxy of container-based application-deployment systems -- Docker, Kubernetes, Rocket, Mesosphere, and so on. Instead, it addresses the issues they typically don't.
This is how we do it
Habitat takes cues from how container systems already work. Application packages created with Habitat are repeatable (the same results from each build), immutable (the contents of the package do not change during runtime), and language- and runtime-agnostic (they can be deployed via containers, but also bare metal, VMs, PaaSes, and so on).
Building on that foundation, Habitat merges the app and its automation details, so the two travel together throughout the app's lifecycle. Any changes that can be made to the app become discoverable and can be changed in a one-off fashion or by editing the app's configuration.
Automation data packed with the app -- the "plan" -- is provided by a shell script and optional configuration files. A "supervisor" application that runs on the target platform hosts the app in question and does the actual management. Multiple supervisors can be ganged together into service groups, and supervisors can be packaged, along with their apps, as Docker containers.
Don't fall off the mountain
Chef created Habitat due to what it calls the "production cliff" -- the growing dificulty of deployment and management the closer you get to production, a common devops issue. Sometimes it stems from development and production environments not resembling each other, which can prove to be a major stumbling block. (Network topologies, for instance, are almost never the same between production and release.)
Habitat takes the parts of the application that are sensitive to where it's built and how it runs -- its build and runtime dependencies, details about what kind of network and infrastructure topologies it uses, any other assumptions it makes -- and provides a set of abstractions for it. In that sense, it's like Cloud Foundry's Bosh tool, which uses a similar (if stricter) approach to make rolling, zero-downtime updates to Cloud Foundry deployments.
Originally, containers left it up to deployers to handle these differences. Docker Compose, for instance, can be used to document dependencies for a given application, although it doesn't speak to much beyond that on its own. But container technology is such a protean, fast-moving space that it's hard to say it will always be so.
Until now, Chef has concentrated on how the infrastructure is set up and deployed, to great success. Facebook has given its Chef playbooks to the world; Amazon has launched a Chef-based tool for customers on AWS. With Habitat, the company is aiming for territory where containers are likely to provide stiff competition in time, but there might still be enough room to make a stand.