Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Why Do Microservices Need an API Gateway?

DZone's Guide to

Why Do Microservices Need an API Gateway?

With the growth of API-centric IT initiatives, API gateways and management layers are common place. Should we consider an API gateway for microservices?

Free Resource

Modernize your application architectures with microservices and APIs with best practices from this free virtual summit series. Brought to you in partnership with CA Technologies.

With the growth of API as a product, as well as API-centric IT initiatives, API gateways and management layers are becoming more common place. However, should we consider an API gateway for our microservices, as well? If so, what kind of benefits do they offer?

What Is an API Gateway?

An API gateway provides a single, unified API entry point across one or more internal APIs. They typically layer rate limiting and security, as well. An API management layer such as Tyk.io adds additional capabilities such as analytics, monetization, and lifecycle management.

A microservice-based architecture may have from 10 to 100 or more services. An API gateway can help provide a unified entry point for external consumers, independent of the number and composition of internal microservices.

The Benefits of an API Gateway For Microservices

Prevents Exposing Internal Concerns to External Clients

An API gateway separates external public APIs from internal microservice APIs, allowing for microservices to be added and boundaries changed. The result is the ability to refactor and right-size microservices over time without negatively impacting externally-bound clients. It also hides service discovery and versioning details from the client by providing a single point of entry for all of your microservices.

Adds an Additional Layer of Security to Your Microservices

API gateways help to prevent malicious attacks by providing an additional layer of protection from attack vectors such as SQL Injection, XML Parser exploits, and denial-of-service (DoS) attacks.

Enables Support for Mixing Communication Protocols

While external-facing APIs commonly offer an HTTP or REST-based API, internal microservices may benefit from using different communication protocols. Protocols may include ProtoBuf or AMQP, or perhaps system integration with SOAP, JSON-RPC, or XML-RPC. An API gateway can provide an external, unified REST-based API across these various protocols, allowing teams to choose what best fits the internal architecture.

Decreased Microservice Complexity

Microservices have common concerns, such as authorization using API tokens, access control enforcement, and rate limiting. Each of these concerns can add more time to the development of microservices by requiring that each service implements them. An API gateway will remove these concerns from your code, allowing your microservices to focus on the task at hand.

Microservice Mocking and Virtualization

By separating microservice APIs from the external API, you can mock or virtualize your services to validate design requirements or assist in integration testing.

The Drawbacks of an Microservice API Gateway

While there are many benefits to using an API microservice gateway, there are some downsides:

  • Your deployment architecture will require more orchestration and management with the addition of an API gateway.
  • Configuration of the routing logic must be managed during deployment, to ensure proper routing from the external API to the proper microservice.
  • Unless properly architected for high availability and scale, an API gateway can become a limiting factor and even a single point of failure.

The Integration Zone is proudly sponsored by CA Technologies. Learn from expert microservices and API presentations at the Modernizing Application Architectures Virtual Summit Series.

Topics:
api ,microservices ,api gateway ,integration

Published at DZone with permission of James Higginbotham, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}