In Container World, Chef Faces Shifting Landscape for Configuration Management
With $40 million in new investment, Chef, the commercial entity behind the open-source configuration management and automation platform, would seem to be poised to take the DevOps world by storm.
“This is an inflection point for Chef as a company. Our innovation is becoming the primary bridge between traditional IT and new IT in the enterprise,” CEO Barry Crist said in the announcement. “Today we enter a new era as the automation control plane for digital-first organizations everywhere, and this new capital will help us take DevOps mainstream.”
Chef CEO Barry Crist told ZDNet that containers and compliance will be two areas of focus for the investment, though it’s keeping its plans pretty close to the vest. The company told The New Stack through a spokeswoman that it’s not ready to talk about its container plans yet.
It would seem that other emerging companies are a step ahead in containerland. SaltStack’s role in Kubernetes reflects a break from existing configuration management environments in the quest for an immutable infrastructure, The New Stack’s Alex Williams wrote previously.
Paul Czarkowski, cloud engineer at Blue Box Group, doesn’t see containers as a threat, per se, to Chef. Chef can be used to both orchestrate the running of containers as well as to configure software inside of the containers, and can be used successfully to build, deploy and run Docker containers in a coordinated fashion, he says.
“Most people I know that are running Docker successfully in production today are using this approach. This is especially important as very few places can run all of their applications — nor should they feel the need to — inside of Docker containers,” he said.
“By using Chef, they get to manage both their Dockerized and traditional workloads with the same tooling, which allows you to introduce Docker without disrupting all of your existing tooling.
“That being said,” he added, “the larger container ecosystem is starting to provide ways to do [most] things that Chef would currently do. Container runtime orchestration systems like Mesos and Kubernetes as well as platforms like Deis and CloudFoundry are a threat to Chef for the more advanced cloud-native apps that will run happily inside a container. Still, something needs to install and manage these systems/platforms.” He predicts that an organization that currently uses Chef would likely continue to do so.
Strong Growth
In April, Chef announced it had the strongest quarter of growth in the company’s history. It also unveiled its DevOps workflow service Chef Delivery, which aims to speed delivery of infrastructure, runtime environments and applications, including containers. It was initially an invitation-only initiative, and the company said it plans to open that service slowly. At the same time, it announced the DevOps platform’s integration with Canonical’s Ubuntu enterprise distributions.
It unveiled a partnership with Microsoft to develop an integration with Azure and plans integrations at the networking layer with Cisco and F5 Networks, as well as analytics integrations with Splunk and Sumo Logic. Last year, HP adopted the Chef configuration management tool into its “orchestrated datacenter” offering.
However, Chef faces competition on a number of fronts — from Puppet, Ansible, Salt and others. SaltStack is also being used by Microsoft Azure as the core orchestration management engine within Kubernetes, and CoreOS has its own method of configuring Kubernetes called Cloud-Config.
Meanwhile, earlier this year, rival Puppet Labs rolled out the latest version of its enterprise platform, Puppet Enterprise 3.8, which included managing Docker and Docker containers. It, too, announced its strongest quarter ever in the first quarter.
The initial Puppet Docker module was released around the same time as Docker, the company points out, and the community effort has logged more than 200 pull requests and close to 100,000 downloads from the Puppet Forge alone.
Puppet, too, will be working with Cisco on its NX-OS Platform to speed the deployment of software-defined networking infrastructure.
Different Direction?
A year ago, though, The New Stack’s Chris Dawson noted a seeming trend among Docker developers toward Ansible and away from Chef and Puppet.
In that article, Colin Campbell from Chef made a distinction between Chef and Ansible in the two responsibilities these tools handle: creation of a container and configuration of a container. He said that Ansible does the first well, but not the second, while Chef excels in configuration. The Chef server runs inside the container, and pulls configuration into it. Ansible uses SSH to orchestrate images, and SSH daemons don’t typically run on containers.
Dawson also noted a clear preference among Docker developers for the Python language, while Chef and Puppet are written in Ruby. (The most recent RedMonk Programming Language Rankings put Python at No. 4; Ruby in a three-way tie for No. 5; and Go, Docker’s language, moving up quickly at No. 15.
Dawson points out that one of Docker’s main promises is to help migrate complex ops tasks into doable tasks for developers.
“Today Chef is really still a bespoke tool in the pocket of IT and it’s hard to get developers to care. This is where Docker is actually a threat,” says analyst Chris Riley.
For Chef to participate heavily in DevOps, it needs to elevate beyond orchestration to really become part of the overall pipeline, which it is doing with its focus on Chef Delivery, he says.
“Really, the technical challenges Chef faces around Docker seem small, and not overly complex. Rather, they need better responses on when to use Docker and Chef together and how, which also likely means better management tools — a place where Docker is very weak,” Riley said.
He said he would expect to see more and better integrations with the cloud providers. Cloud infrastructure provider ProfitBricks just announced such an integration for Ansible and Chef.
“I think the bottom line is Chef could fall into the trap of a heavily used, but not evolving, IT tool, so a transition from that thing we use to build servers to a critical piece in the delivery chain with better integrations and more holistic management tools is necessary,” Riley said.
Czarkowski expects to see more tooling from Chef, likely in the form of community cookbooks to build and run the various systems like Mesos and Kubernetes, as well as resources to interact with those systems.
He said the workflow might look something like this:
Operations / DevOps: Use Chef to build and maintain OpenStack.
Operations / DevOps: Use Chef to deploy and maintain Mesos on top of OpenStack.
Operations / DevOps: Use Chef to deploy and maintain monitoring, logging, and stateful services — like databases — which can be consumed by applications.
Operations / DevOps: Use Chef to deploy and maintain CI/CD infrastructure (Jenkins, Docker Registry, etc.).
Developer: Use Docker Compose to develop application.
Developer: Push code (including dockerfile) to Git.
Developer (or Git hook): Call Jenkins to test code and build Docker image and push to Docker Registry.
Release Engineer: Tell Jenkins to deploy new code. Jenkins uses Mesos tooling or Chef to deploy code.
Cisco, CoreOS, Docker, HP and ProfitBricks are sponsors of The New Stack.
Feature image: “Woven” by Patrick Emerson is licensed under CC BY-ND 2.0.
