Gateway Pattern Relationships and Other Names
The microservice Gateway pattern often goes by other names, including API Gateway pattern and Gateway Offloading Pattern.
As the Gateway Pattern is a proxy (or more properly a reverse proxy as it sits on the server side of a request), it is close cousins to the BFF pattern , the Ambassador pattern, and the Strangler pattern.
The Gateway Pattern shares many of the “Dos and Don’ts” of these closely patterns.
Gateway Pattern Overview
We use the term Gateway as a metaphor for the entrance to and exit from your request/response system whether your solution is initiating a request or it is responding to a request. Think of the Gateway as the embarkation/disembarkation point for all traffic to/from your services. Metaphorically, it is the single point (gate) through which all traffic flows in a medieval keep or castle.
The Gateway pattern in microservices is the software equivalent of a gateway in a network segment of any size; anything coming in or out of that network segment does so most commonly through a single point. That point is often a firewall or router. In your home, it’s likely you cable modem.
The purpose of the Gateway is to offload common shared services needed for all traffic. These services or functions may consist of one of the following and potentially many others:
- Authentication and Authorization (AuthN and AuthZ)
- Security/access monitoring
- Usage monitoring overall of the site/product (e.g. logging)
- SSL termination and offloading
- Common certificate management (SSL and others)
- Throttling (as in rate-limiting activity or validating usage is consistent with contract/pricing)
As you can see with the partial list above, anything that can be shared for the purposes of simplifying solutions and reducing overall costs becomes a candidate for the Gateway pattern. But as we will explain below, be careful to not overload this proxy (reverse proxy) with too much capability.
Benefits of the Gateway
As you can see with the partial list above, anything that can be shared for the purposes of simplifying solutions and reducing overall costs becomes a candidate for the Gateway pattern. But as we will explain below, be careful to not overload this proxy (reverse proxy) with too much capability.
The Gateway pattern comes with many benefits. Many are shared with the Ambassador (another proxy service), but some are unique to the types of solutions for which Gateway is intended. Shared indicates benefits Gateway shares with Ambassador, while unique indicates a benefit only Gateway has:
- Unique: Gateway is focused on infrastructure or software-infrastructure related elements including SSL termination/offloading, AuthN, AuthZ, tokenization, etc.
- Unique: Engenders lower cost implementations, as common “platform” like capabilities converge into single solution sets. Individual teams need not find their own approaches to terminating SSL, handling authentication/authorization, etc. Duplication of work is minimized.
- Shared: Enables multiple languages (polyglot) and skillsets for development teams. Teams that operate in multiple talent markets or that find it difficult to hire lower level infrastructure developers and higher level application developers may find it easier to source talent in multiple markets.
- Shared: Conceptually easy interactions between components, typically consistent with interactions between all other services.
- Shared: Allows for ownership by individual teams and as such engenders organizational scalability of larger teams.
- Shared: Allows for independent release by teams of various shared usage components. As calling or called services change, the ambassador can change without modifying the service for which it is an ambassador (near where it sits).
Drawbacks to Gateway
- Shared: Violation of service calls in series anti-pattern. But for many requests, the functions necessary to terminate SSL, perform AuthZ/AuthN would need to exist “somewhere” anyway. Most likely this would be in either a hardware device (a load balancer like F5) or in a software context switch (NGINX or the like). As such, we don’t consider most Gateway implementations a violation.
- Unique: Over usage or over burdening of the Gateway pattern. Many teams that adopt a Gateway pattern will begin to add too much functionality to their implementation. Early on these burdensome additions are lightweight solutions like common personalization services or greeting services. Later, as the Gateway approaches monolithic proportions, databases and real-time analytics solutions may be added. To avoid these, try to keep to lightweight shared “infrastructure-like” solutions.
- Unique: Poor build v buy solutions. You’d be surprised how many times we see clients developing bespoke Gateways from scratch, including their own webserver implementations. Unless you are providing software infrastructure as your business, please stay away from this and adopt open source solutions or purchase proprietary Gateways that you can extend.
Note: Because some solution needs to proxy (reverse proxy) communication between you and your customer for the purposes of load balancing to achieve (at the very least) X Axis scalability, we do NOT consider most Gateway implementations as a Fan Out Anti-pattern.
When to Use Gateway Pattern
Gateways are great for common components that every service needs and which must be present at the beginning of any interaction. The purpose of using a Gateway is to decrease cost of maintenance, decrease deployment cost, decrease risk and cost of duplication of effort and to allow for specialization within teams without breaking the notion and benefit of empowerment. As indicated above, common implementations include:
- Authentication and Authorization (AuthN and AuthZ)
- Security/access monitoring
- Usage monitoring overall of the site/product (e.g. logging)
- SSL termination and offloading
- Common certificate management (SSL and others)
- Throttling (as in rate-limiting activity or validating usage is consistent with contract/pricing)
Do NOT Do the Following when using the Gateway Pattern
Do not allow you and your team to fall into the following Gateway Traps:
- Do Not Build your own Gateway: For 99.999% of us, this is just ridiculous. If we do anything as a business other than develop Gateways, we should be leveraging open source and proprietary solutions that are widely adopted. Most of these solutions allow for significant configuration and even customization to fit your needs.
- Do Not Implement Multiple Gateways: Its fairly common for our clients to have an infrastructure team responsible for a hardware gateway load balancer and a software team that then implements an additional proxy in a software gateway. Don’t do this – increasing the multiplicative effect of failure is ridiculous. Choose one or the other that best fits your needs – not two because you have two different skillsets.