API Gateway to the Rescue

In non-technical terms, "a gateway or a gate is a point of entry to space which is enclosed by walls." Similarly, a gateway in software terminology acts as an entry point to your servers sitting inside a firewall or intranet. In the microservices world, a gateway sits in front of your APIs that are facing clients and acts as a reverse proxy. 

Increasingly, many applications are migrating from monolithic to microservices architectures. API gateways have become one of the key components in the microservices architecture pattern. Note that this article is not about any particular gateway but instead talks about general features of any gateway.

A Gateway as a Proxy

Before understanding gateways and their responsibilities, let's first look at how a proxy works. A proxy server acts as a bridge which makes internal networks invisible to the internet. There are two types of proxy servers: a forward proxy and a reverse proxy.

A forward proxy is internet facing and retrieves data from the internet. A reverse proxy, on the other hand, sits in the internal network and accepts requests from the internet and forwards them to your servers in the internal network. A gateway is a reverse proxy pattern which protects access to your servers on the private network though they are not mutually exclusive.

API Gateway Pattern and Its Many Hats

There are many features of an API gateway, so let's take a deep dive to understand the responsibilities of a gateway.

Security

You might think that you have set up security layers to your architecture like encrypting requests with HTTPS. I have set up a firewall for my private network. I have added authentication to my requests, etc., but there are additional security aspects which your gateway manages and helps in negotiating requests from the client.

CORS

A gateway can come to the rescue by implementing CORS (Cross-Origin Resource Sharing) filters and having the capability of handling Cross-Origin requests.

CORS is a mechanism which enables cross-domain requests and allows restricted resources. Based on the origin URL reported by the browser, most gateways intercept incoming HTTP requests and identify whether they are cross-origin and apply the required headers before forwarding the requests to the cross-origin resources.

DDoS and SQL Injection

Since all the traffic is routed through the gateway, there is an added advantage that insecure requests are filtered out. Many gateways are good at sanitizing inputs to common threats like SQL injection.

Gateways provide a defensive mechanism in identifying DDoS (Distributed Denial of Service) attacks like requests are being bombarded onto your servers and prevent disruption to your core services.

You can have different layers of protection. For example, AWS provides a service, AWS Shield, to identify usage spikes before even it reaches your gateway or ELB. But gateways are one such layer where you can leverage its features to prevent attacks.

Authorization and Authentication

Since gateways are entry points to your requests, it is always a better place to authorize and authenticate your end users. This helps in keeping your backend services intact without even the request reaching the business layers. 

The best way to manage authorization and authentication at an API gateway is to use OAuth and establish a handshake.

Certificate Management

API gateways can manage certificates using their own keyStore and trustStore. Many commercial gateways have a provision to create/import certs into stores and enforce SSL between the client and the gateway.

If you have an API gateway as the entry point to your backend services, one of the best practices is to use SSL between your gateway and the backend services. Since the Gateway and your backend services are in the internal network, you wouldn’t need an extra layer of security other than SSL (in fact, you could terminate SSL within an inter DMZ). This should be backed by a strong layer of security between the clients and the gateway.

You could even do an SSL termination at the load balancer after the traffic reaches the gateway if you have a large scale distributed cluster for efficient performance.

API Control and Governance

Request Throttling and Quota

There can be many channels that your API requests come from and you may want to rate limit or throttle the requests based on your service agreement with the channel or client. Initially, you make service-level agreements (SLA) with your channels or clients to ensure that you meet their expectations and define the circumstances that they will not meet any outages. You can agree to non-functional requirements (NFR), which you get it from your channels well ahead for service usage agreements.

Also, this will help in segregating your channels and charge them accordingly based on the transactions or NFR you agreed upon. For example, you may get a high volume of requests from a mobile channel and you can surge the TPS based on incoming traffic and keep a note of what volume of transactions could be charged. This way, API monetization can be done specifically with clients.

Quota management, with which you can configure the maximum number of requests that can be submitted within a specified time interval, is also possible. This is usually called quota limit and is very useful in the above-mentioned cases of service agreements with your clients.

So, what other things can be governed by a gateway? Since all the requests flow through the gateway, you can asynchronously log all your transactions at the entry point and trace later on for auditing purposes to meet compliance requirements.

Thus API gateway eases the burden of managing client requirements from the functional layer of your application.  

Monitoring 

Although there are many APM tools which you can plugin to your applications, gateways can also provide real-time API monitoring so that it can be analyzed for usage trends.

API Hosting

So, how does a gateway know which API it should accept requests from and which one to reject? This is where we can host/onboard APIs into a gateway, configure request parameters, apply routing policies if required, append additional headers, etc. 

As we discussed earlier, you may have multiple channels where the requests flow into your applications but not all channels require all APIs to access. In this scenario of API governance, you can configure client specific requirements and route traffic to only those APIs which the client is intended to access. By default, you can impose a deny all policy at your gateway and whitelist those APIs which are on-boarded in advance.

Orchestration

You may want to interact with different APIs from different microservices and then aggregate the information. You can write implement this logic in a gateway by offloading orchestration of composite services. But this is not a recommended way as this makes API Gateway and your application tightly coupled given that you may get rid of the gateway anytime you want.

Request Response Filtering

Why do you want to filter the response in a gateway and rather than in your application, like a servlet filter in Java? Let's consider an example.

Let's say you want to maintain generic microservices which serve different geographies with global APIs being accessed from different parts of the world and consumed by different channels. Every time you send a response to a channel/client, you send the unwanted piece of information which may not be required for that channel at all. This is where we can use a gateway's functionality, filter responses, and send only what is required for that particular channel. Note: This can additional latency for profiling responses by doing an additional lookup on the channel to response mapping.

Types of Gateways

The wide adoption of APIs led to the emergence of off-the-shelf API management products, open source projects, and SaaS offerings.

What Gateway Do You Choose for Your Application?

It depends on whether you want to set up an API Management platform by using various commercial tools. Many commercial SaaS products like Apigee (now owned by Google), Axway, App42, and Azure offer rich features with extensive support bundled with management software. It all depends on how you design your system and fit it into a microservices architecture. But when choosing a gateway, think of the factors like scalability, high availability, and elasticity, as we are in the cloud world, after all.

How About Open Source Gateways?

Few open source gateways, like APIUmbrella, Gravitee, etc., also provide the flexibility of API management. If you are in the Java/Spring world, you can choose to work with edge servers like Netflix Zuul or Spring Cloud Gateway which you can customize to add more features than are available with a commercial gateway. The advantage of these gateways is that they can scale horizontally in tandem with your app servers, providing a distributed nature across containers.

Cloud Native Gateways and Gateways in the PaaS World

AWS and a lot of other cloud vendors provision API gateways provided that your application is cloud native and cloud-ready. API gateways like Ambassador, Kong, Express Gateway for Node.js, and numerous others operate on cloud-native features of the Docker, and K8s integrations. 

Finally, every commercial/open source gateway markets themselves and if you find a good feature I would say it's better to not reinvent the wheel but utilize its features and customize it to your specific requirement.

Gateway Scalability

Availability and horizontal scalability can be achieved by deploying multiple API Gateways on multiple hosts and load balancing across them using a standard load balancer. This also depends on what type of gateways you deploy in front of your application servers.  For example, if you use Netflix Zuul as a reverse proxy and deploy it as a Spring Boot application, you can horizontally scale as many as you need. Since there is no session data at gateways, you don't even need to replicate sessions.

Another common practice is to set up CDNs like Akamai or AWS CloudFront as static content caching layers in front of your gateways.

Gateway Anti-Patterns

We have talked a lot about API gateways and their characteristics, now let's look at some gateway anti-patterns.

• Make sure your API Gateway is not the single point of failure. 

• No matter how good you design your application, there are chances of tight coupling with API gateways.

• Gateways add additional latencies to your end-to-end response times.

• Front tier bottlenecks

• Gateways add additional operational overhead and set up cost if you do not choose wisely.

Ending Notes

Be it commercial, open source, or cloud-friendly, a gateway is good to have as a feature/layer, provided you choose and implement the right one for your application. Most of the features described above are provided by commercial gateways, but I think you can figure out and achieve all of these by customizing them to your own requirements. Start exploring gateways by keeping security, governance, and scalability in mind. Thanks for reading!