Mi­croser­vices and the API Gate­way

OpenSource For You - - Contents - By: A. Arasku­mar The au­thor works at HCL Tech­nolo­gies as a tech­ni­cal lead. He can be reached at aarasku­mar@ya­hoo.com.

Mi­croser­vices is an ar­chi­tec­tural style for build­ing ap­pli­ca­tions that are struc­tured into sev­eral loosely cou­pled ser­vices. An API gate­way acts as a sin­gle en­try point into the sys­tem. This ar­ti­cle, aimed at de­vel­op­ers who work in API, mo­bile and Web de­vel­op­ment, ex­plains how the two can be used in tan­dem.

An API gate­way is a man­age­ment tool to cre­ate, pub­lish, main­tain, mon­i­tor and se­cure APIs. You can cre­ate APIs that carry out a spe­cific func­tion of your logic or that can ac­cess other Web ser­vices. To un­der­stand this bet­ter, con­sider the fol­low­ing ex­am­ple. We are build­ing a client for a shop­ping ap­pli­ca­tion and need to im­ple­ment a ‘Prod­uct de­tails’ page, which dis­plays in­for­ma­tion about any given prod­uct.

Fig­ures 1(a), 1(b) and 1(c) show what you will see when scrolling through the ‘Prod­uct de­tails’ page in any shop­ping site (this one is from Ama­zon). The page also shows other in­for­ma­tion, which in­cludes:

1. Se­lected prod­uct in­for­ma­tion

2. Or­der his­tory 3. Cart

4. Re­views of the prod­uct

5. In­ven­tory and ship­ping

6. Var­i­ous rec­om­men­da­tions, in­clud­ing other prod­ucts fre­quently pur­chased with this prod­uct, and so on.

Mono­lithic ar­chi­tec­ture

The pro­gram (in any lan­guage or frame­work) for this can be de­vel­oped us­ing a mono­lithic ar­chi­tec­ture. This is noth­ing but a tra­di­tional uni­fied model for the de­sign of a soft­ware pro­gram. In this con­text, mono­lithic means all the com­po­nents are in­ter­con­nected and in­ter­de­pen­dent, rather than loosely cou­pled. In this tightly cou­pled ar­chi­tec­ture, all

the com­po­nents should be present in a sin­gle pack­age/code base for the page to be ren­dered. In our ex­am­ple, a client would re­trieve this data by mak­ing a sin­gle REST call (GET, api.com­pany.com/prod­ucts/ pro­duc­tId) in the ap­pli­ca­tion. A load bal­ancer or a clus­ter may route the re­quest to one of N ap­pli­ca­tion in­stances. The ap­pli­ca­tion then queries var­i­ous data­base ta­bles and re­turns the re­sponse to the client.

The ad­van­tage of this de­sign is that the var­i­ous func­tion­al­i­ties like log­ging, au­dit trails, mid­dle­ware, etc, are all hooked to one app wherein any changes, cor­rec­tions and op­ti­mi­sa­tions can be done eas­ily. One more ad­van­tage is that shared mem­ory is faster than in­ter-process com­mu­ni­ca­tion (IPC).

In spite of the ad­van­tages, there are many con­cerns in this pat­tern. As com­po­nents are tightly cou­pled it is dif­fi­cult to iso­late ser­vices for any pur­pose such as in­de­pen­dent scaling or code main­tain­abil­ity. The com­po­nents be­come much harder to un­der­stand in the long run as the code base grows in size and is not ob­vi­ous when look­ing at a par­tic­u­lar ser­vice or con­troller. Down the line, the ap­pli­ca­tion is sure to go out of con­trol; so this is not a good idea.

Mi­croser­vice ar­chi­tec­ture

This de­sign uses small, mod­u­lar units of code that can be de­ployed in­de­pen­dent of the rest of the prod­uct’s com­po­nents. An ap­pli­ca­tion is a col­lec­tion of loosely cou­pled ser­vices and each ser­vice is fine grained, thus im­prov­ing mod­u­lar­ity and mak­ing the ap­pli­ca­tion eas­ier to un­der­stand, as well as faster to de­velop, test and de­ploy.

Mi­croser­vices com­po­nents are mod­u­lar, so each ser­vice can be built, up­dated and de­ployed in­de­pen­dent of any other code. Each mi­croser­vice is re­spon­si­ble for a spe­cific pur­pose or task. Each ser­vice ab­stracts away im­ple­men­ta­tion de­tails, ex­pos­ing only a well­doc­u­mented in­ter­face; so

APIs can be con­sumed in a con­sis­tent way, re­gard­less of how ex­actly the ser­vice is built. In our shop­ping ap­pli­ca­tion, the data dis­played on the ‘Prod­uct de­tails’ page is from mul­ti­ple mi­croser­vices. Some of the po­ten­tial mi­croser­vices are: Shop­ping cart ser­vice

Cat­a­logue ser­vice

Re­view ser­vice

Ship­ping ser­vice Rec­om­men­da­tion ser­vice In the­ory, a client could make a re­quest to each of the mi­croser­vices, di­rectly. Each ser­vice can have an end point like http://ser­vice.api. com­pany.com. This URL would map to the mi­croser­vice’s load bal­ancer, which dis­trib­utes re­quests across the avail­able in­stances. To re­trieve the prod­uct de­tails, the mo­bile client would make re­quests to each of the re­quests listed above.

Un­for­tu­nately, there are some chal­lenges and dif­fi­cul­ties with this op­tion. One prob­lem is the mis­match be­tween the client and the fine grained APIs ex­posed. In this ex­am­ple, the client has to make seven sep­a­rate re­quests for a page. In a com­plex ap­pli­ca­tion, hun­dreds of ser­vices may be in­volved in a page, and this would prob­a­bly prove in­ef­fi­cient over a pub­lic net­work and quite im­pos­si­ble over a mo­bile net­work.

An­other hur­dle with the client di­rectly call­ing the mi­croser­vices is that it might use a pro­to­col that may not be Web-friendly. One ser­vice may use RPC and an­other the AMQP mes­sag­ing pro­to­col. Nei­ther of them is browser- or fire­wall-friendly, and both are best suited in­ter­nally. An ap­pli­ca­tion should use only HTTP and Web Socket out­side of the fire­wall.

Yet one more draw­back with this ap­proach of the client call­ing the mi­croser­vices is that it is

dif­fi­cult to refac­tor the ser­vices. Over time, there might be a re­quire­ment to merge two ser­vices or split a ser­vice into two or more parts. If the client com­mu­ni­cates di­rectly, per­form­ing this kind of refac­tor­ing will be ex­tremely dif­fi­cult.

When an API gate­way comes into the pic­ture

A much bet­ter ap­proach would be to use what is known as an API gate­way. This is a sin­gle en­try point to the sys­tem. It en­cap­su­lates the in­ter­nal ar­chi­tec­ture and pro­vides the ser­vice tai­lored to each client. It might also have other re­spon­si­bil­i­ties that in­clude au­then­ti­ca­tion, mon­i­tor­ing, log­ging, caching, static re­sponse han­dling, etc.

An API gate­way is re­spon­si­ble for re­quest rout­ing, com­po­si­tion and pro­to­col trans­la­tion. All the re­quests from the client go through an API gate­way. It then routes re­quests to the ap­pro­pri­ate mi­croser­vice. The

API gate­way will of­ten han­dle a re­quest by in­vok­ing mul­ti­ple mi­croser­vices and then ag­gre­gate the re­sults. It can trans­late be­tween Web-friendly and Web-un­friendly pro­to­cols.

Here, in our ex­am­ple, the API gate­way can pro­vide an end­point like /prod­ucts/pro­duc­tId=xxx that en­ables a client to re­trieve all the prod­uct in­for­ma­tion (as well as other de­tails) in a sin­gle re­quest. In our case, the API gate­way han­dles this re­quest by in­vok­ing the var­i­ous ser­vices like ship­ping, the rec­om­men­da­tion ser­vice, re­views, etc.

Ben­e­fits and draw­backs

As you might ex­pect, us­ing an API gate­way comes with both ben­e­fits and dis­ad­van­tages. A ma­jor ben­e­fit is that it en­cap­su­lates the whole in­ter­nal struc­ture. Since rather than call­ing var­i­ous ser­vices in­di­vid­u­ally, clients call the API gate­way, this re­duces the num­ber of round trips be­tween the client and the ap­pli­ca­tion, and hence sim­pli­fies the client code.

On the down side, this is yet an­other com­po­nent that must be de­vel­oped, de­ployed and man­aged. De­vel­op­ers must up­date the gate­way in or­der to ex­pose each mi­croser­vice end­point. The process of up­dat­ing should be light­weight. Oth­er­wise, de­vel­op­ers will be forced to wait in queue to up­date their ser­vice, which in turn may af­fect the busi­ness.

De­spite these draw­backs, for most (al­most all) re­al­world ap­pli­ca­tions, it makes sense to use an API gate­way.


Let’s look at the var­i­ous de­sign is­sues to con­sider when im­ple­ment­ing an API gate­way.

Per­for­mance and scal­a­bil­ity: Only a hand­ful of com­pa­nies need to han­dle bil­lions of re­quests per day. In any case, the per­for­mance and scal­a­bil­ity of an API gate­way is more im­por­tant as this is the en­try point. It is there­fore nec­es­sary to build the API gate­way on a plat­form that sup­ports asyn­chro­nous and non­block­ing I/O.

Ser­vice in­vo­ca­tion: As this is a dis­trib­uted sys­tem, it must use an in­ter­pro­cess com­mu­ni­ca­tion mech­a­nism.

There are two styles of IPC. One op­tion is to use an asyn­chro­nous, mes­sage-based mech­a­nism like JMS or AMQP. An­other op­tion is to use any syn­chro­nous mech­a­nism such as HTTP.

Ser­vice dis­cov­ery: The API gate­way has to know the lo­ca­tion of all mi­croser­vices it needs to com­mu­ni­cate with. In­fra­struc­ture ser­vices such as mes­sage bro­kers will have a static lo­ca­tion. An API gate­way can use two ways to de­ter­mine the lo­ca­tion—server side dis­cov­ery and client side dis­cov­ery. It is be­yond the scope of this ar­ti­cle to get into the de­tails of these two types of dis­cov­ery; yet, if the sys­tem uses client side dis­cov­ery, the API gate­way must be able to query the ser­vice registry to de­ter­mine any ser­vice lo­ca­tion.

Han­dling fail­ures: This is­sue can arise in al­most all dis­trib­uted sys­tems when one ser­vice calls an­other ser­vice that is re­spond­ing slowly or is un­avail­able. For ex­am­ple, if the rec­om­men­da­tion ser­vice is un­re­spon­sive in our Prod­uct de­tails sce­nario, the API gate­way should be able to serve the rest of the prod­uct de­tails as they are still use­ful to the client. An un­re­spon­sive ser­vice can be re­turned by any de­fault re­sponse.

The API gate­way could also re­turn cached data if it is avail­able. An ex­am­ple is the prod­uct prices, for which changes are not fre­quent. Prices can be cached in the API gate­way it­self, in Redis or Mem­cached. By re­turn­ing ei­ther de­fault data or cached data, the gate­way en­sures that sys­tem fail­ure does not af­fect the user ex­pe­ri­ence.

For most mi­croser­vices based ap­pli­ca­tions, the API gate­way, which acts as a sin­gle en­try point, is an ideal so­lu­tion. The gate­way can also mask fail­ures in the back­end ser­vices, im­prove ser­vice mes­sag­ing, as well as ab­stract some of the com­plex­i­ties and de­tails of the mi­croser­vice ar­chi­tec­ture.

Kong is a pop­u­lar open source API gate­way. NGINX Plus, Red Hat and 3scale each of­fer a free trial.

Fig­ure 3: Po­ten­tial mi­croser­vices

Fig­ure 2: The dif­fer­ence be­tween the two ar­chi­tec­tures

Fig­ure 1(a): Prod­uct de­tails pages of Ama­zon

Fig­ure 1(b): Prod­uct de­tails pages of Ama­zon

Fig­ure 1(c): Prod­uct de­tails pages of Ama­zon

Fig­ure 4: API gate­way

Newspapers in English

Newspapers from India

© PressReader. All rights reserved.