In an earlier blog we concluded that microservices architecture is a good place to start your integration layer design principles. We also briefly touched the advantages for continuous delivery. In this blog we take a closer look at how a microservices architecture helps with continuous delivery.
When working with a microservices architecture, applications are built as a collection (or suite) of services. Services are developed independently, allowing them to be deployed independently. The low dependencies between the different services makes implementing continuous delivery a lot easier.
With continuous delivery we strive to make deployments as boring as possible. To assure that we try to deploy often and find errors as soon as possible. A number of best practices in a microservices architecture help us to achieve that.
Smart endpoints and dumb pipes
By making sure your pipe – read your enterprise service bus – does only what it is meant for (transportation and transformation), you create highly independent services. All the logic is in the endpoint and no logic is in the pipe. This makes it easier to test the part of the application that you are working on without the need to have an environment with the complete system on it.
Of course you need to do a complete end to end test (and automate that). However, you can deliver higher quality in one part of the system because you can be more confident than in a monolithic architecture that is it works on itself. It will work in the whole.
By taking the logic out of the pipe you make it easier to build quality into your applications. No big dependency management system which prevents you from detecting problem in an early state. The introduction of techniques like service virtualization is easier in this setup and helps to maintain a high quality.
Easy deployment pipeline
When implementing continuous delivery a pipeline is created to move software from development through production. The purpose is to do this often and to get feedback to the developer quickly. With monolithic application setting up the pipeline can be very complex. In order to prepare the environments needed a lot of dependencies have to be met.
The goal of microservices is to make a part of a larger system that can be taken to production on its own. The only dependencies you have are therefore in your own part of the system. This generally makes it a lot less difficult to set up environments. And thus makes it easier to deploy fast and to automate the complete cycle.
You build it, you run it
Teams working with microservices tend to like the “you build it, you run it” approach. The team is not only responsible for delivering good software, but also for the performance of the software on the production environment. This gives a big incentive for the team to deliver software with high quality. And the team will make sure that, by automating tests and testing as early as possible, good quality is delivered.
This again removes a dependency. Not a technical one but an organizational one. The team itself has to be able to run the software and maintain it. So there is no need to create cross organizational processes to maintain the software
Resilience
When applying continuous delivery we try to ship code to production as often as possible. That is sometimes seen as a risk. In many organizations releases are big events that are done only a few times per year. The idea is that releases are a big risk and should be avoided as much as possible. And because of dependencies it is not possible to do it more often.
With microservices you create a system that is very resilient. When one microservice fails, your system is still running. It might lose a part of the functionality but the rest is still working and serving your customers. That reduces the risk of deployment. Even if a deployment breaks, the impact is small. And it is easy to roll back.
More about Microservices
