Deployment autonomy on microservices

Introduction

Deployment autonomy is one of the characteristics you would expect in a microservices architecture. The ability to deploy a given microservice without needing to coordinate with other microservices deployment is especially useful if you have a team in charge of each microservice.

In this article, I will explain how to achieve this.

What is deployment autonomy in the context of a microservices architecture?

First, we need to define what exactly deployment autonomy means: the ability to deploy a microservice without any further action with regards to other microservices, while the whole microservices architecture is still working with any downtime or error-prone period. No additional microservices needed to be deployed, no global migrations, no nothing. Only one microservice deployment.

If you need to deploy more than one microservice at the same time because one depends on the other, you don't have deployment autonomy; if you have shared databases so one deployment on one microservice affects others, you don't have deployment autonomy; if you need to ping another team so they are aware of your deployment, you don't have deployment autonomy; if you need a token to "block" the deployment of other microservices while you are deploying yours... well, you get it.

What does it require to have deployment autonomy?

To achieve this characteristic of the microservices you need some things to be in place:

• You can't share any persistence system, such as databases or cache systems. If you share this kind of service, then deploying one microservice can affect others.
• If you are communicating some of your microservices using HTTP calls, you need these endpoints to be versioned and you always need to maintain some degree of backward compatibility; this compatibility period shouldn't be infinite, so other microservices need to be updated regularly so you can deprecate old versions.
• If you are communicating some of your microservices using messages, such as in a messaging queue, messages need to be versioned, and you need to fire both versions, the previous and the new one, during the backward compatibility period; again, this period should not be infinite, so can eventually deprecate versions and stop firing them.

What are the advantages of having deployment autonomy?

The amount of flexibility you can achieve if you can deploy microservices on their own, without dependencies, is huge:

• First, if you have squads assigned to the microservices, then they can work at different paces, with different priorities and backlogs. This gives the company a lot of flexibility and helps product owners to fill gaps.
• It allows upgrading languages or frameworks versions microservice by microservice, without needing to upgrade the whole microservices architecture at the same time.
• Progressive deployment allows testing new versions of the system one by one, reducing risks.
• It reduces the number of big deployments that use to happen at night.

Conclusion

I like to say that, if you don't have deployment autonomy, you don't have a microservices architecture, but a distributed monolith. This is because, if you need to deploy many microservices at the same time, it's like deploying a monolith, with all the disadvantages of the monoliths and no one from the microservices. Take this into consideration when you design your new architecture.