DevOps and Automation

A  Common theme running across many organizations trying to implement DevOps is that Automation is the key to implementing DevOps. So if Automation is the key, then the next logical step is to decide which areas you want to Automate, deciding on the tool and training your staff (or hiring from the market). The example Org’s give is that if Google, Facebook, Netflix can do multiple deployments every day and they have automated everything (from Continuous Integration to Continuous Deployment) so it is just a matter of Automating everything and we are all set. It may be an eye opener if organizations compare their HR Manual with Netflix HR Manual. Now what has a HR manual has got to do with DevOps.  The HR manual highlights the “Control” Vs “Flow” philosophy. Each of these philosophies in turn leads to certain organizational behaviors which in turn lead to what is called “High Trust” or “Low Trust” organizations. It is much easier to implement the DevOps principles (DevOps Third Principle: Culture of Trust and Experimentation) in a High Trust Organization as compared to a Low trust organization. That is not to say a low trust organization cannot implement DevOps just that the approach has to be different.

Note: There are many factors which decide if a Organization is a High Trust or a Low Trust Organization, HR Manual is just one of them.

Now your Organization has decided that they need to Automate their Infrastructure provisioning piece and decide they need to use one of the below tools (a quick search on the Internet will list many more tools than the one’s given below).

• Puppet, Chef, Ansible, SaltStack.

You decide as a first project that you need to automate the Configuration of the ngnix (Web Server) which is being used by five different projects in five different nodes. You gather the setting requirements for each of the projects and write the automated scripts to do the job. You run the scripts and the result is 1 pass and 4 fail. You start to analyze why the 4 failed and the reasons are

• Network Port blocked.
• Missing OS Libraries.
• Missing permissions.

For the 1 pass you decide to run the script against the QA environment to change the setting but the result is a fail (on further analysis you find that the OS is different on the QA environment and that you need to re-write your code).

What I am trying to highlight here is the fact that you need to have a complete understanding of the underlying software stack, the dependencies among other things i.e. you need to go through a requirements phase before you even begin to start to write a single line of code. Also you need to have automated methods to check if you have the required infrastructure configurations in place. Manually doing this will beat the purpose of automating it in the first place.

In Short it means

• Only Automate what you understand completely.
• Have Automated Validations in place.

Remember Automation means a lot of heavy lifting not just selecting the Automation Tool, Trainings etc. A whole eco-system needs to be in place for automation to be successful.