DevOps: How not to Fail?
According to Gartner, by 2016 25% of Global 2000 companies will use DevOps. But just because everyone is using it, should you jump in the race too? But if you choose to, then there are certain things that you must be aware to get the maximum out of it. More than what you should do, this article is about what you shouldn’t. In my next article I will mention the factors pertaining to the success of DevOps.
It’s not just about Automation
Automation is a key part of DevOps, but there’s lot more. DevOps enables better communication and reduced gaps between development and operations which is beyond the scope of automation. It is more of an end-to-end solution which involves Code, Build, Test, Package, Release, Configure and Monitor making the software distribution faster and efficient. If your objective is only to automate the software cycle then DevOps is not the right solution for you.
Don’t be Rigid
Each organisation has its own unique culture, technology and processes which must be taken into account while implementing DevOps. It’s advisable to consider DevOps as guidelines rather than a process. Doing everything by the book is not a very effective strategy to implement DevOps. Your previous experience in implementing DevOps will be helpful but being adamant doing it the same way with a different function/organisation may not be fruitful.
If you think that you will create the perfect software distribution which will have zero bugs, no downtime, dramatic cost reduction and everyone will be exultant, then DevOps is not what you want. DevOps is a culture and is implemented by different tool chains. The effectiveness of the system depends on the tools used. And then there is always human error. You may have the most talented and competent team, but then there is always that “period” that one may miss.
Impatience is not a Virtue
An exercise without any immediate fruitful outcome is not much appreciated. But any significant change takes time to produce results. Blaming individuals for not being productive and firing them will not only affect the morale of the team but also hinder the adaption of DevOps. One must give sufficient time before declaring that DevOps is not for them.
About the Author
Global head pre sales and solution architecture at Newt Global Consulting