The demands of modern businesses, especially around scalability, velocity, and agility, underpin the reasons that microservice architectures are replacing monolithic applications.
The accelerated rate of microservices adoption, coupled with the continuing increase in commercial API integrations, gave birth to a new set of needs related to an organization's API architecture. The concept of an APl gateway was created to address these needs.
Let's take a closer look into what an APl gateway is and what purpose it serves in a microservices architecture, as well as some tips and tricks to keep in mind when implementing one.
What is an API gateway and how is it different from a reverse proxy?
An API gateway is deployed at the edge of your infrastructure and acts as a single entry point that routes client API requests to your backend microservices. At its core, an API gateway is a reverse proxy receiving incoming user requests and directing them to the appropriate service. The diagram below illustrates where the API gateway lives in a microservices architecture.
Although an API gateway includes many of the functions that you find in a typical reverse proxy (e.g., request routing, load balancing, caching, etc.), it also offers a unique set of additional features and functions. The API gateway provides custom APIs tailored to each service, encapsulating the internal architecture.
The primary difference between an API gateway and a reverse proxy is the ability to address cross-cutting, or system-wide, concerns. A concern is a part of the system's architecture that has been branched based on its functionality. A cross-cutting concern is a concern that is shared among a number of different system components or APIs. Here are a few examples of cross-cutting concerns:
- Configuration management
- Exception management
API gateways come with a set of features that are specifically designed to address these cross-cutting concerns.
What are the key features of an API gateway?
There is a core feature set developers expect from an API gateway, focused around four main pillars:
- Authentication and authorization
- Traffic management
- Traffic observability
Some solutions also offer feature sets designed for API acceleration and team collaboration. The list below summarizes the features you most commonly find in API gateway solutions.
- HTTP, HTTP/2, TCP, UDP, WebSockets, gRPC
- Protocol translation and management
Authentication & Authorization
- LDAP authentication
- JWT authentication
- oAuth2 authentication
- OpenID Connect (OIDC)
- HMAC authentication
- Traffic mirroring
- Blue / Green & Canary deployments
- Active health checks
- Middleware (circuit breakers, retries, buffering, etc.)
- Distributed In-flight request limiting
- Distributed rate limiting
API Traffic Observability
- Cluster-wide dashboard
- Distributed tracing (Jaeger, Open Tracing, Zipkin)
- Support for third-party monitoring platforms (Datadog, Grafana, InfluxDB, Prometheus, etc.)
- GitOps workflows integration
- Developer portal with OpenAPI support
The benefits of an API gateway and why your microservices need one
The feature sets seen earlier go beyond addressing simple cross-cutting concerns that a reverse proxy wouldn't normally be able to handle. By centralizing processes and configuration, API gateways address the most common microservices issues — security and availability. Features like SSL and authentication and authorization overcome security issues in microservices architectures, while features like rate limiting, retry, and circuit breaker ensure availability for applications and services.
Implementing an API gateway for your microservices comes with a number of benefits:
- Expose and connect your services from the moment they're deployed, using any protocol, and automatically encrypt communications with TLS.
- Instantly and consistently secure APIs by offloading the complexity of authentication and authorization to the API gateway.
- Support enterprise application deployment at scale using advanced traffic management.
- Troubleshoot fast and gain better insights into the health of your microservices using real-time metrics and analytics.
- Use embedded caching to improve API response time.
- Use embedded developer portals to document your APIs.
- Monetize APIs with the help of an API gateway.
Things to consider when implementing an API gateway
API gateways benefit most microservices-based applications, but implementing one comes with a few notes of caution.
Don’t let an API gateway solution drive your architecture
With the rich set of capabilities offered in API gateways, it’s tempting to deploy features and configurations before they’re actually needed. An API gateway can serve an environment with 10, 100, or 1,000 microservices; however, depending on the size of the application, you don't always need to use the entire feature set. API gateway solutions should be used to help and improve your microservices architecture, not drive it.
Before you start adding authentication rules to every route or creating credentials and adding traceability for everything, take a step back and assess if the current state of your application really needs these functions. If you prematurely implement steps and configurations, you overflow the system with information of little value.
Just because the product can do something doesn't mean you need to use the feature. Most API gateways offer a common set of enabling features and a smaller set of niche features. Building your app around the niche features unnecessarily complicates the application.
Diligent logs and metrics can save you a lot of trouble
The impact on performance is a major concern when introducing an API gateway to the application architecture or to your team. One recurrent problem is the tendency to put the blame for any issues on the tool, especially when dealing with slow response time or request errors. This is why keeping metrics and logs is essential. If performance issues arise following the implementation of an API gateway, make sure your first priority is to properly analyze logs and metrics for the APIs themselves before moving on.
Don’t overlook API governance
Technical tools often provide everything you need to manage users and their rights over APIs, policies, etc, but the internal team and company organization is still crucial. And API governance is an integral part of the team and company organization. Lifecycles, intra and inter-organization of integrations, visibility, and security are only a few of the responsibilities under API governance.
Internally promote the adoption of an API gateway
Powerful tools like an API gateway are not always easily handled by teams. API gateways often add complexity to architectures with new behaviors, new processes, new questions, etc. This makes troubleshooting a bit more complicated.
Simply adding an API gateway in the current architecture is not enough — it's necessary to onboard teams and raise their awareness on new concepts. Providing training and helping manage the impact of change is key to a successful adoption process.
As microservices replace monolithic applications, the need for API gateway solutions will only increase. Investing in the right solution is one of the most important factors for a successful microservices adoption process.
API gateway features successfully address the most common issues of microservices architectures but come with the risk of creating bottlenecks. Properly identifying the problems you want to solve, as well as the appropriate features that will help you achieve that, is important for a smooth implementation and use of an API gateway.
References and further reading
- Reverse Proxy Explained: How It Works And When You Need One
- Traefik API Gateway for Microservices
- Unlock the power of API Gateways in your Enterprise
- Getting Started with Traefik and the New Kubernetes Gateway API
- Kubernetes Ingress & Service API Demystified
- Using an API Gateway for Authorization and Authentication
- Eliminate Common API Gateway Challenges in Amazon ECS
- Acing Cloud Networking with Traefik Enterprise