4 Mi­croser­vice Myths and How to Avoid Them

In this ar­ti­cle we'll be de­bunk­ing 4 mi­croser­vice myths that can get you into trou­ble, and point you to­wards 5 com­mon pit­falls that will ruin your data con­sis­ten­cy in the long run...

When start­ing out with mi­croser­vices there are com­mon mis­con­cep­tions that can get you into trou­ble lat­er. This ar­ti­cle gives a short overview of these myths and of­fers a good next step to­wards avoid­ing sev­er­al pit­falls.

Myth #1: mi­croser­vices is about tech­nol­o­gy

Not true:

The only valid rea­son to do mi­croser­vices is be­cause it op­ti­mis­es team size and ve­loc­i­ty, by avoid­ing that de­vel­op­ers step on each oth­er’s toes in the code­base and mess up re­lease cy­cles. So it's all about ef­fi­cien­cy, not about tech­nol­o­gy. Tech­nol­o­gy is only there to en­able cer­tain things.

Myth #2: mi­croser­vices means HTTP/REST/JSON

Not true:

This prac­tice in­vari­ably leads to many more tech­ni­cal fail­ures that users don’t want to know about (see the down­load at the end of this post for what can go wrong). Also re­alise that server­less still runs on servers (and thus re­quires net­work de­lays and all that) so be­ware of the cost.

In­stead, con­sid­er mes­sag­ing (to lim­it net­work is­sues) or gRPC (to en­hance com­pat­i­bil­i­ty across re­leas­es).

If you can't do ei­ther, con­sid­er do­ing a con­sumer-dri­ven con­tract ap­proach to test new re­leas­es ear­ly for com­pat­i­bil­i­ty with ex­ist­ing clients / mi­croser­vices. This, how­ev­er, comes at an ex­tra de­vel­op­ment cost.

Myth #3: be­liev­ing that it’s all about be­ing poly­glot

Not true:

Every mi­croser­vice needs some cross­cut­ting con­cern sup­port, and this re­quires ex­tra over­head from your in­fra­struc­ture teams. Lim­it this over­head in ex­change for bet­ter and more ef­fi­cient sup­port from the in­fra­struc­ture teams: mon­i­tor­ing, in­stru­men­ta­tion, re­li­a­bil­i­ty and fault-tol­er­ance.

In oth­er words: just be­cause you have a cou­ple of idle .Net de­vel­op­ers around doesn't mean you should not fo­cus on Java. Or the oth­er way around.

Re­lat­ed to this: if you're a tech­nol­o­gy or de­vel­op­ment man­ag­er then you prob­a­bly know how much de­vel­op­ers like to learn and use new tech­nol­o­gy. Go­ing mi­croser­vices is not an ex­cuse to mix-and-match what­ev­er new gad­gets you (or rather: they) like.

To make mat­ters worse: poly­glot per­sis­tence has se­ri­ous pit­falls with re­spect to data con­sis­ten­cy (see the down­load at the end of this post for what can go wrong).

Myth #4: “dis­trib­uted trans­ac­tions - just say no!”

Not true at all:

Believ­ing that data con­sis­ten­cy is guar­an­teed by the “pat­terns” out there (no­tably sagas and/or even­tu­al con­sis­ten­cy) is the fi­nal and prob­a­bly the most dan­ger­ous myth.

You would be sur­prised how many ex­perts still claim this to be the case. The cause of this mis­con­cep­tion is that peo­ple tend to con­fuse dis­trib­uted trans­ac­tions with syn­chro­nous calls. Even if you make things asyn­chro­nous via your lat­est great­est event bus / bro­ker, you still have "dis­trib­uted trans­ac­tions" that need to be man­aged (whether you choose to call it an "ele­phant" in­stead does not change the core of the mat­ter).

The bot­tom line re­gard­ing this myth: the pat­terns peo­ple use don't ac­tu­al­ly work cor­rect­ly and on top of that take a lot of need­less de­vel­op­ment ef­fort. See the down­load be­low for what can go wrong...

FREE PDF cheat sheet: 5 com­mon data con­sis­ten­cy pit­falls with mi­croser­vices

We have 20+ years of ex­pe­ri­ence in re­li­a­bil­i­ty for dis­trib­uted sys­tems geared to­wards cus­tomers who val­ue data in­tegri­ty the most: fi­nan­cial ser­vices. This has al­lowed us to iden­ti­fy 5 com­mon data con­sis­ten­cy pit­falls that peo­ple en­counter in their mi­croser­vice ar­chi­tec­tures. Learn these 5 data con­sis­ten­cy pit­falls (that hap­pen even with Sa­gas, Kaf­ka bro­kers or even­tu­al con­sis­ten­cy) and get in­tro­duced to our way of do­ing mi­croser­vices:

Send me the PDF!

I have read and ac­cept the pri­va­cy pol­i­cy.