The API Gateway pattern
With the API Gateway pattern, we are explicitly simplifying the calling of a group of APIs to emulate a cohesive API for an “application” for a specific set of users, clients, or consumers. As we use microservices to build our systems, the notion of “application” kind of disappears. The API Gateway pattern helps to restore this notion. The key here is the API gateway, when it’s implemented, becomes the API for clients and applications and is responsible for communicating with any backend APIs and other application network endpoints (those that don’t meet the aforementioned definition of API). Another term you may hear that represents the API gateway pattern is “backend for frontends” where “front end” can be literal front ends (UIs), mobile clients, IoT clients, or even other service/application developers.
A developer’s tool
An API gateway is much closer to the developers view of the world and is less concentrated on what ports or services are exposed for outside-the-cluster consumption. An API gateway mashes up calls to backends that may expose APIs, but may also talk to things less described as APIs such as RPC calls to legacy systems, calls with protocols that don’t fit the nice semblance of “REST” such as hacked together JSON over HTTP, gRPC, SOAP, GraphQL, websockets, and message queues. This type of gateway may also be called upon to do message-level transformation, complex routing, network resilience/fallbacks, and aggregation of responses.
Fits a decentralized workflow
Since the API gateway is so closely related to the development of applications and services, we’d expect developers to be involved in helping to specify the APIs exposed by the API gateways, understanding any of the mashup logic involved, as well as need the ability to quickly test and make changes to this API infrastructure. We also expect operations or SRE to have some opinions about security, resiliency, and observability configuration for the API gateway. This level of infrastructure must also fit into the evolving, on-demand, self-service developer workflow. See the GitOps model for more on that.
Understanding Gloo API Gateway
Gloo API Gateway contains a robust set of features and is accessible using Gloo’s own Custom-Resource based resources:
VirtualServices provide the routing configuration to Gloo in the form of route tables. Each Virtual Service represents an ordered set of routes for a single set of domains.
Upstreams represent routable destinations in Gloo, similar to
clusters in Envoy terminology, except that Upstreams can be expressed as custom resources (stored in Kubernetes, Consul, or in YAML files).
Follow these guides to get started using Gloo Gateway:
- Getting Started
- Customizing Routes
- Function Routing
- Security Configuration
- Service Mesh
- External Services
Basic example of using Gloo to route to a service, including a path-rewrite.
Routes can be configured to add HTTP features to traffic such as retries, fault injections, and timeouts. Routes can also be configured to use a variety of request matching techniques, as well as perform different actions when a request is matched, such as splitting traffic between multiple targets and sending direct responses to clients. The following guides detail different ways of configuring Gloo routes with different behaviors and features. Advanced Route Matching Advanced routing matching rules for Gloo.
Gloo routes can be used to call functions and remote procedures that live on your services, as well as those provided by serverless runtimes such as AWS Lambda and Azure Functions. The following guides demonstrate configuring Gloo to invoke OpenAPI endpoints and AWS Lambda functions. AWS Lambda Routing AWS Upstream configuration guide. REST Endpoint Routing Create function routes to REST API endpoints discovered from a Swagger (OpenAPI) specification.
The following guides cover security configuration settings for Gloo such as TLS. Setting up Server TLS Understanding how to set up TLS for Gloo Configure CORS Understanding CORS Cross-Origin Resource Sharing (CORS) is a method of enforcing client-side access controls on resources by specifying external domains that are able to access certain or all routes of your domain. Browsers use the presence of HTTP headers to determine if a response from a different origin is allowed.
Service mesh technologies solve problems with service-to-service communications across cloud networks. Problems such as service identity, consistent L7 network telemetry gathering, service resilience, traffic routing between services, as well as policy enforcement (like quotas, rate limiting, etc) can be solved with a service mesh. For a service mesh to operate correctly, it needs a way to get traffic into the mesh. The problems with getting traffic from the edge into the cluster are a bit different from service-to-service problems.
Adding External Services to Gloo Example of routing to an external upstream. Routing to AWS EC2 Instances Example of routing to EC2 instances.