My first real exposure to build and deploy automation was with Imago Publishing in 2007, where I used Thoughtworks’ CruiseControl for both builds and deployments of webservices, web applications, and databases. 13 years later, there is a lot more choice when deciding on tooling, and the best results are found where there’s an appreciation of what it means to unify the efforts of Development and Operations teams. Although the technical problems being overcome have not changed a great deal, it has become clear how the best solutions reach beyond Developers alone.
Classical architectural approaches tend to define specific, rigid designs which are intended remain mostly unchanged. This approach requires specific configuration of unique pieces of infrastructure and software which comes with a unique ‘run book’ explaining how to manage it. This rigidity soon impacts the business when it becomes clear that making changes is expensive and time consuming.
Modern architecture must take into consideration the dynamic nature of today’s software. What is being designed isn’t a static, finished product, it’s what is needed right now. Configuration management techniques mean that the output of software design and development isn’t just the software, it’s also the means to deploy, modify, test, and reconfigure the software – often without down time.
Modern DevOps involves embedding software development practices into Operations teams, allowing infrastructure to be considered a dynamic resource, while embedding standardised and automated approaches to building, testing, deploying, and monitoring software into Development teams. This means deployed applications can be managed without having to understand what they do, and changes in platform (such as patching) can be applied simultaneously everywhere, safely, and without down time. Introducing DevOps is not something which can be accomplished successfully in a ‘big bang’ approach. A slice of Operations staff, Developers, QA, and the business should be chosen to make the transition first, and they should be given permission to get things wrong and reconsider their approaches. With experienced help major pitfalls can be avoided, but good DevOps looks different everywhere and is an always improving function – there is no ‘perfect’, and no-one gets it right first time. Their progress can then be adopted and expanded on as other teams see the benefit.
In my experience, the thing which holds many enterprises back from realising the full value of DevOps is the misconception that it only involves an amount of automation, driven mostly by developers. Development teams get part of the way there, by building automations for complex tasks such as build, test, and deploy, but without the involvement and commitment from the Operations side, these are simply window dressing on fragmented working practices.
I place DevOps into the same bag as Agile and Micro Architecture; you don’t have to know everything about them to see some benefits, or even implement a working solution, but you will almost always fall foul of problems and inefficiencies that are only seen with experience.
If your business is attempting to embrace DevOps practices, I strongly suggest finding someone with wide and varied experience in the subject if you want to get the best return on your investment.