The Role of API Gateways in Microservice Architectures

Despite their differences in nomenclature, newly emerging service meshes aren’t all that different that API Gateways, and the similarities between the two will continue to grow over time, so predicts Marco Palladino, Chief Technology Officer of API Gateway provider Mashape.

The two technologies actually offer quite similar functionality, Palladino noted. API Gateways, such as Amazon Web Services‘ API Gateway or Mashape’s own open source Kong, have been primarily used over the last decade or so for mapping external traffic to internal resources, whereas the more recently developed service meshes — such as Lyft’s Envoy or Uber’s Catylist— have been primarily been on brokering internal resources in a microservices architecture.

“When you think of gateways, you usually think of a centralized layer, an extra hop in the network that is processing additional features. But that doesn’t necessarily have to be true,” Palladino said, speaking at MesosCon 2017, held last week in Los Angeles. Gateways can also offer an effective way to handle communications across microservices. “You can also run Kong alongside your existing microservices, getting rid of the extra hop and reducing the latency,” he said.

👁 Image

APIs have been a favored method of communication exchange for the past 10 years, and Docker made it easy to set a microservices architecture, in which applications and services are composed of smaller, exchangeable components. But these components need a way to find and communicate with one another. This is where API gateways come in.

API gateways “can become an abstraction layer that sits on the execution path of every request that goes to one of these microservices,” Palladino said.

The gateway consolidates the path to all of a system’s commonly used features, such as authentication or service discovery, which can be recognized by the gateway through plug-ins. “Plug-ins are effectively middleware functionality that you can dynamically apply on top of any microservice,” he said.

API gateways can also aggregate service requests to and from these features. The client can make one response, which the gateway can break into multiple service requests, saving the bandwidth of having the client make all the calls itself.  The gateway will also keep track of the requests.

Carving #Microservices from monoliths is like making chicken nuggets from a chicken, while keeping the chicken alive –@thefosk #MesosCon pic.twitter.com/medzXUITyb

— The New Stack (@thenewstack) September 14, 2017

As an organization starts breaking down a monolithic app into microservices, the gateway can also minimize the impact the resulting changes would have on the client itself. “The gateway can be that curtain that you put in front of the monolithic application. The client will deal with the gateway only, and you can decouple your monolithic app behind the curtain, and not have to worry about updating your clients,” he said.

“This is particularly useful if you do not control your clients,” he said.

Traditionally, API gateways have been used at the edge of an organization’s networks, handling traffic that was mostly between a monolithic application and outside clients. A microservices architecture, however, shifts most of this traffic to inside the internal network itself, as different microservices communicate among themselves.  “You still have the external client use case, but that becomes one of the many clients that are now consuming those microservices,” Palladino explained.

Built on top of the Nginx high-performance server software, Mashape’s Kong is the most widely used open source API gateway, with more than 200,000 running instance a month, Palladino boasted. With Kong, Nginx is extended with the middleware, which can be dynamically provisioned called through a JSON RESTful call.

👁 Image