Choice is great, as long as you make a great choice.
In the configuration management tools space we are spoilt for choice. This wasn’t so a couple of years back. I would never want to go back to those hand-cranking days where deployment and release management tasks were simply a nightmare.
But with choices, an added responsibiity falls upon our shoulders to actually make a choice and stick with it.
Of recent I have been noticing a trend in various projects. I joined a startup team last year and was grokking through the infrastructure codebase and noticed that we had some “manifests of puppet and chef recipes”. When I asked why this was so, I got a response along the lines of puppet rocks at doing “x” stuff and chef was awesome at doing “y” stuff.
In another company I found a mix of puppet and ansible code in the infrastructure repo. Again I asked, and got a response along the lines of ansible was good at doing “x” stuff while puppet aced “y” stuff.
A few days ago I came across a company that was using chef, puppet and salt! At that point I decided this has just got to stop and here is the rant:)
One of the reasons we roll-out infrastructure as code today is because it allows us to have a single source of truth that prescribes how a company’s infrastructure is provisioned and our applications are deployed. Oxford English Dictionary defines prescribe as “STATE AUTHORITATIVELY or as a rule that (an action or procedure) should be carried out.”
Having bits and pieces of infrastructure coded using various configuration management tools eventually leads to attrition, where the infrastructure code is reduced from its’ authoritative stance to a bunch of opinions.
The configuration management space is a broad category with various tools providing complementary features and you sometimes need to daisy-chain a few together to achieve the required results. However, there is a lot of overlap and the tools should be selected carefully ensuring functionality duplication is reduced to the bare minimum. Having a git repo that includes scripts for deploying nginx with puppet and chef for the same infrastructure is not what you want to do.
A few things to note when selecting configuration management tools:
Consider the features you need: You might need a tool that does provisioning, orchestration and scales well on public/private cloud infrastructure. The more features you can effectively nail down with one tool the better.
Consider ease of use and learning curve: Hi-five to you if everyone defaults to using the selected tool because it is easy or easy to learn. Selecting a tool along the path of least resistance bolsters productivity.
Consider the culture of the company: Each tool embraces a slightly different philosophy and paradigm. Select a tool that is in sync with the culture you are trying to elicit.
Consider the skills available in the company: Selecting a tool built around a language that developers and operations folk are comfortable with promotes convergence of ideas and practices amongst the two camps.
Consider the hiring challenge: Engineers come and go. Being able to easily source talent skilled in the tool selected should not be over-looked.
Consider the level of support required and available for your selected tool: The best tools are transparent and get out of the engineers way. The less time spent figuring out a.k.a googling for solutions the better.
Consider your companys’ future and the selected tools’ roadmap: The communities around some tools are very active and are possibly evolving in a way that is in alignment with your projected infrastructure trajectory.
I love hacking on new tools and my favourite toy changes all the time. However when it comes to business infrastructure, lets play fair – one game at a time! ^_^
If you like this post, sign-up for my upcoming book “DevOps 101, An Introduction to DevOps Culture and Practice”