There is a wide variety of DevOps tools a business can use. Puppet, Ansible, Chef, Salt, Kubernetes, Docker, Marathon, Packer, Maven, Selenium, Prometheus, Icinga, AWS and Google Cloud services, etcetera, etcetera. Why would you use Chef DevOps, for example? IT SVIT, a managed DevOps services provider with 5+ years of expertise, explains this.
Chef is one of the first configuration management tools. It was released back in 2009 with a goal to provide a uniform approach to managing a tangled nest of tools and configurations many companies used to run their services back then. Written in Ruby and then rewritten in Erlang, this tool was widely adopted initially and is still used by Facebook and multiple other companies large and small.
Chef operates recipes and cookbooks. The “recipe” is a script describing how to configure and manage the infrastructure components for a certain type of operation. The “cookbook” is a collection of recipes, making it easier to manage them at scale. Chef recipes are step-by-step guides on building the required system environments and configuring them to a needed state. A properly written recipe ensures everything is installed in the correct order and all the dependencies are configured correctly.
Does this sound good? Naturally! Is it actually good? Not so much. But why?
This step-by-step approach results in a severe performance bottleneck, as Chef recipes take some time to operate and deliver the expected result. While with simpler deployments this time is measured in seconds or minutes, with complex systems at large scale it might take hours on end. Unfortunately, Chef DevOps architecture cannot be changed, nor does it need to. Chef has become a tool for several huge customers like Facebook, who have invested too much into adopting it and don’t want to move to more modern products yet.
Are there more modern products? Yes, of course, like Ansible and Jenkins and Saltstack and Heroku and many others. Why are they better? Because they are faster. Unlike Chef that waits for confirmation of successful completion of each step before commencing the next operation, Ansible just forces the system to install the needed software and update it to the needed version, regardless of the current state of the system — and does not wait for confirmation. This saves a ton of time (and money) and makes the process of preparing Ansible playbooks much easier as compared to working with Chef recipes.
More modern tools like Terraform use and even more time-efficient approach. Their manifests are written in simple descriptive language, describing the required state of the environment without any emphasis on the process of getting there. Terraform handles it automatically and does it blazingly-fast, making creation, adjustment and deletion of virtual words a matter of seconds.
Is Chef outdated? Probably. Would we recommend using it for new projects? Definitely not. Is it worth to continue using it for your existing projects? Definitely yes. It is a good tool with reliable and predictable behavior able to deliver the expected results on time. As long as it does what you expect it to do and does not cause major issues — you can follow the lead of Facebook and continue using it.
However, if you are thinking of starting a new project — there are multiple worthy alternatives to the Chef DevOps tool. Selecting the best of them might seem tricky, so working with an IT outsourcing company that possesses an in-depth DevOps expertise can be quite beneficial. This will ensure your project is built using the most appropriate and cost-efficient tools to minimize the time-to-value and your operational expenses.
