Using an API Gateway in Your Microservices Architecture

Working with a microservices API gateway can greatly reduce coding efforts, make your applications far more efficient, and decrease errors all at that same time. An advantage of using microservicesis that you don’t have to interact with a huge code base. Microservices are small and flexible. You can choose precisely which bits of code you want to interact with and from where those bits come. It’s possible to mix and match bits of code as needed. However, the small nature of microservices can also be a problem because those little bits of code end up coming from all sorts of sources—each of which can have its own set of rules.

Trying to keep track of all those microservices, and knowing when and how to use each of them can cause even the most fastidious developer headaches and worry. The need to track microservices and make them easier to use is one reason to use an API gateway. Using an API gateway makes your collection of microservices look like a custom API—one especially developed to meet your application’s specific needs. From the front it looks like an API, but from the back it uses individual microservices to perform tasks—you get the best of both worlds. This article provides you with the keys for using an API gateway and helps you gain a significant advantage over your competition, which is likely still floundering in a sea of microservices. You can read more here about How to Create a Microservices Setup, but this article can be read first.

What Precisely is a Microservices API Gateway?

In many respects, a microservices API gateway behaves precisely like any other API gateway. It’s important not to confuse a microservices API gateway with API management (see the article, “How Amazon API Gateway Shakes Up Your API Management Strategy” for a description of the difference). What a microservices API gateway provides is a front end used to access the microservices underneath—there is no support for publishing, promoting, or administering services at any significant level.

However a microservices API gateway does more than simply create a single interface for a single application. A single microservices API gateway can create multiple APIs—one for each platform you need to support as shown in Figure 1. For example, you might need to support smartphone native applications, browsers, and server-side applications—each of which requires a different set of microservice features (and may require different protocols as well). An API gateway can create a custom API for each of these clients so that the client sees just the features it needs. Rather than a bulky array of microservices, you now have one sleek API customized for each platform that makes writing applications fast and easy.

Understanding Microservices API Gateway Efficiencies

Combining the microservices in specific ways is only part of the solution. Each microservice may also have special needs. The most common need is the use of a particular set of protocols for access. Trying to access each microservice using its particular protocol setup in a client application is hard. The microservices API gateway provides protocol translation so that each microservice receives requests using the needed protocol, yet the clients rely on just the single protocol they support best. The use of protocol translation means that developers can focus on programming issues instead of how to access the microservices—reducing coding time and potential coding errors at the same time.

By allowing the clients and the services to use the protocols that best serve their individual needs, you also get a speed increase. The microservices API gateway performs all of the required protocol translations automatically, so everyone appears to speak the same language, even when they aren’t. The result is an optimized communication stream that allows faster data flow between endpoints.

The microservices API gateway also makes it possible for clients to use a single call to request data. When working directly with microservices, a client may need to call several services to obtain enough information for just one screen of information. Each of these calls uses network bandwidth and requires additional client code. A single call makes the call far more efficient.

Simulating Features with Virtual APIs

During application development, one team might be creating microservices while another team is writing the applications to use those microservices. A typical approach to allowing both teams to proceed is to rely on mocking or API-focused service virtualization, where a call to a microservice provides either a static or dynamic response such as from ServiceV in Ready API. The mocked response stands in for the microservice until the microservice becomes functional and can provide live data. Relying on a microservices API gateway makes it possible to perform configuration tasks associated with mocking to hide the fact that the data is mocked. The application behaves precisely as it will when the microservice code is complete. What this means to the developer is that activities such as debugging, become more realistic and there is no need to change any configuration information later (when the microservice becomes operational). As far the application is concerned, the microservice is always operational and fully functional, even though it’s mocked during part of the development cycle.

You can Virtualize Your APIs with ServiceV Pro

Considering the Drawbacks

It may seem at first that using a microservices API gateway would be a perfect solution to the problem of dealing with a host of microservices. However, there are drawbacks for any solution and a microservices API gateway has several. The most obvious of these drawbacks is that someone now needs to configure yet another piece of software on the server. It’s true that the configuration process consumes less time than having developers code for each of the microservices, but it’s only true when things work precisely as they should.

Another issue is that using a microservices API gateway creates an additional failure point. You may encounter scenarios where a configuration error causes an application bug that’s truly horrid to find. The server on which the microservices API gateway runs could also crash or the application could simply find it difficult to communicate with the server for some reason. In fact, the microservices API gateway could fail in all sorts of ways that add to reliability problems, rather than making things better.

The Bottom Line

Using a microservices API gateway makes everyone more efficient and speeds data transfers along as well. However, in order to obtain these benefits, the server you use needs to support non-blocking asynchronous I/O. Otherwise, both speed and scalability suffer and your microservices API gateway will become a choke point.

Because of the way microservices API gateways work, you need to write your application in a declarative style using a reactive approach. Products such as Promise make this approach possible for JavaScript developers and there are other products for other languages. Using a declarative style makes it possible for the microservices API gateway to decide how to fulfill requests and reduces the client workload. Consequently, when a request requires several concurrent calls, the microservices API gateway can perform them all at once. Likewise, when the microservices API gateway must first authenticate the user before making a microservices request, it can do so without querying the client.

Microservice locations are also dynamically assigned in most cases, so any microservices API gateway you use should provide the means for discovering microservices as needed. As microservices autoscale or developers upgrade them, the microservices API gateway must automatically make adjustments to ensure applications continue to run as if nothing has happened. In general, the microservices API gateway locates microservices using the services registry.

A final consideration is that the microservices API gateway must be able to handle partial failures. A single unresponsive microservice shouldn’t cause the entire request to fail. A microservices API gateway can handle such partial failures using a number of approaches:

Provide an empty value

Rely on a hardwired top ten value

Use cached data from a previous call

Return an error code for time critical data that is the main focus of the request