Who needs Google technology? Probably not you

Clearly Google is doing something right. Although Google Cloud’s revenue still lags AWS and Microsoft Azure, it’s growing much faster (albeit on a smaller base). But that’s not the real story of its growth. The story is that it’s growing at all. Google Cloud should have been knocked out in the second round given AWS’s years-long head start and Microsoft’s enterprise IT dominance. Google is booming, particularly now given its strength in AI. By some accounts, its newest Gemini model meets or exceeds OpenAI’s GPT-4 in areas like complex reasoning.

This is Google doing what it does best: tackling bafflingly hard computer science problems and releasing the output as research papers, open-source projects, or cloud services for the rest of us. From Kubernetes to Angular to Bazel to Zanzibar, Google has either released or inspired a range of different technologies that are now commonly used.

But that doesn’t mean you should. Use them, I mean.

After all, you’re not Google, and you won’t be anytime soon. Yes, I’ve argued that “run like Google” is an achievable goal, but the kinds of challenges Google faces are generally not the problems you’re going to have in your lifetime. Google’s Zanzibar is an example of tech that is awesome for Google but likely won’t be for mainstream enterprises.

Be yourself

To be clear, this is an argument against running like Google, particularly when the inspiration comes from Google research papers. It’s emphatically not an argument against buying from Google (Cloud). As mentioned, Google Cloud has hit a rich vein with enterprise adoption. Google BigQuery and other services, plus new AI models like Gemini 2.0, have helped many enterprises level up the way they build and run software. They represent Google taking the best of its technology approaches and applying them to mainstream enterprise use cases.

But you’re not Google. Google, for example, boasts massive scale and tackles that scale with a homogeneous technology stack and an enormous monorepo. In the industry, we talk a lot about the need to move to microservices-based architectures, and Google also heavily uses microservices. But Google, as well as other tech giants, relies on monorepos, site reliability engineers, and other approaches that really don’t apply to most enterprises.

Why? Most enterprises simply don’t have similar scale, and even fewer have the ability to enforce rigid standards across thousands of engineers. Hence, while one developer acknowledges that Google Spanner (its highly scalable database) is “amazing,” they go on to conclude, “It’s a mosquito with a sledgehammer for most workloads.” Take another comment about Google’s Bazel, a build-and-test tool that Google open sourced to mimic its internal Blaze service: “Bazel is overkill for most orgs because unlike Google we don’t all control our entire dependency chains all the way down.” For some of these projects (as with many open-source projects), ease of use and the developer experience aren’t priorities.

Web-scale authorization

Google’s Zanzibar is a classic example of this trend of aping Google in all the wrong ways. Google engineers wrote about their globally consistent authorization system in 2019. Since then, a dozen or so startups have raised gobs of VC cash to deliver on Google’s vision so that their customers can also scale to “trillions of access control lists and millions of authorization requests per second to support services used by billions of people.” Because, you know, that’s a problem lots of enterprises have.

Oh, wait. They don’t.

To be clear, authorization is a near-universal need for enterprises. That doesn’t mean it’s easy. As I wrote a few years ago, “Authorization (along with authentication) is one of the most foundational needs of developers when building their apps, but it’s … a colossal pain to deliver.” True in 2021 and just as true in 2025. It’s not surprising, therefore, that startups are desperate to help solve the authorization problem for enterprises.

Still, what works for Google won’t necessarily work for mainstream enterprises. After all, most enterprises don’t operate like Google. Zanzibar-style “authz” systems require the centralization of all data you might ever need to render an authorization decision, and this data is stored in the authorization system itself. Most companies increasingly operate in a distributed microservices architecture, without the centralized approach that fuels Google.

Authz for the rest of us

This is why Oso has been succeeding while Zanzibar clones have not: Oso offers a hybrid architecture. It centralizes shared authorization datalike roles and permissions in Oso’s cloud service and leaves service-specific data right where it is—in general-purpose application databases. Its approach is based on the messy reality of enterprise tech, not an idealized vision of Google’s internal systems. Even that vision may not be quite as “ideal” as first appears. As Oso engineers uncovered, “Some authorization data can’t be expressed as a relation between an object and a group of users. Google couldn’t even get out of their own [2019] white paper before they ran into this and modified the userset to accept an object with no relation.”

So remember: As fabulously cool as Google is, adopting the technology from its latest research paper or open source project won’t necessarily make you just as cool. Sometimes the best strategy is to learn from what Google does and try to apply some of its design thinking without straining too hard to make your IT practices fit theirs. Services such as Oso walk this line, enabling enterprises to tackle hard problems like authorization without introducing the harder problem of mimicking Google.