Adds initial goals doc #7
Conversation
GOALS.md
Outdated
| # Goals | ||
|
|
||
| WIP and comments on the project's goals can currently be found in this document: | ||
| https://docs.google.com/document/d/18MuuV9Qzij7Z1OeZ6GrOURKzVi9D0qv2SgvFPELM4gc/edit |
There was a problem hiding this comment.
@alexgervais thanks for getting this started. The referenced goals doc is higher-level and a bit more wordy than what I'd like to see in this repo, but it does provide a good reference point for us to develop the GOALS.md. Here are a few goals that I noted from the kick-off meeting:
- Make Envoy easy to consume for simple use cases. For example, provide an API that abstracts xDS APIs, e.g. route HTTP/TLS requests for https://foo.example.com/bar to a backend Kubernetes service.
- Have Envoy Gateway become the de facto standard for Kubernetes ingress.
- Envoy Gateway should be expressive. For example, expose xDS APIs to support advanced gateway use cases instead of trying to replicate all the functionality provided by xDS.
- Support multiple personas, e.g. Infra Admins create Envoy Gateway/Proxy instances while App Devs create routing rules to their backend apps.
- Support various runtime environments with Kubernetes being the initial focus.
- Envoy Gateway should be extensible. For example, users should be allowed to use rate limiting solution "Foo" instead of envoyproxy/ratelimit.
As you can see above, I highlighted "simple", "expressive", and "extensible". IMHO these words should be the core principals of the project.
@mattklein123 @arkodg @youngnick feel free to add any goals as comments to this PR so we can get the GOALS.md merged.
There was a problem hiding this comment.
This all sounds reasonable to me. One thing that we didn't discuss in the meeting is I would personally like multi-cluster to be an explicit medium-term goal. I think this is a critical feature in any real product deployment.
There was a problem hiding this comment.
@mattklein123 I agree 100%, especially with it being a medium-term goal ;-) I created #9 to capture this, PTAL. @alexgervais please ensure that the GOAL.md specifies this requirement.
There was a problem hiding this comment.
@alexgervais IMO we should drop this section and the linked gdoc.
There was a problem hiding this comment.
@danehans agreed. I'll move it to the PR description so we still have a reference somewhere.
|
@alexgervais I'm converting this PR to draft. Please remove when you feel like it's ready to merge. |
| Since a general-purpose API cannot address all use cases, the Envoy Gateway will provide additional extension points | ||
| for flexibility. As such, the 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 Included
The Envoy Gateway project will strive to include any additional infrastructure components required by users
to fulfill their Ingress and APIGateway feature needs. This list can be exhaustive so as a starting point, the project will natively include any components that are part of the Envoy ecosystem (such as ratelimit service) or introduce new components for features that historically couldn't be implemented in Envoyproxy such as ACME support.
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 Envoy Gateway project plans to include any additional infrastructure components required by users
to fulfill their Ingress and API gateway needs.
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.
Signed-off-by: alex <alex@datawire.io>
… the markdown file Signed-off-by: alex <alex@datawire.io>
Co-authored-by: Arko Dasgupta <arkodg@users.noreply.github.com> Signed-off-by: alex <alex@datawire.io>
There was a problem hiding this comment.
A few more pieces of feedback for @alexgervais and the community as a whole.
| Since a general-purpose API cannot address all use cases, the Envoy Gateway will provide additional extension points | ||
| for flexibility. As such, the 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.
@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?
GOALS.md
Outdated
| @@ -0,0 +1,71 @@ | |||
| # Goals | |||
|
|
|||
| The high-level goal of the Envoy Gateway project is to attract more users to Envoy by adding new capabilities | |||
There was a problem hiding this comment.
Do folks think it's worth adding something here about building an extensible foundation that vendors/other projects can build on top of? To me it seems equally important and worth stating here.
There was a problem hiding this comment.
I'm on the fence. Looking a the updated wording to "support a multitude of ingress and L7/L4 traffic routing use cases", it feels like a pretty good WIIFM for newcomers and eludes to the inclusion of an unlimited set of possible extensions.
There was a problem hiding this comment.
This is sort of said under "extensibility", but I think I agree with @skriss that this would be a good thing to have up-top. The current wording gives a good WIIFM for newcomer users, but I think it would also be good to include this as a WIIFM for newcomer developers.
What about this?
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.
+use cases; and provide a common foundation for vendors to build value-added products without having to re-engineer
+fundamental interactions.There was a problem hiding this comment.
I've gone ahead and committed that as eb0db71, even though I'm not in love with the wording.
Signed-off-by: alex <alex@datawire.io>
| Since a general-purpose API cannot address all use cases, the Envoy Gateway will provide additional extension points | ||
| for flexibility. As such, the 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.
I suggest we keep the goals as high-level as possible. Maybe just keep the first sentence from ^
The Envoy Gateway project plans to include any additional infrastructure components required by users
to fulfill their Ingress and API gateway needs.
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.
GOALS.md
Outdated
| # Goals | ||
|
|
||
| WIP and comments on the project's goals can currently be found in this document: | ||
| https://docs.google.com/document/d/18MuuV9Qzij7Z1OeZ6GrOURKzVi9D0qv2SgvFPELM4gc/edit |
There was a problem hiding this comment.
@alexgervais IMO we should drop this section and the linked gdoc.
Signed-off-by: alex <alex@datawire.io>
There was a problem hiding this comment.
Just coming back and catching up.
This is looking pretty great!
I asked this more specifically below, but I don't see the point in being coy about the fact that the Gateway API is the key crystalizing factor here. Without there being a more descriptive, role-based etc. upstream API for us all to work towards, we wouldn't be here, right?
We're going to implement an API that's being developed in Upstream Kubernetes, because it's intended to meet all the goals for APIs we're describing here. Why not just say that?
GOALS.md
Outdated
| The 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 the Envoy Gateway become the de facto | ||
| standard for Kubernetes ingress supporting the [Gateway API](https://gateway-api.sigs.k8s.io/). |
There was a problem hiding this comment.
It seems a little weird to me that this is the only mention of the Gateway API. If the point is to use the Gateway API as the starting point, why not mention that earlier? Is there some context here I missed?
There was a problem hiding this comment.
@alexgervais I agree with @youngnick. The doc has the ## Expressive API section that we should clearly state this project intends to leverage Gateway API to provide expressive, extensible, role-oriented APIs. Refer to how Gateway API is highlighted in the recent Istio CNCF announcement.
There was a problem hiding this comment.
I've attempted to address this in 8792c73.
There was a problem hiding this comment.
@alexgervais other than the need to add "egress" (xref) to the ## Goals section, everything else are nits.
| # 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 |
There was a problem hiding this comment.
It appears that we need to add egress to the goals, xref.
There was a problem hiding this comment.
I'm leaving it out for now, given the reaction in yesterday's call.
| The expressive 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.
GOALS.md
Outdated
| 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. | ||
|
|
||
| This expressive API will not be implemented by the Envoy Proxy, but rather an officially supported translation layer |
There was a problem hiding this comment.
Since we've already made reference to the API as being simple, expressive, etc, IMHO this paragraph reads better if follow-on references to the API are "the API".
There was a problem hiding this comment.
I almost included that in 5172fcc, but decided to leave this sentence as-is. There are plenty of APIs that are implemented in Envoy Proxy itself, so in this sentence I think it makes sense to leave in "expressive" (as in the section header) as a scope-limiter for the sentence.
GOALS.md
Outdated
| The 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 the Envoy Gateway become the de facto | ||
| standard for Kubernetes ingress supporting the [Gateway API](https://gateway-api.sigs.k8s.io/). |
There was a problem hiding this comment.
@alexgervais I agree with @youngnick. The doc has the ## Expressive API section that we should clearly state this project intends to leverage Gateway API to provide expressive, extensible, role-oriented APIs. Refer to how Gateway API is highlighted in the recent Istio CNCF announcement.
Signed-off-by: Luke Shumaker <lukeshu@datawire.io>
Signed-off-by: Luke Shumaker <lukeshu@datawire.io>
Signed-off-by: Luke Shumaker <lukeshu@datawire.io>
This is the description suggested by Daneyon on GH, but with the phrase ", e.g. path-based routing" removed per Alex and Nick. Co-authored-by: danehans <daneyonhansen@gmail.com> Signed-off-by: Luke Shumaker <lukeshu@datawire.io>
Signed-off-by: Luke Shumaker <lukeshu@datawire.io>
…bility Signed-off-by: Luke Shumaker <lukeshu@datawire.io>
Signed-off-by: Luke Shumaker <lukeshu@datawire.io>
Signed-off-by: Luke Shumaker <lukeshu@datawire.io>
|
LGTM |
| 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/
|
LGTM with one small missing link nit from me. |
Co-authored-by: Arko Dasgupta <arkodg@users.noreply.github.com>
|
I'm merging since the link works and @LukeShu provided feedback in #7 (comment) |
| 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 |
| 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. |
Signed-off-by: alex alex@datawire.io
fixes #6
Initial discussions and comments on the project's goals can be found in this document:
https://docs.google.com/document/d/18MuuV9Qzij7Z1OeZ6GrOURKzVi9D0qv2SgvFPELM4gc/edit