Brian Grant

The initial focus gravitated towards directly supporting features needed by Cloud in Borg so that Cloud wouldn't need to work around the the lack of those features (see my previous comment on 2-level scheduling: https://twitter.com/bgrant0607/status/1126153859041087488 …)

Google also spends a lot of energy constantly mitigating entropy in its internal software and infrastructure. The monorepo is one mechanism for this. It also launches many efforts to “unify” or “converge” multiple systems that co-evolve to do similar things.

In that context, 2 months later, the Unified Compute Working Group was formed by Google Cloud and Google's internal infrastructure group, "TI", which included Borg. The goal was to develop a proposal for a "compute platform" that could be used by both Cloud and internal customers

It was obvious that VMs would be too cumbersome and inefficient and PaaSes of the time weren't versatile enough to run a wide range of internal services, such as web search and Gmail. We needed a platform that was more like Borg, that was based on containers.

There were discussions regarding how compatible it should be with App Engine and with Borg. Docker, buildpacks, and Omlet (a new node agent under development to replace Borglet) were compared. Early discussions presumed a managed service, like GCE, App Engine, and Borg

In September 2013, viewpoints of 9+ WG participants were collected and composed into a "Unified Compute PRD", focused on serving workloads (e.g., rather than batch). That was the first time I was aware of the term "Container as a Service" being used

In October, subgroups of the WG were formed to focus on key problems, including a container management API subgroup. In November, we pulled in more people from Borg and from Cloud to hash out a number of API details. In December, an API proposal was presented to the full WG