by feidhlim o’neill
DevOps is all about breaking down the barriers between development and operational teams and thereby unlocking a wide range of benefits in how we design, build, deploy and support software. DevOps has been the key driver behind the adoption of a whole raft of technologies, architectures, processes and skills and one of the best of these is continuous delivery — delivering business value in a continuous stream without creating chaos as you do so. There are a number of aspects to continuous delivery but a key point, certainly from an Ops perspective, is that new features or functionality get deployed into production as part of a continuous process and isn’t just “thrown over the wall” to be installed (and supported) by a separate team.
Complementary to continuous deployment has been the rise of the microservices architecture. Microservices are, as the name suggests, breaking down your business logic into 10s if not 100s of small independent services and ideally suited to the low risk changes that continuous deployment promises. To see why lets look back when code was deployed in large single application with separate operations teams.
In the past, besides handing the code off to a separate Ops team, we had to go through a change process to assess the risks associated with the change as well as things like compliance. Production had to be protected from developers who considered their job done once the change ticket was created. In larger companies there was a function specifically created to oversee this process. It was a slow process and because getting approval for a deployments was onerous it was natural to get as much into each release as possible. Therefore, ironically, the change process designed to manage risk was in some cases actually increasing it. Not good.
So along came DevOPS. Continuous delivery is about deploying small changes continually so the risk on each change is lower. This certainly helped lower the risk of each deployment but when dealing with monolithic systems the business impact, of a bad change, could still be large and difficult to diagnose and the the number of releases needed to achieve the same results as a bigger release meant there was more scope for human error. In response to this DevOps engineers used their development skills to create tools to make deployment easier.
Automation tools allow us to better manage the change process and de-skill making the change itself so engineers could focus on the impact and do more releases. With better tools to both orchestrate the change and monitor more widely in real-time the impact of the change we could react quicker to issues. The automation even allowed you to automate the release process formalities too if needed — to the satisfaction of compliance.
Now I, finally, get to the point of micro-services and change management. Microservices decomposes the business logic into smaller, independent chunks of code that are loosely coupled and ideally suited to continuous deployment. Of course a misbehaving microservice can still cause significant business issues but with correct tooling should be easily identified and reverted and most importantly can be done without slowing down other independent changes — so it scales.
Because microservices decompose the business logic, having 100s of Microservices is to be expected so good tooling and automation is essential for both release and debugging issues. If you invest upfront in good monitoring both at the macro (metrics, graph) and the micro (traces, correlation) level as well as orchestration tools then the actual process of releasing is low risk with limited scope of change. Related services in the architecture can help identify issues and in more mature platforms, automated rollback can be trigged if issues detected via the extensive monitoring.
Of course these microservices will have dependencies on infrastructure services and platforms that need updating and may not lend themselves to decomposition in the same way but they also need to change less and may indeed, in the next round of architectural enhancement, follow a similar path.
In short, microservices combined with comprehensive monitoring and orchestration eliminates the need for manual change management processes even at scale.