The Role of APIs in a Microservices Architecture

This article is featured in the new DZone Guide to API Management: Comparative Views of Real World Design. Get your free copy for more insightful articles, industry statistics, and more!

To meet the ever-increasing demands of business innovation, organizations are steadily moving towards adopting microservices architectures in their enterprise software. While a microservices architecture provides you with the agility required to develop, maintain, and enhance your software at scale, it doesn’t come for free. There are many challenges and hurdles to overcome when applying these architecture patterns and practices. One such challenge is to understand the importance of APIs and API Management in a microservices architecture. To understand the problem better, let us look at the microservices architecture of a retail application.

Figure 1 — Microservices architecture of a retail application.

Here, we have individual microservices for operations such as browsing the product catalog, placing orders, updating inventories, and shipping items to clients. At first glance, you would realize that there is a lot of chaos in terms of the number of components in action and when it comes to the integration in between these components to facilitate business requirements. Some of the key problems in this architecture are:

1. Too many microservices for the client application to deal with. The nonuniformity across these microservices interfaces, their rawness, and varying authentication schemes would make the consumption of these microservices nontrivial.

2. Policy enforcement on factors such as rate limiting and access control becomes a challenge due to the non-existence of an enforcement point.

3. Business value reporting becomes harder since

4. Inter-microservice point-to-point communication becomes a challenge due to the continuously deployed nature of microservices.

Managed Exposure of the Microservices to Consumer Applications

Uniform Exposure for Comprehensiveness

Each of the individual microservices in Figure 1 could be developed by independent engineering teams. They may have freedom of choice to use their own programming languages, use their own standards, and to release at their convenience. In such situations, it is highly likely each of the microservices would have different interface standards and patterns. This lack of uniformity makes it harder for its consumers to use these services effectively, reducing developer efficiency. Exposing them through a managed infrastructure such as an API Management solution provides an organization with ways of ensuring the APIs exposed for consumer applications are standardized, well documented, and discoverable on developer portals.

API Façade

There are many cases in which the rawness of the microservices should not be exposed to its consumers. For example, an operation that performs a read on your product catalogue and an operation that performs an update may be developed as individual microservices to cater to different scalability needs. But, the consumers of these operations would like to see them both in a single API since they perform operations on a single entity (products). This makes it necessary to have a single API consisting of two resources (functions) that expose both microservices.

Security

Each of the microservices above may require different levels of authentication and authorization such as OAuth2.0, certificates, mTLS (mutual transport level security), etc. These may apply on communication channels between consumer applications and microservices or on inter-microservice communication channels as well. This makes it harder for applications to consume your microservices as well as making it harder for programming inter-microservice communications. This problem can be solved by using an API Gateway capable of exposing a uniform security mechanism to its consumers and translating them to whatever the necessary internal security protocols are. For example, exposing OAuth 2.0-based security for consumer applications while using mTLS to communicate with internal microservices.

The Microgateway Pattern

As discussed in the section above, the use of an API gateway in an API Management solution helps us to solve most problems related to exposing our microservices to consumer applications. One key factor to keep in mind here is that the main reason an organization adopts microservices is because of the agility they provide in terms of development, testing, deployment, and scaling applications. As businesses keep innovating, they will end up with more microservices and more integrations between them. This will only result in us seeing more APIs, which raises a question on our API Gateway architecture. Just like microservices, this situation demands our API gateways be agile in terms of development, testing, deployment, and scalability. Instead of hosting the runtime of all our APIs on a single monolith gateway, this situation demands the capability of deploying each individual API or smaller subsets of APIs on individual Microgateways.

Figure 2 — A microservices architecture influenced by microgateways.

Some key characteristics of Microgateways in order to meet these criteria are described below.

Designed to Scale

The ability to scale easily to meet rising demand is a critically important factor for a Microgateway. As such, it is important that the Microgateway does not connect to any other systems at runtime so that it can scale without resistance.

CI/CD Readiness

The creation, deployment, and spinning down of Microgatewaysshould be as trivial as possible. These processes should be automated in their entirety, meaning that they should entertain CLI-like tools or administrative APIs so that these processes can be performed by automation tools such as Jenkins during their build or deployment phases.

Container Readiness

Many of today’s software following microservices standards are being deployed on containers and container orchestration systems for the range of benefits they offer. As such, the gateways that become the entry point into the services offered by this software should bear characteristics that make them easy to deploy on Containers. Some of these are

• Small distribution size (100 MB)

• Low resource consumption and fast boot-up (256 MB, 1second boot up)

• Configurable via environment variables

• Build processes that generate container images and deployment artifacts, and the ability to automate them

Immutability

Microservices architectures demand scalability and automated recovery. This makes the predictability of software very important so that we guarantee that we deploy and scale the exact artifact we have tested. A given Microgateway runtime needs to be built once with its APIs and policies so that we guarantee its replicas are identical.

Conclusion

As organizations steadily embrace microservices and as businesses keep on innovating, we are looking at a future where the number of APIs being used within and exposed out of an organization are due for a rapid increase. In such a landscape, it is important for us to have scalable mechanisms for the development, deployment, and management of these APIs. The management of these APIs is going to be a lot more than management of API proxies. Being able to compose integrated/composite microservices, expose them as Microgateways, and manage them via API Management systems efficiently are going to play a critical role on how agile and competitive an organization can be. Gearing up for this growth should definitely be in your plans!

This article is featured in the new DZone Guide to API Management: Comparative Views of Real World Design. Get your free copy for more insightful articles, industry statistics, and more!