Back in 2016, as Kubernetes was gaining steam, there was a movement called Google Infrastructure for Everyone Else (GIFEE) that was evangelized by container startups that bought into Google's way of doing things – Kubernetes, TensorFlow, gRPC, Prometheus, and Bazel to name a few. At the time, there was a debate – should companies emulate Google's way of doing things? Some agreed. Others didn't – e.g., You Are Not Google.
8 years later, the debate is still alive, but we have more data to look at.
Kubernetes is complex but arguably a good way to do things – even if you aren't using it directly, many popular services were enabled or inspired by its API and workflow. It should be noted that Kubernetes is inspired by, but not Borg, the internal workload (not Docker) scheduler used by Google. Very few services at Google run on Kubernetes. So in a way, it wasn't really "the Google way of doing things."
On the other hand, projects that were more tied to Google infrastructure were maybe worse bets. Bazel is the product of good ideas that are too coupled with Google's monorepo. For example, there's very little support for package management (third-party code is vendored into the monorepo at Google). Unlike Kubernetes, it wasn't rewritten for public consumption.
In the middle, there are projects like gRPC and GraphQL (from Meta). Good ideas, good execution, but potentially solving problems at scale or with infrastructure topologies that aren't common. Protobufs are great – schema-driven, efficient, and coupling it with an RPC framework makes sense. Yet, the developer experience is lacking, and the learning curve is steep (there are few good alternatives). GraphQL equally solves many issues but creates new challenges – a tradeoff specifically made for the data and use cases at Meta.