DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
The Latest "Software Integration: The Intersection of APIs, Microservices, and Cloud-Based Systems" Trend Report
Get the report
  1. DZone
  2. Data Engineering
  3. Databases
  4. The Role of APIs in a Microservices Architecture

The Role of APIs in a Microservices Architecture

Learn how APIs help to bring a sense of order into the chaotic nature of a microservices architecture.

Nuwan Dias user avatar by
Nuwan Dias
CORE ·
Sep. 01, 18 · Opinion
Like (24)
Save
Tweet
Share
16.93K Views

Join the DZone community and get the full member experience.

Join For Free

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.

Image title

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.

Image title

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!

microservice Architecture application API consumer

Published at DZone with permission of Nuwan Dias. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Custom Validators in Quarkus
  • What Is API-First?
  • Best Navicat Alternative for Windows
  • Isolating Noisy Neighbors in Distributed Systems: The Power of Shuffle-Sharding

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: