Habitat — a new open source project for automating applications

Today we launched our new open source project, Habitat, for application automation. We hope you’ll try Habitat and join us in taking automation to the next level. What follows is a blog from Adam Jacob detailing the philosophy behind Habitat and what this new technology delivers – automation that travels with the application.

You can watch Adam unveil and demonstrate Habitat here.

Why Habitat?

Habitat exists to solve the problem of how we build, deploy, and manage applications. As Marc Andreessen declared in 2011, “software is eating the world”. In every sector, in every industry, from small startups to the largest of enterprises, we see software at the center of how we build and run our companies, and how we interact with our customers. This shift forces us all to become fast, efficient, software-driven organizations—or lose out to a competitor who is.

This challenge is not simply technical. It is also organizational and it is cultural. We have to change the way we work together, hand-in-hand with changing the systems that enable us all. We need to build solutions that help create the culture that enables us.

What have we done so far?

As an industry, we have designed our solutions to this problem either from the perspective of the Enterprise, or the perspective of the Big Web (Facebook, Google, Netflix, Twitter, etc.).

When we start from the Enterprise, we tend to build solutions that are too narrowly focused. Our software becomes an example of Conway’s Law in action. The deep silo-ing of responsibility present in most enterpries drives us to design software specifically for one silo or another: we build security software, or we build application deployment software, or we build configuration management software. If we endeavour to escape this trap by designing solutions that cut across the silos, we fall prey to another issue: we’re forced to integrate into every silo’s existing software toolchain. The result tends to be systems that are deeply complex, and very difficult to understand and operate—or worse, that are only as good as their worst point of integration. It is difficult to escape the complexity of the matrix between different eras of technology and deep silo-ing.

When we look to the Big Web for inspiration, things look better. While each company is different, they all share in the ability to deliver software efficiently, safely, at speed. They accomplish this feat by establishing a simpler, more standardized infrastructure layer than their enterprise compatriots. On top of this, they build a runtime that supports the applications they build, making it easy for their software development teams to write new software, and streamlining their operations. It feels intuitively right that we should look here, at least directionally, for the solution to our problem.

Yet two facts quickly arise that make this direction difficult as a general-purpose solution. First, these companies all share one fundamental truth: they controlled the destiny of their applications from day one. Unlike the Enterprise, the Big Web wrote their software from scratch. This reality leads naturally to the second truth: the platform they built is the business. If we follow this path, we will have to re-write most of the software in the world to target a specific runtime platform—one which, as of today, doesn’t exist, and has no analog in the big web, because each platform is different.

Taking the application’s perspective

Habitat started by asking this question: if our goal is to quickly and safely build, deploy, and manage applications, what would happen if we took the application’s perspective on the problem? Rather than starting from the Enterprise point-of-view, or from the platform-centric view of the Big Web, what if we simply focused in on what it means to be easy to build, easy to manage, and easy to deploy?

We call the answer we found Application Automation. Our great discovery was simply that the automation must travel with the application, rather than be provided by the platform. Everything the application needs, from build dependencies, run-time dependencies, configuration, dynamic topologies, deployment strategies, secrets management, security auditing, and so on belongs with the application, because we’re doing it for the application. Runtime and infrastructure layers exist to support the application, but the efficient building, deployment, and management of the application are decoupled from those layers.

Existing and cloud-native software: one management layer

The result is that we can take an application, wrap it in a layer of application automation, and the resulting package can be deployed on the infrastructure or runtime that suits it best. If your application has hard requirements on physical infrastructure (SAN settings, network topologies, GPUs, etc.), you can deploy it there, and manage it the same way you manage the software that deploys on top of a PaaS, or in a container.

Packaging and supervision

Habitat accomplishes this by providing two main components: a robust, safe, simple, and secure software packaging system; and a supervisor which manages the lifecycle of the services declared in these packages. The packaging layer creates immutable, atomic packages, which contain both the software and all of its configuration options.

The supervisor component is where the run-time magic happens. Each supervisor can be joined with many others in a “ring”, with the service it manages formed together into service groups. These supervisors can then handle ensuring the application has the correct configuration, has the right secrets, is in the correct topology, coordinates dynamic software upgrades, and more.

Avoiding the production cliff

This architecture allows us to avoid the production cliff problem: the closer you get to production, the more difficult it is. Rather than force the deployment of more and more infrastructure and management software as you approach production, operations teams can simply pass more options to the supervisor: declaring the correct topology, update strategy, and configuration. Deploying the application is deploying the automation—all of it.

Try Habitat!

We’re proud of Habitat. We think it makes the software you already have better. We also think it makes the runtime and infrastructure platforms you’re moving to better. Habitat is technology that simplifies the complexity of how we build, deploy, and manage our applications; empowers the teams that need to collaborate in order to deliver the future; and accelerates the speed with which we can get a better experience out to our users.

Don’t take our word for it. Try Habitat yourself, right in your browser Or head over to the tutorials and documentation. Habitat is open source, so if you would rather dive straight in, grab the source from GitHub.

Adam Jacob

Adam Jacob is the CTO and co-founder of Chef.