Safe roll­back and guar­an­teed data con­sis­ten­cy for con­tin­u­ous de­ploy­ment of mi­croser­vices

What can you do if a de­ploy­ment goes wrong in your mi­croser­vices en­vi­ron­ment?

The prob­lem

So you are do­ing a mi­croser­vices ar­chi­tec­ture. One of the main dri­vers of mi­croser­vices is team au­ton­o­my so each time can de­vel­op and de­ploy new re­leas­es more or less in­de­pen­dent­ly. How­ev­er, the main con­se­quence is that com­pat­i­bil­i­ty with oth­er mi­croser­vices is at risk in every new re­lease.

That is why con­tin­u­ous de­ploy­ment (CD) and the abil­i­ty to roll­back to a pre­vi­ous re­lease are cru­cial for suc­ces:

• It en­sures you can in­stall new fea­tures in small in­cre­ments (less risk of break­ing things), and
• It en­sures you can go back if things do break - with­out hav­ing to fall­back to a re­lease from 1 year ago with lim­it­ed func­tion­al­i­ty

Re­gard­less of whether you can al­ready achieve the above or not, there is one more cru­cial as­pect: the in­tegri­ty of your dis­trib­uted data.

More pre­cise­ly: sup­pose you do an in­stal­la­tion of (a new re­lease of) mi­croser­vice MS1. When it starts run­ning, it calls an­oth­er mi­croser­vice MS2 and af­ter that MS3. It turns out MS3 has com­pat­i­bil­i­ty is­sues with the new MS1 and could not up­date its data as per the in­vo­ca­tion.

What now hap­pens in MS2? Can you roll­back the changes in MS2 be­fore you put back the old re­lease of MS1? Prob­a­bly not, or maybe via an er­ror-prone man­u­al process of log in­spec­tion.

The so­lu­tion

The easy so­lu­tion to this is us­ing our trans­ac­tion sup­port over mi­croser­vice calls: MS1 starts a trans­ac­tion and the calls to MS2 and MS3 are part of that. Any fail­ures and MS1 (or the sys­tem) will roll­back any data­base changes made, in­clud­ing changes in MS2.

Learn­ing more

Find out more about this in our Mi­croser­vice Trans­ac­tion Pat­terns Book or try for your­self with our free tri­al of Ex­tremeTrans­ac­tions:

Free Tr­i­al