Chef Extends Automation Reach to Containers

IT operations teams are about to be confronted with an unprecedented number of microservices based on containers moving into production environments. As such, more reliance on IT automation frameworks is all but inevitable. At the ChefConf2017 conference this week, Chef announced that its Habitat IT automation framework for applications will be extended to include support for microservices based on containers.

Chef CEO Barry Crist told conference attendees that Habitat, which is part of the Chef Automate continuous integration platform, will be extended to enable Chef to become the dominant platform for automating container and microservices deployment. Crist promised attendees that Habitat will be the fastest tool for packaging applications. To prove that point, Chef demonstrated how a container application running on Amazon Web Services (AWS)’ Elastic Cloud Computing (EC2) service can be moved to the Google Cloud Platform using a single command.

To enable those types of migrations, Chef has extended Habitat to include support for scaffolding via additional helper functions aimed at applications written in Ruby on Rails and Node.js. Those helper functions allow applications to be exported to any target runtime, including Docker and the Application Container Image (ACI) for use in container platforms such as Kubernetes, OpenShift and Mesosphere DC/OS. Chef also committed to developing helpers for additional programming languages such as Go, Python and Java Virtual Machines (JVM). Habitat essentially captures the meta data that describes the dependencies and attributes of the application, then presents format options for automatically deploying that code.

In addition, Chef noted, packages accepted and curated as “Core” will be automatically rebuilt as their dependencies are updated and there are now 20 core build plans to enable developers and teams to more quickly package applications for common enterprise scenarios. Those build plans span big data (Cassandra, Spark, Storm, Kafka, Zookeeper, CrateDB), monitoring (Prometheus, Grafana), middleware (WebSphere, Mulesoft, Varnish, RabbitMQ, Consul), databases (PostgreSQL, MySQL, Redis, Shield backup) and developer and content tools (Jenkins, Drupal, WordPress).

When it comes to containers and microservices, it’s apparent Chef is making a case for extending existing IT automation frameworks that can be applied to both legacy and cloud-native applications. The goal, says Crist, is to make it much simpler for IT organizations to adapt to change. Rather than having to implement separate tooling for each application environment, a continuous integration platform should take all the drama out of supporting multiple computing models simultaneously. In fact, Crist contends that without some form of automation, most organizations will never achieve the real benefits of making the transition to deploying containers at scale. After all, the ultimate goal is to be able to deploy more applications per IT staff.

Of course, the big challenge IT operations teams—and, by extension, Chef itself—face today is that developers are often implementing their own tooling. Over time, that not only increases technical debt by creating redundant processes, it also makes managing DevOps a lot more messy than it needs to be.

Mike Vizard

Mike Vizard is a seasoned IT journalist with over 25 years of experience. He also contributed to IT Business Edge, Channel Insider, Baseline and a variety of other IT titles. Previously, Vizard was the editorial director for Ziff-Davis Enterprise as well as Editor-in-Chief for CRN and InfoWorld.

Mike Vizard has 1600 posts and counting. See all posts by Mike Vizard