The Truth About API Management in a Microservice Architecture
In this post, I won’t be raving about how microservices have revolutionized software application architecture (they have!) simply because it has been done ad-nauseam for the past couple of years. Despite their drawbacks — complexity being the biggest of them — microservices are usually a good choice for consumer-driven rapid application development with shorter time to production and ability for faster innovation. To learn about microservices and what they can do for your organization I suggest you start reading here. At the same time, API management existed way before the rise of microservices as a popular and effective mechanism for organizations to manage non-micro REST APIs and SOAP services, and their API-driven businesses. API management entails designing, publishing, documenting and analyzing APIs in a secure environment. So how exactly does API Management fit into a Microservice Architecture (MSA)? Is there any value in API Managers in the world of microservices?
The API Gateway: The Friend
Before we talk about API management in a MSA, let’s discuss the API Gateway pattern (it’s important not to confuse an API gateway with API management), and before we do that, let’s understand how client applications (web/mobile apps) communicate with microservices.
Microservices are fine-grained APIs, which means that client applications need to interact with multiple services if the clients talk to the microservices directly via mechanisms such as HTTP-based REST, Thrift or gRPC (for synchronous request/response-based communication). Known as direct client-to-microservice communication, this approach will produce considerable problems such as the following:
- Introduce the point-to-point spaghetti mess SOA tried to eliminate with the use of an Enterprise Service Bus.
- If there are mismatches between the needs of the client and the fine‑grained APIs exposed by each of the microservices, the client will have to make several calls to get what it needs. In a complex application, this could mean hundreds of service calls.
- Consuming services via non-uniform interfaces and protocols.
- Refactoring the microservices will be challenging if clients communicate with the services directly.
Because of these kinds of problems, it rarely makes sense for clients to talk to microservices directly. When designing and building large or complex microservice-based applications, adopting the API Gateway pattern is a good approach. Implementing an API Gateway as the single entry point for all clients will address the issues faced in direct client-to-microservice communication. All requests from clients first go through well-defined APIs in a lightweight message gateway (aka API Gateway). The gateway is mainly responsible for request routing, composition, and protocol translation. The API Gateway APIs will often handle a request by invoking multiple microservices and aggregating the results.
Fundamentally, an API Gateway provides for easy developer consumption of microservices as managed APIs and is usually a part of an API Management offering.
An API management platform should provide ways to on-board and manage developers, create an API catalog and documentation, generate API usage reporting, productize or monetize APIs, and enforce throttling, caching, and other security and reliability precautions. The API Manager provides the tools, control, and visibility to scale microservices via APIs to new developers and connect them to new systems .
WSO2 API Manager: Not Just Another Open Source API Management Solution
The WSO2 API Manager, recently named as a leader in the Forrester Wave™: API Management Solutions, Q4 2018 Report, is an open source API management solution which provides an API gateway with support for API creation, publication, lifecycle management, versioning, monetization, governance, security, rate limiting and analytics using proven WSO2 technology. It provides web interfaces for development teams to deploy and monitor APIs, and for consumers to subscribe to, discover and consume APIs through a user-friendly store front. The API Manager consists of several components: API Gateway, Key Manager, Traffic Manager, Publisher portal, Developer portal (store) and Analytics. Depending on the use case and traffic volumes, these components can be deployed in a single runtime or as separate runtimes.
Microservices can be directly exposed to client applications via the WSO2 API Manager Gateway. Security can be handled via the gateway using a combination of OAuth2/OIDC at the edge and sending information to the microservices via JWT. The Key Manager is responsible for issuing and validating all security tokens. The WSO2 API Manager will also provide other API Management capabilities such as documentation, service discovery via the store and analytics for the exposed APIs. The WSO2 API Manager can be deployed as the API Gateway as shown in the figure below. The WSO2 API Analytics profile is deployed as a separate runtime.
At the same time, The WSO2 API Manager also provides the ability to deploy decentralized gateways, known as microgateways, instead of a single monolithic gateway. Decentralized gateways are useful when it comes to scaling. The WSO2 API Microgateway is an immutable, ephemeral and lightweight API Gateway for APIs and is used for message security, transport security, routing, and other common API Management services. A single independent microgateway can front a single microservice or a subset of microservices. The WSO2 Microgateway is designed to scale, where it does not require any mandatory connections to other components, such as the Key Manager, Analytics, Traffic Manager etc. as it is done with the standard monolithic WSO2 API Manager. This way it can be made to scale easily without having to worry about scaling other components. This is achieved through self-validating tokens, localized rate limiting, offline analytics and immutability. The microgateway has native support for Docker and Kubernetes.
Benefits of API Management
And this is why everyone is talking about API Management in a MSA. Adopting the API gateway pattern via an API Management solution makes life tremendously easier for client developers and microservices teams due to the reasons listed below:
Simplification of Client Code
Rather than having to invoke specific services, clients simply talk to the gateway because it provides the required abstractions. Client apps will only need to know the address of the gateway because the gateway will be responsible for routing the requests to the relevant microservices. It can even perform lightweight transformations. Even if these services are created using different technologies and are exposed via non-uniform interfaces and protocols, the API Gateway will expose all the heterogeneous microservices in a standard way and can also expose different APIs for different client types. The Developer Portal/Store component of the WSO2 API Manager is a web application, which provides a collaborative interface for API publishers to host and advertise their APIs and for API consumers to self register, discover, evaluate, subscribe to and use secured APIs.
Security and Access Control
Even though microservices should focus on the business logic, authentication and security can be implemented in the service level as well. However, doing so will duplicate the functionality and increase maintainability issues such as changing and redeploying the microservice every time the security requirement/protocol changes as opposed to handling it centrally. Having an API Gateway will enforce standard authentication and security across all the microservices. Also, a microservice may have its own security requirements depending on its functionality. For example, in an application, third parties should only be able to access some microservices and not all of them. If a service is exposed externally, to authenticate and authorize end user applications and users, OAuth2 or OpenID Connect protocols can be used. In contrast to having just a couple of ports opened as entry points in a monolithic application, an MSA can have as many as hundreds of entry points. Even though all of them are not exposed externally, there is a broader attack surface to secure, making securing service-to-service communication vital. A signed self-contained access token such as JWT can be used to pass end-user details and service context to check what each user can do with a microservice. Mutual Transport Layer Security (TLS) can be leveraged to allow trusted internal communications. The Key Manager component of the WSO2 API Manager manages all clients, security and access token-related operations. The Gateway connects with the Key Manager to check the validity of security tokens, subscriptions and API invocations. The Key Manager can also seamlessly secure the back-end microservices by behaving as the Security Token Service (STS), which can issue and validate JWT tokens.
Rate Limiting
Overloading microservices with large volumes of requests will lead to an unresponsive application. The API gateway should perform rate limiting by allowing a maximum number of requests, that could be handled by a microservice, and blocking subsequent requests for a given period of time. Policies for rate limiting can be defined globally for all APIs or on a per‑API basis. The WSO2 API Manager provides a Traffic Manager which helps users to regulate API traffic, make APIs and applications available to consumers at different service levels, and secure APIs against attacks. The Traffic Manager features a dynamic throttling engine to process throttling policies in real-time, including rate limiting of API requests.
Analytics and Business Insight
There are many frameworks available for developing microservices. Most of them have good support for integrating with observability tools which are mostly capable of reporting operational analytics such as resource usage, latency, memory usage etc. They all fall under the umbrella of operational analytics. However, business information or KPIs — such as the number of calls for each API, logins, popular products etc. — can be derived from the gateway layer. The gateway is an integral part of learning customer needs and discovering trends through analysis. The Analytics component of the WSO2 API Manager provides reports, statistics and graphs on the APIs deployed in the WSO2 API Manager. Alerts can be configured to monitor these APIs and detect unusual activity, manage locations via geolocation statistics and carry out a detailed analysis of the logs.
Service Discovery
In order to make a request, the client needs to know the network location (IP address and port) of a service instance. However, this is a much more difficult problem to solve because in an MSA, service instances have dynamic IP addresses because of autoscaling, failures, and upgrades. Consequently, the client code needs to use a more elaborate service discovery mechanism to determine the network locations of available service instances and load-balance requests across them. The client application can offload this task to the API Gateway to use registry services like etcd or Consul, or discovery mechanisms assumed by orchestration engines such as Kubernetes or service mesh software such as Istio. Meanwhile, the API Gateway can expose static service names to the client and the client code will remain unaffected despite the dynamic changes. The WSO2 API Manager provides a developer portal (store) for the client application developers to discover the APIs exposed in the gateway. The API store provides a collaborative interface for API publishers to host and advertise their APIs and for API consumers to self register, discover, evaluate, subscribe to and use secured, protected, authenticated APIs.
Transitioning from a Monolith to a Microservice Architecture
Another advantage of introducing a gateway to a microservice architecture is the ability to smoothly and continuously move from a monolith app to an MSA. Imagine the task of rewriting a large monolith application from scratch. It’s a massive effort and has a good amount of risk associated with it. Also, rewriting the monolith from scratch prevents users from using the new system until it is complete. There’s a lot of uncertainty involved until the new system is developed and functioning as expected. Consequently, there will be minimal enhancements or new features delivered on the current platform, so the business will have to wait to have any new features developed and released. This task will, most likely than not, have to be phased out. Known as the Strangler Pattern, this is a design pattern to incrementally transform the monolith into microservices by replacing a particular functionality with a new service. To make the client applications agnostic to such frequent changes, introduce an API gateway as the Strangler Facade. As the Strangler Facade, the API gateway will act as a proxy layer with static or well-defined interfaces corresponding to the back-end microservices. The subsequent changes in the microservices will not affect the client apps as they will only deal with the API Gateway layer. This is another advantage of having an API Gateway.
I would love to take this one step further and add how the API Gateway complements the Service Mesh architecture into the list, but it warrants an article of its own. Read more about the differences between an API Gateway and a Service Mesh here.
In conclusion, API Management offers multiple complementary benefits to an MSA which allow organizations to harness the full power of microservices by controlling security and access to microservices, and the truth of the matter is, API Management is really nothing short of essential in a Microservices Architecture.
