IT teams are always on the lookout for configuration management tools that can effectively manage a large numbers of servers hosted both inside and outside the organization across physical data centers as well as virtualized work spaces. These tools are highly valued (nay, indispensable!) because they excel at stuff like repetitive task automation, simultaneous deployment of apps and packages across groups of servers, and configuration and provisioning of new servers from scratch.

The server configuration market is primarily dominated by platforms like Chef, Puppet, Ansible, and Salt. While each has its own distinct advantages based on parameters like performance, scalability, availability and interoperability, based on eInfochips’ experience with some of our recent clients, Enterprise Chef is emerging as a clear favorite with system administrators. Of course, such an opinion is highly open to debate and such a comparison would be subjective to begin with but it cannot be denied that there are more than a few “user-friendly” attributes of Chef that are making it a unanimous choice for system administrators of a certain disposition: those who value versatility, speed and Ruby-on-Rails design (I listed that one last but it might as well be the most important reason!).

So what does Chef basically do?

The biggest reason for the popularity of Chef as a server configuration management automation tool is that it lets developers express the design of the company infrastructure using less code, greater flexibility, agility, and version-control. Chef servers form a central component that store information about company servers and can execute dynamic actions to automate infrastructure in public/private cloud or on-premise datacentre. The basic concepts around which Chef is built are rather simple: achieving desired state, centralized modelling of IT infrastructure, and resource primitives that serve as building blocks. These concepts enable quick management of any complex server infrastructure.

Chef utilizes a master-agent model, and in addition to a master server, a Chef installation also requires a workstation to control the master. The agents can be installed from the workstation using the ‘knife’ tool that uses SSH for deployment, easing the installation burden. Chef Configs are packaged into JSON files called ‘recipes’. Chef can run in either a client-server or in a standalone mode called ‘Chef-solo’.

Chef in Action: A Case Study

One of the previous clients I worked for is a major healthcare Insurance company which managed to double its revenues from $3 billion a year to $6 billion within 3 years of short period and still growing. As management was very happy with growing business, IT department was facing two main challenges.

• Upgrading infrastructure to support ever growing business needs:  To align with growing business needs, the client decided to migrate its core enterprise applications from proprietary platform of older Sun Solaris x86 servers to Red Hat Linux RHEL 6.x enterprise-focus open source servers optimized for the modern data center environment. The idea was to deliver an enhanced level of scale-up performance, availability, reliability and comprehensive security. There were 30+ applications consisting of web/app servers, databases, ERP and portals components deployed on 700+ virtual machines to be migrated, set up and tested on new infrastructure.
• Automation and continuous delivery – DevOps:  As Infrastructure grew from a few to hundreds of servers, manual update and maintenance became an intractable problem. Repeatable needs for creating hundreds of virtual machine with different configuration during load testing in short amount of time was becoming challenging due to the need of manually configuring each server. The development need for testing all applications in continuous deployment and continuous delivery pipeline was the biggest challenge to overcome as valuable time was lost while operation team would take like one or two weeks just to set up an environment for an application in test or stage.

After carefully evaluating different Configuration Management Tools (Chef, Puppet, Ansible, and Salt), management and technical team decided to deploy chef as their choice of infrastructure management tool. There wer several reasons behind using Chef as a deciding factor chief among which were the follows:

• Open source and Large community Support including Facebook, Google
• Client Server Architecture
• API for an Infrastructure ( Infrastructure as a code )
• Continuous Delivery  ( Build, Test and Deploy )
• Programmer friendly – Chef uses Ruby as DSL
• Dependency management

The intervention of Chef helped to reduce the test and development team’s systems management time, allowing system admins to concentrate on their core activities with the entire infrastructure running smoothly during the transitions.

How long did it take to bring up a new application server from scratch? It took less than 10 minutes!

Yes!!! That’s over 4000 times faster than the previous process of manual setup! We were able to quickly and easily automate hundreds of servers in cloud infrastructure in a matter of some hours, rather than the entire year!

Benefits of Chef Approach

• By reducing infrastructure setup time from weeks to some hours, we managed to save on ample time and money.
• The whole stack was reproducible while the application deployment rate increased from 10 to 60 per week with faster infrastructure and code delivery.
• The solution also helped in reducing human error with perfect infrastructure automation.
• It also helped us delivered increased agility and reliability to manage platform configuration.