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!).
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’.
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.
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:
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!
