Safe rollback and guaranteed data consistency for continuous deployment of microservices

What can you do if a deployment goes wrong in your microservices environment?

The problem

So you are doing a microservices architecture. One of the main drivers of microservices is team autonomy so each time can develop and deploy new releases more or less independently. However, the main consequence is that compatibility with other microservices is at risk in every new release.

That is why continuous deployment (CD) and the ability to rollback to a previous release are crucial for succes:

• It ensures you can install new features in small increments (less risk of breaking things), and
• It ensures you can go back if things do break - without having to fallback to a release from 1 year ago with limited functionality

Regardless of whether you can already achieve the above or not, there is one more crucial aspect: the integrity of your distributed data.

More precisely: suppose you do an installation of (a new release of) microservice MS1. When it starts running, it calls another microservice MS2 and after that MS3. It turns out MS3 has compatibility issues with the new MS1 and could not update its data as per the invocation.

What now happens in MS2? Can you rollback the changes in MS2 before you put back the old release of MS1? Probably not, or maybe via an error-prone manual process of log inspection.

The solution

The easy solution to this is using our transaction support over microservice calls: MS1 starts a transaction and the calls to MS2 and MS3 are part of that. Any failures and MS1 (or the system) will rollback any database changes made, including changes in MS2.

Learning more

Find out more about this in our Microservice Transaction Patterns Book or try for yourself with our free trial of ExtremeTransactions:

Free Trial