Adds initial goals doc #7
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,79 @@ | ||
| # Goals | ||
|
|
||
| The high-level goal of the Envoy Gateway project is to attract more users to Envoy by lowering barriers to adoption | ||
| through expressive, extensible, role-oriented APIs that support a multitude of ingress and L7/L4 traffic routing | ||
| use cases; and provide a common foundation for vendors to build value-added products without having to re-engineer | ||
| fundamental interactions. | ||
|
|
||
| ## Objectives | ||
|
|
||
| ### Expressive API | ||
| The Envoy Gateway project will expose a simple and expressive API, with defaults set for many capabilities. | ||
|
|
||
| The API will be the Kubernetes-native [Gateway API][], plus Envoy-specific extensions and extension points. This | ||
| expressive and familiar API will make Envoy accessible to more users, especially application developers, and make Envoy | ||
| a stronger option for "getting started" as compared to other proxies. Application developers will use the API out of | ||
| the box without needing to understand in-depth concepts of Envoy Proxy or use OSS wrappers. The API will use familiar | ||
| nouns that [users](#personas) understand. | ||
|
|
||
| The core full-featured Envoy APIs will remain available for those who need more capability and for those who | ||
|
|
||
| add functionality on top of Envoy, such as commercial API gateway products. | ||
|
There was a problem hiding this comment. Should s/commercial API gateway products/commercial API management products/ since EG is an API gateway? I feel like EG does not compete with commercial API Gateways, e.g. Tyk, but will not compete with commercial API management systems, e.g. Ambassador Cloud, Edge Stack, etc. There was a problem hiding this comment. I would call Edge Stack an API gateway product; it is essentially Emissary plus (1) an ext_authz service that provides additional gateway-related features, and (2) a service that is a fork of envoyproxy/ratelimit. |
||
|
|
||
| This expressive API will not be implemented by Envoy Proxy, but rather an officially supported translation layer | ||
| on top. | ||
|
|
||
| ### Batteries included | ||
| Envoy Gateway will simplify how Envoy is deployed and managed, allowing application developers to focus on | ||
| delivering core business value. | ||
|
|
||
| The project plans to include additional infrastructure components required by users to fulfill their Ingress and API | ||
| gateway needs: It will handle Envoy infrastructure provisioning (e.g. Kubernetes Service, Deployment, et cetera), and | ||
| possibly infrastructure provisioning of related sidecar services. It will include sensible defaults with the ability to | ||
| override. It will include channels for improving ops by exposing status through API conditions and Kubernetes status | ||
| sub-resources. | ||
|
|
||
| Making an application accessible needs to be a trivial task for any developer. Similarly, infrastructure administrators | ||
| will enjoy a simplified management model that doesn't require extensive knowledge of the solution's architecture to | ||
| operate. | ||
|
|
||
| ### All environments | ||
| Envoy Gateway will support running natively in Kubernetes environments as well as non-Kubernetes deployments. | ||
|
|
||
| Initially, Kubernetes will receive the most focus, with the aim of having Envoy Gateway become the de facto | ||
| standard for Kubernetes ingress supporting the [Gateway API][]. | ||
|
There was a problem hiding this comment. It's a footer-style link; the URL is at the bottom of the doc, since there are multiple links to it. [Gateway API]: https://gateway-api.sigs.k8s.io/ |
||
| Additional goals include multi-cluster support and various runtime environments. | ||
|
|
||
| ### Extensibility | ||
| Vendors will have the ability to provide value-added products built on the Envoy Gateway foundation. | ||
|
|
||
| It will remain easy for end-users to leverage common Envoy Proxy extension points such as providing an implementation | ||
| for authentication methods and rate-limiting. For advanced use cases, users will have the ability to use the full power | ||
| of xDS. | ||
|
|
||
| Since a general-purpose API cannot address all use cases, Envoy Gateway will provide additional extension points | ||
| for flexibility. As such, Envoy Gateway will form the base of vendor-provided managed control plane solutions, | ||
| allowing vendors to shift to a higher management plane layer. | ||
|
|
||
|
There was a problem hiding this comment. Can we add a point about "Stronger Envoy out of the box" - which highlights incorporating envoy native auxiliary control planes such as the envoy ratelimit service as well as core control plane libraries such as the go control plane There was a problem hiding this comment. I feel like "Stronger Envoy out of the box" is aligned with the simplification we want to push forward, but goes against extensibility. We want a "batteries included" solution, but are still unsure about which batteries. There was a problem hiding this comment. yeah can we add batteries included into the goals doc. https://github.com/envoyproxy/ratelimit seems to be one, there might be more in the future such as an OIDC service or TLS Issuer service. There was a problem hiding this comment. @alexgervais I like the "batteries included" analogy. Beyond the points above, the details behind "batteries included" can be 1. sensible defaults with the ability to override 2. Envoy infra provisioning, e.g. k8s service, deployment, etc. 3. should we include a self-signed CA to simplify TLS termination (for non-prod use) 4. improved ops through API status conditions, 5. Others? There was a problem hiding this comment. Do we want to provide details about which batteries are included? I feel we need validation from the governance group in order to make sure we have an agreement from all vendor affiliations before committing to any of them. There was a problem hiding this comment. @alexgervais I don't think we need to detail the battery details ;-) That can come in the future if needed. I just wanted to provide thoughts related to your "... but are still unsure about which batteries." There was a problem hiding this comment. wdyt Batteries IncludedThe Envoy Gateway project will strive to include any additional infrastructure components required by users There was a problem hiding this comment. I suggest we keep the goals as high-level as possible. Maybe just keep the first sentence from ^
The design doc can xref the example components provided above. When the design doc is merged, we will create GH issues to track the desire to add these specific components. There was a problem hiding this comment. I hope I've captured the intent in bd5bc15. I used some of the specifics from #7 (comment) because while I agree that we should keep things as high-level as possible, I think that 1 sentence on its own isn't sufficiently clear. |
||
| ## Non-objectives | ||
|
|
||
| ### Cannibalize vendor models | ||
| Vendors need to have the ability to drive commercial value, so the goal is not to cannibalize any existing vendor | ||
| monetization model, though some vendors may be affected by it. | ||
|
|
||
arkodg marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| ### Disrupt current Envoy usage patterns | ||
| Envoy Gateway is purely an additive convenience layer and is not meant to disrupt any usage pattern of any user | ||
| with Envoy Proxy, xDS, or go-control-plane. | ||
|
|
||
| ## Personas | ||
LukeShu marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| _In order of priority_ | ||
|
|
||
| ### 1. Application developer | ||
| The application developer spends the majority of their time developing business logic code. They require the ability to | ||
| manage access to their application. | ||
|
|
||
| ### 2. Infrastructure administrators | ||
| The infrastructure administrators are responsible for the installation, maintenance, and operation of | ||
| API gateways appliances in infrastructure, such as CRDs, roles, service accounts, certificates, etc. | ||
| Infrastructure administrators support the needs of application developers by managing instances of Envoy Gateway. | ||
|
|
||
| [Gateway API]: https://gateway-api.sigs.k8s.io/ | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It appears that we need to add egress to the goals, xref.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm leaving it out for now, given the reaction in yesterday's call.