Habitat and Twelve-Factor Applications

Twelve-Factor Applications are not something revolutionary or new. The concepts were originally published over 5 years ago, however they are are still relevant today as they were then. With the growth of Cloud Computing and the introspection that has taken place in the industry about how you run distributed services at scale, it’s useful to revisit these ideas. If you’re not familiar with twelve-factor applications you can read more on the website dedicated to these ideas, 12factor.net.

The basic principle behind twelve-factor applications is how do you run “software as a service”, with a focus on declarative automation, workload portability, continuous deployment, and scalability. With the rise of technologies that make these goals easier (such as containers), and the rise of modern architectures that focus on independent services (microservices and Cloud Native applications), twelve-factor applications have never been more relevant.

Habitat, Chef’s open source project focused on application automation, helps you achieve many of the goals of twelve-factor applications. Let’s look at a few of the twelve-factors that Habitat can help solve in your twelve-factor application strategy.

Factor II. Dependencies – Explicitly declare and isolate dependencies

Dependency management is one of the long standing challenges in the world of application deployment. Every language has their own tooling to solve this problem differently, and then you have libraries that are traditionally thought of as the domain of the operating system. Habitat breaks the barrier between “application dependencies” and “operating system dependencies” treating them the same. As these underlying dependencies are updated, Habitat can then notify you of applications that rely on these dependencies, then help you rebuild, and redeploy your application.

Factor IV. Backing services – Treat backing services as attached resources

Modern applications focus on detaching required application services from the services responsible for code execution. With this decoupling, there arises a need for knowing what services a given application requires to run. Habitat allows you to define what services an application artifact requires to run, and the application won’t start unless those services are provided. This knowledge of these service dependencies is stored in the Habitat application artifact, allowing you to easily query what services an application needs directly against the application itself.

Factor V. Build, release, run – Strictly separate build and run stages

Along with Habitat’s capability to explicitly declare and isolate dependencies, you can also explicitly declare what dependencies are build time dependencies, and what are the dependencies required at runtime. This allows you to package your software knowing that your build tool chain won’t leak into the application deployment, and helps you reduce what’s deployed onto your production systems. Additionally, Habitat provides the Habitat supervisor, which allows you to define how an application should be ran, and allows you to package up the run time requirements in your application package. 

Factor VII. Port binding – Export services via port binding

In addition to being able to explicitly declare what services an application requires to start, Habitat packaged applications can also export the services, configuration, and ports the application offers to other applications. This allows you to easily bind services to one another, and once again this knowledge of exposed services is baked into your Habitat application artifact.

Hopefully this helps you understand how Habitat enables you to run your applications and application services in a twelve-factor way. If you want to learn more about Habitat, and how it can help build and run the Developer Services required for modern application architectures, check out this recorded webinar on Building Effective Developer Services with Habitat.

Michael Ducy

Former Chef Employee