Investigate Kubernetes-native solutions

[marshall007]

wormhole is a very elegant, general-purpose solution for connecting applications to Fly. Unfortunately, it does not integrate very seamlessly with typical deployment scenarios within k8 clusters. I think there are several possible integration points worth exploring:

• provide an image for running wormhole as a "sidecar" within the same pod as the service container
• implement a custom resource (CRD) that watches for the creation of pods (with particular annotations), automatically injects the wormhole sidecar, and starts proxying traffic from Fly to the pod
• investigate Knative as a solution for deploying edge apps within your own cluster (with access to cluster network), automatically registered with the Fly managed service
• investigate porting the custom v8 runtime as a networking primitive within Kubernetes
  • could be an interesting scripting solution for traffic management on Ingress and service mesh (Istio) resources

Ultimately, I think the most flexible solution would be a combination of the workflow-y improvements above coupled with the ability to deploy and operate Fly itself on Kubernetes. GitLab has done an incredible job embracing the "cloud-native solutions but no lock-in" philosophy/trend the industry is moving towards... as evidenced by all the effort they've been putting into their helm chart. Note that this chart is also what powers the deployment of their application in the GKE Marketplace under the hood.

In addition to operational flexibility for use cases that have strict compliance requirements (i.e. government and healthcare), I think a self-hosted Fly and/or Knative-based edge apps would be a great way to grow a strong community around the tech you guys have come up with.

[mrkurt]

This would be awesome. A production Fly infrastructure could work with something like nginx + fly + redis just fine.

• A frontend proxy that handles SSL (until TLS/https support #143 is done)
• App store: in dev mode, it uses the file_app_store, which works fine for running a single edge app. We can extract a redis_app_store from what we run in production to load up multi tenant apps.
• ~ Cache storage adapter: in dev mode it uses the memory_cache_store, feat: cache tagging, expires related cache entries #114 includes a redis_cache_store that's reasonable for production. We run twemproxy on our global stuff. ~
• File system adapter (readonly): in dev mode is uses file_store. In production we actually load these from the same redis as the app source.

Wormhole is standalone, and pretty easy to deploy, but it needs docs too. It could use the same redis, or even be modified to use etcd in a k8s world.

We can help a ton with all the adapters and things to build into Fly. We need a ton of help with Helm/k8s stuff though.