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.
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.
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
· Ready! API
· Delving into the Microservices Architecture
· Martin Fowler on Microservices
· Microservices at InfoQ
· The Great Microservices vs Monolithic Apps Twitter Melee
· Microservices and PaaS