While the entire comment could be contradicted, a quick example is that google’s SRE book details much more developer strategies, including from a massive scale and enterprise perspective, than 12 factor web app. This book was assembled but industry experts with experience from Borg, with borg emerging from the global work queue — decades before heroku existed.
I would argue that's precisely the problem. Google are clearly capable of doing complex things, but inspiring and nurturing an entire cultural shift is a different category of "complexity", which in the story of Paas, Google did not achieve, they merely exploited it.
I think you're arguing that that's a bad thing. But it's a thing that very much did happen, because kubernetes is successful.
So docker is maybe the thing that allowed kubernetes to catch on, but that's just because the external world was catching up to what borg had been doing for more than a decade, and so kubernetes was Google sticking a decade or more of expertise in container orchestration into the OSS world.
Google caught up to Docker not the other way round.
When kubernetes was released, the majority of that ecosystem didn't yet exist. Kubernetes influenced many of those best practices, standards, and tooling. So in shaping the ecosystem, yes, docker was catching up to Google. Like I think this would be a reasonable argument if Kubernetes was released today, but it was released only about a year after Docker was.
(heck, iirc, even docker as a tool was originally built on LXC, which I think google functionally upstreamed as part of borg hypervisor stuff, but I could be mistaken there. I do know that LXC was based on Google work though: https://www.nextplatform.com/2016/03/22/decade-container-con...)
Edit: Ok yeah I think I figured it out, cgroups is the borg upstreamed feature (https://news.ycombinator.com/item?id=9506800), LXC and evenutally docker are built atop cgroups, etc. etc. So the entire modern containerization infra is built atop a feature borg upstreamed.
Yes LXC and cgroups were Google contributions before the existence of Docker. But jails and containers in general were also general ideas before LXC and cgroups, I think most notably in BSD.
I feel like we must have had different experiences of that period 8 or so years ago. I distinctly remember the hype and bandwagon feeling of Docker's release. I remember various projects trying to capitalise on Docker to make PaaS-type projects; Swarm, Deis, Flynn (even my own Peas project), before Kubernetes came along. It seems so clear to me that Google were reactive rather than proactive. I really don't think Kubernetes would be a thing without Docker.
And even then I think you understimate googles contribution of "we've literally been doing container orchestration for longer than anyone else, here's tooling that is built with lessons we've learned in mind". That's far more than just "money and influence", and I don't think it's "exploitative".
I think in the same way that you're concerned I'm misrepresenting Google, I'm concerned that the documentary misrepresents the landscape of developers and projects that set the scene for Google's Kubernetes. Yes Google made significant contributions to the story that led up to Kubernetes, but crucially, I believe they didn't nurture the culture, they didn't create the mindset that makes developers (and managers) ready to think in a containerised way. And I think that's important because the smaller voices that did make those innovations easily get drowned out by the might of Google.
Google pre-k8s achieved "container" orchestration by controlling the whole stack in detail. K8S provided a way to get most of that with mostly arbitrary code.
The public version of this embraced a fundamentally different status quo: software is a mess. People pull in dependency in many different ways. You may end up using some python code that has a C extension that in order to build requires some C library whose installation instructions are a mix of run some install script after having installed some apt package.
This idea that you build a container with a container (and accepting that the resulting mess is "ok") is indeed something that has to be granted as a form of innovation to docker. It created a whole new industry of people trying to tame the dependency hell and supply chain woes that have been just swept under a carpet.