evankanderson
Disclaimer: I have this setup using Humanmade/S3-uploads for WordPress, but am not currently running Mastodon.
Representation is based on contributions to the project, and Google has publicly stated that they look forward to not being a majority on the steering committee (when other companies have exceeded Google's contributions).
There are CNCF projects whose governance is entirely within a single company. I get that there's a great narrative here that "Google doesn't share", but it seems like Google is being held to a higher bar here.
What you're describing with injecting outbound proxies is definitely something that Istio does in service mesh mode. When Knative launched 0.1 over a year ago, we had a pretty hard dependency on Istio. We heard a lot of feedback from users who weren't ready to make that much commitment, and as of 0.3 (last December or so), Knative supports multiple pluggable HTTP routers, including Gloo, Ambassador and Kourier.
If you aren't using Istio in mesh mode, Knative only controls inbound HTTP networking to your container instances, which it uses to implement scale-from-zero, concurrency-based-balancing, and percentage based version rollout. Outbound network is completely unaffected, except that containers may be shut down when they are no longer handing a request.
If you're using Java, see this writeup for how different frameworks can affect startup time: https://medium.com/google-cloud/java-frameworks-performances...
Similarly, if you're using Node or Python, you might want to see if any of your dependencies are enormous with lots of files and slow startup time -- you can check this locally by timing how long it takes to get to the initial listen() call and just print that wall time as you adjust dependencies.
If you're building Golang and you're seeing slow cold starts... I have no idea how you're doing that. For development, a lot of us on the open source http://knative.dev/ side are using Go http servers that take tens of milliseconds to start up, so there's probably some other initialization that's slowing you down.
Disclaimer: I work on both Cloud Run and App Engine at Google.
Unlike something like Fargate, it supports automatic scaling of containers based on requests, so it will run zero containers if you get no traffic, and 100 containers if you get (for example) 1500 requests per sec. The fully-managed version has a pay-per-100ms of execution model, while the GKE-hosted version uses an existing GKE cluster you provide.
Knative calls the role of the person providing the servers are "operator". Kubernetes is great for operators because it has a lot of common low-level primitives, and lots of choice if you want to pay someone else to be your operator.
Knative aims to give a similar great experience to developers if you can convince your operator to install it on top of the kubernetes they already have. In particular, if an operator charges you for container runtime minutes on knative, you're getting close to the pay-per use model of lambda or app engine. Also, as you noted, developers should have fewer concepts they need to grok in order to deploy a knative app compared with kubernetes.
I think it's an open question whether a PaaS like Google Dataflow is a good match or not. It will certainly require more planning, but I think it's doable.
The short summary if you had a nice client shell would be:
1) Run a command to deploy. That command:
a) determines what build templates are available on your cluster and what language/tools you're using, and finds a match between the two.
b) Creates a YAML definition of your application on the Knative cluster(and stages your source if needed).
2) On the server side:
a) The build component will (optionally) trigger to take staged source and convert it to a container.
b) The serving component will create Istio routes and various pieces to schedule your app into a k8s Deployment.
i) This Deployment will scale to zero if there's no activity, and scale back up if needed.
ii) Scale-to-zero is accomplished via a (shared) "actuator" which stalls the incoming HTTP request until a Pod is live.
c) Additionally, the serving components loads various observability tools like Prometheus and ELK (by default, the no-mon or lite installs skip this) so that you can see what's happening even as your pods appear and disappear.In order to do this, we've broken the problem down into 3 parts:
Buses provide a k8s-native abstraction over message buses like NATS or Kafka. At this level, the abstraction is basically publish-subscribe; events are published to a Channel, and Subscriptions route that Channel to interested parties.
Sources provide a similar abstraction layer for provisioning data sources from outside Kubernetes and routing them to the cluster, expressed as a Feed (typically, to a Channel on a Bus, but could also be directly to another endpoint). Right now, we only have a few generic Sources, but we plan to add more interesting and specific Sources over time.
Lastly, we have a higher-level abstraction called a Flow which bundles up the specification from the Source to the endpoint, optionally allowing you to choose the Channel and Bus which the event is routed over. (Otherwise, there is a default Bus used to provision a Channel.)
All of this is also very much work-in-progress. You're seeing the workshop as we put down our tools yesterday, not as cleaned up for a tour. :-)