Published February 11, 2020Last Modified September 02, 2020
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 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 Proxy
Considering 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.