Google's Cloud Run service, which lets you run containers on Kubernetes (K8s) using a serverless model, has hit general availability, and El Reg has taken it for quick spin.
Cloud Run is for both Google Cloud Platform and Anthos, which presents various ways to use Cloud Run on Google Kubernetes Engine (GKE) on-premises or in other clouds.
The idea of the service is that developers can think mainly about their code and the container in which it runs. You deploy the container with Cloud Run and it will auto-scale from zero to 1,000 (the default maximum) or more, according to demand.
The auto-scaling is based on three factors: CPU utilisation; concurrency (number of requests per container instance); and the number of requests. By default, each instance will support up to 80 concurrent requests, though if Cloud Run detects that the CPU is maxed out, it will create new instances before the maximum is reached.
Since it is container-based, the configuration of the container in terms of runtimes and dependencies is a developer choice, provided it is based on 64-bit Linux. Containers are stateless so you will need additional services to provide and persist data as needed.
Google calls this model "serverless containers". Serverless platforms like AWS Lambda, Azure Functions or Google Cloud Functions let you deploy code to a fully managed runtime. Although this is cleaner than having to worry about containers, it is also less flexible since you have little influence over the details of the runtime environment. It can also be inefficient. Cloud Functions can only handle one request at a time, which means more instances will be created at busy times. Cloud Run lets you tune this for best efficiency.
Cloud Run is based on the Knative API. This extends K8s to provide the deployment and auto-scaling features used by Cloud Run. That said, if you use the GCP version of Cloud Run, it might not use K8s. "Knative is the API that Cloud Run is based on. On the fully managed version of Cloud Run we don't actually run a K8s cluster," said product manager Donna Malayeri, also a member of the Knative Steering Committee, in a podcast. "But we do have a K8s API server. So the API that you use to deploy your application... is the Knative API."
In other scenarios, such as Cloud Run for Anthos, or your own K8s cluster, Cloud Run does use a K8s cluster.
No one company should aspire to control outcomes
There are some industry politics around Knative, which is open source under the Apache 2.0 licence. Kubernetes is maintained by the Cloud Native Computing Foundation (CNCF), part of the Linux Foundation. It had been expected that Knative along with Istio, a service mesh used by Knative, would in due course be handed over to CNCF. In October, though, Google stated that it would not do so "for the foreseeable future" to the disappointment of many in the community.
Google has now responded with a blog post in the form of an open letter from the steering committee (currently four Google members, and one each from Pivotal, IBM and Red Hat). The letter states that future membership of the Steering Committee and Technical Oversight Committee will be based on both code and non-code contributions to the project. It also says that "no one company should aspire to control outcomes" and takes an aggressive stance towards protecting the "Knative trademark", with the promise of legal help from Google as needed. This would perhaps deter others from forking Knative.
The letter does not address the question of why Google is unwilling to hand the project to a foundation. There is indirect reference to this by Malayeri in the podcast mentioned above, though it is pretty confusing. "The feedback we heard from both our partners on the steering committee as well as the community at large was, Google isn't the only contributor any more. Now Google was 60 per cent of the contributions. Why don't we look at this again, why don't we broaden this space?" said Malayeri, promising "more diversity in Knative". She then said:
Our goal is not to have this be a Google-controlled project. If that were the case it would have been a lot easier to just open source this and throw it over the wall versus what we intended to do, which is to build an open and vibrant community.
Does Google believe that handing over stewardship to a vendor-neutral foundation is "throwing it over the wall"? And that it prevents an "open and vibrant community"?
The fact is that Google does not want to cede control of Knative and must regard this as a commercial advantage, while at the same time wanting to make the right noises about it being a cross-vendor project. It is a tension that is unlikely to go away. ®