Ever since Docker (the company and the opens source initiative) started to gain momentum, I’ve been interested to see how the more traditional infrastructure orchestration companies would adapt. These companies – Chef, Puppet, and Ansible – all got their start around the time that virtualization gained momentum and all offered value to organizations by providing them with a “recipe book” of configuration that could help them make their usage of virtual machines more efficient.

Which was super valuable and super relevant in an enterprise that was primarily virtualized and still thinking about infrastructure with a unit size measured in servers (be they virtualized or whatever.) But what happens when the unit size decreases and, all of a sudden micro-services, containers and (heaven forbid) functions become the norm?

Well, if you’re Chef, you continue innovating and ensure that your continuous automaton platform maintains validity. in their case, Chef did this through Habitat Builder, a SaaS-based service that provides the fastest way to package apps simply and consistently for deployment and management across flexible cloud-native architectures such as those comprising Docker Swarm, Kubernetes and Cloud Foundry, both on-premises and in-cloud.

Developers packaging applications with Habitat are not required to commit to a particular export format or runtime; that decision can be made when the applications are deployed. Habitat also provides scaffolding for popular languages such as Node.js, Java, and Ruby On Rails, automatically detecting what language tooling is being used and building an artifact for the application. Deployment artifacts contain the app, as well as the libraries and dependencies it needs to run in any traditional or cloud-native architecture.

This approach helps to ameliorate some tensions between the portability benefits that containers bring, and the issues around consistency. Says Stephen Elliot, Program Vice President at IDC:

While the application portability benefits of containers are widely recognized, lack of consistency in packaging and orchestration across the application lifecycle has, in many cases, limited the success of their deployment at scale, even when using cloud-native architectures. Separating packaging, deployment concerns, and artifacts is one strategy that can empower teams to deliver on business objectives of delivering software at speed, with high quality.

Consistency across build, deploy and manage

Chef is trying to rethink what a consistent packaging and delivery process should look like for these newer, cloud-native applications, to this end, it covers of the three stages in the following ways:

  • Build. Habitat provides container packaging with a safe, simple and secure application packaging system.
    • Developers can define their dependencies and configuration needs and create deployable artifacts.
    • Developers can connect their source code repos to Habitat to enable automated builds, and trigger builds based on dependency changes.
  • Deploy. Habitat can deploy applications to any format and runtime in traditional and cloud-native architectures.
    • Habitat Builder packages can be exported to any deployable artifact such as Docker, rkt, Mesos or Tar, and exported for platforms such as Kubernetes and Cloud Foundry.
    • Habitat Builder can be connected to Docker Hub to automatically publish apps to that registry. More registries will be integrated into the service over time.
  • Manage. Habitat delivers automation for applications by integrating a supervisor with the deployment artifact.
    • The Habitat supervisor understands what is needed to successfully run the application and automates critical functions such as configuration, enabling clustering topologies and managing the lifecycle of the services that are declared as part of the build.
    • Using Habitat Builder, everything the application needs, from build dependencies, runtime dependencies, configuration, dynamic topologies, deployment strategies, secrets management and security auditing stays with the application.

Alongside the native functionality, Chef has been thinking about development tool ecosystems and integrations. To this end, Habitat Builder provides native integration with Github for source code and with Docker Hub for container format export with more integrations to follow. It also includes a native operator for Kubernetes that enables export of Habitat packages into a cluster, along with a container exporter for Cloud Foundry that injects Cloud Foundry defaults into Habitat-run services.

Speaking of the real-world hybrid requirements of organizations, Marc Holmes, VP of marketing for Chef points to the real value proposition here:

While some existing tools are great for getting started with containers, modern app teams need to be able to package and deploy apps across multiple traditional, and cloud native architectures. We developed Habitat Builder to enable developers to package apps in a consistent way, and enable operations to choose appropriate deployment targets, bringing the team closer together through a clear separation of concerns.


The jury is out on the validity of a tool like Chef, that was borne of a different age, for more modern infrastructure approaches. That said, the reality is that most organizations are using a range of approaches and for these organizations, Chef’s broader offering will be attractive.

Ben Kepes

Ben Kepes is a technology evangelist, an investor, a commentator and a business adviser. Ben covers the convergence of technology, mobile, ubiquity and agility, all enabled by the Cloud. His areas of interest extend to enterprise software, software integration, financial/accounting software, platforms and infrastructure as well as articulating technology simply for everyday users.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.