Media Temple has been a leading web hosting provider for nearly 20 years. As a Software Developer there, George Marshall is responsible for focusing on products that help their customers realize their goals in taking their ideas online. We recently interviewed George about how his team is using Chef and Habitat. You can watch a recording of the interview below. George told us how crucial automation has become in day to day application deployments, and in particular he shared his excitement about working with Habitat.
Big Ideas, Small Shippable
“…since you’re only pulling in what you need, you’re able to have a very, very small deliverable to your end production.”
A theme George kept coming back to is the value of having very small shippable components. In traditional environments, on bare metal servers or VMs, typically we’ll start with an operating system image with its own pre-installed software and libraries, as well as organization-wide software baselines, onto which additional dependencies will need to be installed before we’re finally able to deploy our application.
As systems have grown more complex over time, even so-called “minimal” installs can have a lot of moving parts. What’s worse, it can be difficult to discern which elements are tied to the function of the underlying operating system, which are tied to components of our application, and which aren’t in use by anything at all! This can cause a variety of challenges, from making it difficult to predict the impact of software upgrades, to inconsistencies between environments causing much-dreaded “but it worked on my machine!” issues. In any case, these concerns are apt to slow our development pace to a crawl.
With habitat, rather than starting with an operating system and building up to an application environment, we start with an application, and pull in any required dependencies to build an artifact that contains everything it needs to run, and nothing it doesn’t. Whether we run those artifacts on VMs, bare metal machines, or export them to containers, they’ll run consistently regardless of what is or isn’t installed on the host OS. Per George, this in turn can, “…make new platforms a bit less challenging by being a little bit more agnostic… and you have a little bit more flexibility in how you want to take your deployments”
Builder: Dependencies Done Right
“What you’re shipping is gonna be a better product.”
As we talked, George was particularly enthusiastic about Habitat’s Builder feature, and in particular its dependent build functionality. As mentioned previously, evaluating the impact of package upgrades has historically been a significant source of pain, as each upgrade might have multiple services that depend on it, and if applied inconsistently, conflicts can be difficult to diagnose and repair. Habitat plans allow you to define dependencies on other projects and configure automatic rebuilds whenever any upstream components are updated. In George’s view, “The big benefit of that is the integration testing you can get out of that. And being able to make sure every component in the stack is going to work with each other and be copacetic.”
In other words, since Habitat builds its artifacts with everything they need to run, these automatic builds will produce ready-to-test versions of our application without us needing to take any manual steps to parse the dependency tree or stage an upgrade.
Learn More
- Get started with a hands on demo of Habitat Builder
- Earn the “Ready to Serve” badge on Learn Chef Rally for Building Applications with Habitat
- Earn the “Packaged to Go” badge on Learn Chef Rally for Deploying Applications with Habitat
- Watch an on-demand version of a recently recorded webinar: “Cloud Native Applications with Habitat Builder“