Why Microservices Require a DevOps Approach
Interest in Microservices as an architecture is growing, with a lot of interesting content and real world case studies coming out of the Microxchg conference in Berlin. Having succesfully delivered projects in this style, we think it's great that more people and looking at Microservices as an enabler for faster and more agile application delivery. We do however think that moving towards Microservices has quite far reaching implications for how you deliver software, which some people don't always fully commit too. The risk is that if you approach Microservices with a waterfall mindset (big design up front, release centricity, siloed and process driven build and run), you will probably end up with a much more complex system and hardly any of the benefits which Microservices give you! If you are doing Microservices, we think you simply need to incorporate elements of what is coming out of the DevOps movement - of course from an automation perspective but also from a people and process point of view. Here is why we believe this to be the case:
Microservice architectures lead to an explosion in the number of processes you have to manage. Your single monolithic application can turn into 10s, 100s, or even 1000s of independent services. Perhaps each of those have to be duplicated up or deployed for resilience to different regions, and of course created in development, test and production environments. All of these services in all of those places have to be tested, deployed, monitored, maintained and upgraded over time, representing a lot of operational complexity and overhead. Robust automation is essential if you want to manage a system with this sheer volume of processes and velocity of change going through it. This includes the obvious test, release and deployment automation, but also automation such as registering new services with load balancers, log file management, and live rolling upgrades of services for instance. On one Microservice project, we even had to automate creation of the source control repository as even that process was becoming so repetitive and time consuming!
Test Automation Becomes Much More Complex
Testing becomes much more complex in a distributed Microservice based application. The most immediate challenge is that to test services in an automated way, we have to bring them up in some kind of test harness that starts a number of processes and integrates them in some way. Perhaps this needs to happen on the developers machine or as part of the Continuous Integration process in order to automate full stack integration testing. Doing this can require a lot of DevOps smarts and take a lot of time if the development team have a strong tendency towards automated testing.
We Need To Carefully Manage Microservice Versions and Environment Consistency
We need to create and manage environments in very consistent ways and keep our development and test environments in line with production. This requires a lot of control around versions and sophisticated automation and understanding of both the code and the operating environment of the system. Specifying infrastructure as code can help you achieve all of this, allowing you to build consistent development, test and production environments from code and then promote infrastructure changes and services through those environments in a consistent and repeatable way inside of the software development lifecycle. In a monolithic application we get problems with snowflake servers and changes made directly to environments. I think these situations would bite you more severely in a Microservices architecture.
You Need To Optimise The Local Microservice Development Experience
Developers need to be able to develop against sets of integrated services in order to work most efficiently. Shared development environments always throw up stability problems and take time to deploy to, reducing development cycle time. Therefore, it is preferable to provide either many isolated development environments or enable realistic development environments on the desktop. DevOps is a huge enabler for developers from this perspective. For instance, DevOps approaches can helps you shift development environments back onto your local development machine, for instance taking advantage of tools such as Vagrant in order to build virtualised, realistic development environments. This will make it much easier to test Microservices.
Automate The Infrastructure That Underlies Your Microservices
Microservices are well suited to cloud environments. Rather than scaling out the monolith horizontally by adding huge new nodes, we can elastically scale out services at different paces depending on load characteristics at an individual service level. DevOps infrastructure automation approaches will help you achieve this by facilitating autoscaling, golden images, automatic deployments and dynamic service registration at runtime. If you don’t take advantage of virtualisation and cloud in this way, you will miss a huge advantage of Microservices architectures. Specifically, you will have a hugely sophisticated and flexible application architecture constrained by a very rigid platform to run on top of.
Close Development And Operations Alignment Is Needed
Throwing a monolithic application or ‘ball of mud’ over from development to operations brings all kinds of difficulties and sources of inefficiency. Throwing a more complex and rapidly changing ball of mud over the fence even more frequently is simply not going to work. In a siloed development and operations setup, the poor operations team will be fighting a losing battle trying to keep up with the pace of change and the complexity of the handover. Development and Operations have to be much more aligned in a Microservices situation, ideally working together in the same cross functional team to both develop and run the system. Everyone in this team should have shared and aligned incentives of delivering change balanced with stability.
DevOps Helps You Harness The Main Benefit Of Microservices – Delivery Speed
The main benefit of Microservice architectures is speed – the ability to iterate on individual services quickly and without being tied into monolithic release cycles. If you aren’t set up to do this then you are losing the main reason for going with a Microservices architecture in the first place. DevOps helps you achieve speed through people, process and technology change. We can automate every element of the path to production, but if you keep the same waterfall, process driven change management process with lots of manual sign offs occurring on a monthly or quarterly basis, you have literally thrown away the main benefits of a Microservice architecture.
You Need To Monitor Your Microservices Effectively
In a more rapidly evolving system, sophisticated monitoring is important. In order to speed up delivery, we may lower the testing barrier in favour of more full coverage for monitoring of outages, events and metrics. Services are going to be short lived, as perhaps will be the virtual servers that those services live on. Therefore, we need a more dynamic approach to monitoring – log aggregation, capturing and aggregating metrics across a more distributed environment, A lot of best practices around monitoring is coming form the DevOps community, with a lot of the innovation coming from open source tools such as Sensu, StatsD and Reimann. These can all be leveraged to enable the succesfull delivery and operation of Microservices.
You Can Leverage Containers, PAAS and IAAS To Make Microservices Tractable
Whilst not strictly aligned with DevOps, platforms such as the above can really help to manage some of the complexity of Microservice architectures by devolving it to the platform and removing those concerns from the developer, freeing them up to concentrate on value producing business logic. So these are some of the tools and approaches coming out of DevOps which will help you be succesful in your Microservices project. If you are looking at Microservices, it's worth taking a step back and working all of these principles into your approach.
