SOFTWARE DEVELOPMENT

Microservices and How they Affect your Product

As it stands, there is not an agreed upon for­mal de­f­i­n­i­tion of mi­croser­vices ar­chi­tec­ture. The eas­i­est way to think of the con­cept is that it is a method of de­vel­op­ing soft­ware ap­pli­ca­tions. The way it dif­fers from other ap­proaches is the soft­ware ap­pli­ca­tion de­vel­oped is made up of in­de­pen­dently de­ploy­able, mod­u­lar ser­vices where each ser­vice serves a busi­ness goal by run­ning a unique process. In short, the mi­croser­vice ar­chi­tec­tural style is just an­other way to ap­proach de­vel­op­ment of a sin­gle ap­pli­ca­tion. It’s key dif­fer­en­ti­at­ing fac­tor is that it de­vel­ops via a suite of small ser­vices, each run­ning in its own process and com­mu­ni­cat­ing with light­weight mech­a­nisms.

Often re­ferred to as just mi­croser­vices, this method of de­vel­op­ment has grown in pop­u­lar­ity over the past few years and one com­pany util­is­ing it, is Codebots.

Codebots is a tech com­pany founded by WorkingMouse’s very own Dr Eban Escott. WorkingMouse uses the code-writ­ing bots to plan, de­sign, build and launch awe­some soft­ware to the cloud for our awe­some part­ners. One of the most pop­u­lar bots to date is Lampbot. The speed at which it can write lines of code is roughly 300,000 lines of code in a minute. The Lampbot ar­chi­tec­ture is based on mi­croser­vices.

One of the ben­e­fits of mi­croser­vices is scal­a­bil­ity, which makes it par­tic­u­larly well suited for pro­jects that re­quire sup­port for a range of plat­forms and de­vices. The way in which an ap­pli­ca­tion can be built with scal­a­bil­ity in mind is to de­sign with con­cur­rency and par­ti­tion­ing in mind. At the end of the day, scal­a­bil­ity is linked to the pro­cess­ing of tasks. It also is found to be use­ful for de­vel­op­ment where the fi­nal de­vice that needs to be sup­ported is­n’t known.

Monolith ap­pli­ca­tions are built as an au­tonomous unit and sin­gu­lar in de­sign. This does­n’t ring true for mi­croser­vices, in fact it is the po­lar op­po­site. This means there are is­sues sur­round­ing change cy­cles in a mono­lithic ar­chi­tec­ture be­cause they end up be­ing tied to one an­other. This pre­sents a big risk if or when any mod­i­fi­ca­tions need to be made. Say you want to mod­ify just a small sec­tion of your ap­pli­ca­tion, with a mi­croser­vices ar­chi­tec­ture this is­n’t a has­sle. With a mono­lithic ar­chi­tec­ture, you might end up build­ing and de­ploy­ing a to­tally new ver­sion of your ap­pli­ca­tion.

Coming back full cir­cle, mi­croser­vices en­ables de­vel­op­ers to scale spe­cific func­tions of an ap­pli­ca­tion with­out hav­ing to scale the en­tire ap­pli­ca­tion. To learn more about how Lampbot wraps its code in API pack­ag­ing check out this blog by WorkingMouse founder Dr Eban Escott.

ABOUT THE AUTHOR

Eban Escott

Get cu­rated con­tent on soft­ware de­vel­op­ment, straight to your in­box.

Your vi­sion,

our ex­per­tise

Book an con­sul­ta­tion