Enroute Universal Gateway
Enroute Universal Gateway
Introduction
With the advent of cloud and micro-services, proxies have taken up different roles. They are used at the edge or the perimeter for all incoming traffic. The perimeter was the point of running the proxy, providing network services for the application and managing it.
The perimeter proxy provided function for the application(s) running behind it. These included TLS termination, load balancing, API gateway functions and security. As the monolithic application got broken into microservices, so did the network function. This introduced multiple points to insert the network function - the perimeter or the edge, the intermediate proxy or the sidecar proxy.
Also with the adoption of kubernetes as the default orchestration platform for microservices, the kubernetes ingress gateway is a critical point to provide such services to micro services running inside a cluster.
Add to this the complexity of running the application/services/micro-services either in the cloud, on-premise, in a kubernetes cluster or outside.
Need for a Universal Gateway
Application architects and network operators, more than ever need an ability and flexibility to define network functions at any of the above proxy locations. Such flexibility is critical to meet the needs of the application.
Add to this the operational complexity of running the infrastructure. This complexity only increases with adoption of developer operation or DevOps practices. As the developer owns a part of operations, it creates challenges in the organization and in technological adoption.
In a constantly changing environment, Enroute is the key network function delivery substrate. It can take on the role of a perimeter API gateway, a Kubernetes Ingress API gateway or a centralized control plane that can control and manage several stateless sidecar API gateways.
Envoy proxy in polymorphic use-cases
Envoy has been adopted by several projects as a key data-plane component to delivery services to applications. It has shown wide adoption for implementing functions at the edge, at the sidecar and in between. However control planes have committed to providing solutions at one of these locations.
A well designed control plane needs to extend and expose Envoy’s flexibility and ability to take on several roles - as an edge proxy, as a kubernetes ingress gateway and as a sidecar proxy.
The Enroute Universal Control Plane provides this flexibility. It also extends Envoys filter mechanism to attach functionality to the control plane.
Envoy also defines the xDS API to stream configuration to the underlying proxy without restarts. The control plane needs the ability to stream xDS config to Envoy’s without restart.
A flexible control plane, with Envoy’s extensible architecture and ability to stream xDS config is important.
## Enroute: A universal gateway built on top of Envoy ProxyConsidering all the above requirements, Enroute was built to work in multiple use-cases. The key tenant to building the control plane was the ability to provide a uniform API function and features across all the network function insertion points.
#### [Enroute Gateway For Kubernetes](/docs/getting-started-enroute-ingress-controller/)Enroute can be run at kubernetes ingress as an API gateway to micro-services running inside kubernetes. When run in this manner, its behavior and configuration can be driven using CRDs. Refer to the getting started article on Enroute Kubernetes Ingress Gateway for more details.
Enroute can be run as a traditional API gateway for services. When run in this manner, it can be configured using REST API calls to configure it. Refer to the getting started article on Enroute API gateway for more details.
Enroute can also be run in dual-plane mode with a clear separation of the control plane and multiple stateless data planes. The control plane has the REST API interface to configure the stateless data planes. This provides the flexibility to run the API gateway function at the side-car level. Additionally it also provides a way to horizontally scale out the L7 API gateway fabric across several proxies. Refer to the getting started article on Enroute control-plane for multiple sidecar gateways.
Containerized
Enroute artifacts are built as containers. Such a form factor provides the flexibility to run anywhere - in the cloud, inside kubernetes, as a sidecar and as a stand-alone gateway.
Run with database or in db-less mode
The enroute data plane is stateless. Enroute control plane can use a database to store config. Alternatively, the enroute control plane can also be run without persisting the docker volume. This is useful when the config is held elsewhere and a database is not required. This is also useful in gitops like use-cases where infrastructure is specified as code.
Enroute extensibility
Filters in Enroute provide the extensibility to add services or network function. There are two levels of filters - (1) global filters that are applied to all traffic going through the gateway (2) per-route filters that are applied to traffic that matches that specific route.
Global filters
Global filters are associated with services or at the virtual host level. Any traffic that goes through the proxy gateway undergoes the filter logic attached to it. This provides the flexibility to attach a network function at the virtual host or service level.
If a service has multiple routes defined, the global filter is applied to all this traffic regardless of the route it matches.
An example of this filter is the lua filter. A lua script can be attached at the global level for request and response processing.
Per-route filters
Per-route filters are only applicable to traffic that matches a particular route.
If a service has multiple routes defined, the per-route filter does not apply to all traffic going through the service. The filter logic is only applied to the subset of traffic that matches this route.
Per-route advanced rate-limiting is a filter that can be attached at the route level.
Enroute Universal Gateway features
Programmability using lua scripting
The lua filter is a global filter that associates a lua script to a HTTP request and HTTP response.
For more details on getting started with the lua global filter, see article on getting started with lua filter.
Advanced rate-limiting
The per-route rate-limiting feature provides advanced rate-limiting capabilities for traffic going through a specific route. It supports unlimited configurability and uninhibited functionality for rate-limiting on basis of the user, a specific header or another HTTP attribute.
For more details on getting started with the rate-limit per-route filter, see the article on getting started with rate-limit filter.
Conclusion
Enroute Universal gateway proxy is a flexible API gateway to work in any environment. It comes packaged with advanced features and programmability to meet different use-cases and architecture.
Enroute is built on the flexible and versatile cloud-native Envoy proxy and uses Envoys xDS API to stream configuration updates without restarts and traffic interruption.
The various form factors in which API gateway function can be implemented with Enroute provides the flexibility and peace of mind to a network and application architect to meet the challenges of adopting microservices and cloud.
The adoption of cloud and microservices not only needs new technology stacks, but also new processes and a change in team organization. Enroute’s architecture provides enough adaptability to meet these goals of an organization.
Latest Posts
