What are microservices and should you be using them?

Leo Tol­stoy began Anna Karen­i­na with the immor­tal obser­va­tion that “hap­py fam­i­lies are all alike; every unhap­py fam­i­ly is unhap­py in its own way”. It’s also true of tech firms. 

Each of the hap­less ones is unique, pro­duc­ing its own par­tic­u­lar hotch-potch of back-end hor­rors, where­as the suc­cess­ful com­pa­nies look spook­i­ly sim­i­lar when you open the bon­net. Con­sid­er Ama­zon, eBay, Etsy, Face­book, Google and Spo­ti­fy. They all run on a par­al­lel set of tools and ideas. An engi­neer could move from Ama­zon to Spo­ti­fy, say, and know their way around on day one. 

One of the key attrib­ut­es that these giants have in com­mon is their use of microser­vices. The con­cept has become so impor­tant that any com­pa­ny fail­ing to rebuild itself around microser­vices could be con­sid­ered obso­les­cent.

A sur­vey of CIOs and CTOs in March by US soft­ware firm Kong found that 86% con­sid­ered microser­vices to be the future of appli­ca­tions. More­over, 84% agreed that any firm that can’t ensure the reli­a­bil­i­ty of the appli­ca­tion pro­gram­ming inter­faces (APIs) that link microser­vices-based apps is like­ly to lose mar­ket share to rivals that can.

Microser­vices seem to be cru­cial, then, but what do they actu­al­ly do? In the sim­plest terms, they are the alter­na­tive to mono­lith­ic code­bas­es. In the old days, soft­ware would be com­posed as a sin­gle block, which would be a night­mare to update. Teams would squab­ble over how and when to com­mit new code. Any error meant that debug­ging teams need­ed to scour the entire code­base to find the cul­prit. 

In essence, microser­vices split an appli­ca­tion into autonomous chunks that work inde­pen­dent­ly. The sep­a­rate parts sit in the cloud and com­mu­ni­cate with each oth­er via APIs. This set-up has numer­ous advan­tages, but one of the most impor­tant ones is that it enables one team to update a microser­vice in its own time with­out hav­ing to both­er any oth­er par­ty. Errors are eas­i­er to pin­point and fix. 

Finan­cial soft­ware provider WealthK­er­nel is a strong advo­cate of microser­vices. Chris Wright, its CTO, explains: “In soft­ware terms, the decom­po­si­tion of large sys­tems into microser­vices means that they can be worked on and deployed inde­pen­dent­ly. As the old say­ing goes: the eas­i­est way to eat an ele­phant is one bite at a time. This allows for increased team auton­o­my, faster release cycles and improved iso­la­tion of faults.” 

He reveals that WealthKernel’s pro­duc­tion plat­form con­sists of 51 microser­vices, but adds that “this num­ber grows every time we incor­po­rate new func­tion­al­i­ty. We expect to have 70 by the end of the year.”

The usu­al prac­tice is to grant each dis­tinct func­tion in an appli­ca­tion its own microser­vice. Suresh Chin­ta­da, CTO of Subex, an Indi­an firm spe­cial­is­ing in soft­ware for tel­cos, explains that “each microser­vice does one thing real­ly well. This under­ly­ing con­cept allows us to set the bound­ed con­text and focus on deliv­er­ing that sin­gle capa­bil­i­ty with high qual­i­ty.”

Gone are the days when teams need­ed to coor­di­nate their activ­i­ties for every upgrade. Now that each activ­i­ty has been ren­dered autonomous, teams can inter­vene when­ev­er they see fit, he adds. “Devel­op­ment teams can work inde­pen­dent­ly to build or enhance a prod­uct by focus­ing on the ser­vices they own. This allows them to oper­ate in par­al­lel, as it’s only the inter­faces that they care about to inter­act with ser­vices being built by oth­er teams.”

There’s also the mat­ter of deploy­ment. It is pos­si­ble for a microser­vice to be host­ed in a dif­fer­ent envi­ron­ment – a pub­lic cloud plat­form such as Microsoft Azure, for instance – and work with relat­ed microser­vices host­ed on Ama­zon Web Ser­vices or Google Cloud. 

“Microser­vices offer high scal­a­bil­i­ty,” Chin­ta­da says. “As each ser­vice is a sep­a­rate com­po­nent, we can scale it up or down with­out hav­ing to do the same thing with the entire appli­ca­tion.”

Nat­u­ral­ly, there are dis­ad­van­tages to this high­ly mod­u­lar archi­tec­ture. With scores or even hun­dreds of microser­vices need­ing to com­mu­ni­cate with each oth­er in some cas­es, there is a greater expo­sure to cyber risks. Con­ver­sa­tions about ensur­ing data secu­ri­ty are nev­er far away.

Gov­er­nance can be trick­i­er too: in sit­u­a­tions where dozens of teams are oper­at­ing inde­pen­dent­ly with dif­fer­ent agen­das, it can be hard to coor­di­nate large-scale changes. The costs of imple­men­ta­tion and ongo­ing staffing also tend to be rel­a­tive­ly high for microser­vices.

Such down­sides encour­age small­er soft­ware firms to con­tin­ue with their tra­di­tion­al mono­lith­ic code­bas­es. A com­pro­mise approach, known as ser­vice-ori­ent­ed archi­tec­ture (SOA), may be a bet­ter bet for some of these com­pa­nies. SOA is a design prin­ci­ple under which soft­ware com­po­nents are loose­ly cou­pled but mim­ic inde­pen­dence. 

Justin Bid­dle, head of UK strat­e­gy and busi­ness devel­op­ment at ecom­merce plat­form Shop­ware, believes that there may be mer­it in tak­ing the SOA route. 

“While microser­vices have their place, I’m against the idea that every­one should be using them,” he argues. “Espe­cial­ly for mid-mar­ket busi­ness­es, the best way to strike a bal­ance between microser­vices and mono­liths is gen­er­al­ly to find the mid­dle ground: the SOA archi­tec­ture. This pro­vides broad­er appli­ca­tions, with the abil­i­ty to align best-of-breed ser­vices with a decent out-of-the-box solu­tion stack. This way, devel­op­ers have enough flex­i­bil­i­ty to extend a plat­form as required, with­out exces­sive com­plex­i­ty.”

Nonethe­less, microser­vices look set to become the default choice in dig­i­tal trans­for­ma­tion. The human fac­tor alone may decide it. After all, engi­neers want to apply the lat­est tools and prin­ci­ples – and, right now, that means microser­vices. Who knows when an eBay or an Etsy might come call­ing with a six-fig­ure salary for an engi­neer versed in their ways? 

When all the big guns declare them­selves in favour of an idea, it’s hard to dis­agree.