Decision: Should Kube and Non Kube Be Two Separate Builds

[danehans]

This issue comes from @youngnick comments in 6/9/21 community meeting:

"Should we consider building two version of EG, one for Kubernetes and one for non-Kubernetes? (With code reuse between them, of course). I’m writing a doc about what the install experience should look like for both options, and I’m worried that trying to serve both with one thing may make them too complex."

[shaneutt]

As someone who's interested in this project and would like to contribute I have honestly been left wishing for this kind of distinction (in fact I was almost kinda hoping that these efforts would even be separate repositories, perhaps sharing some libraries, but that's taking it to another level I suppose). I don't have any need of the non-kube use case (at least for the moment) so the thought had occurred to me that separations of these concerns would help at least reduce noise and complexity.

[arkodg]

hey @shaneutt supporting all environments is a core goal of the project with an initial focus on kube. The outcome of this issue should help add more clarity on internal k8s specific tasks and components as well as end user UX and arch.

from an end user intent perspective, the user could either specify the platform they can running on via the BootstrapConfig as suggested here or envoy-gateway can have distinct subcommands - kubernetes & local/stand-alone/docker .
from a project perspective would prefer if everything lives in the same repo initially to speed up development.

[shaneutt]

hey @shaneutt supporting all environments is a core goal of the project with an initial focus on kube. The outcome of this issue should help add more clarity on internal k8s specific tasks and components as well as end user UX and arch.

from an end user intent perspective, the user could either specify the platform they can running on via the BootstrapConfig as suggested here or envoy-gateway can have distinct subcommands - kubernetes & local/stand-alone/docker . from a project perspective would prefer if everything lives in the same repo initially to speed up development.

👍

[danehans]

I created a brainstorming doc to allow more freeform discussion on this topic. As we did in #60, a summary and any agreed-upon outcomes should be surfaced in this issue before it is closed.

cc: @alexgervais @LukeShu @arkodg @youngnick @skriss

[danehans]

closing due to #111 that provides details of the agreed-upon EG design.