The Google SRE Chapter 2 — The Production Environment, Through an SRE's Eyes

In the first chapter, we talked about why SRE exists in the first place. In the book's second chapter, the focus shifts to something more concrete: how Google's infrastructure actually works, physically and architecturally. I'll walk through it here and add my own take along the way.

Hardware: Ordinary Machines, Extraordinary Software

Google's data centers aren't built on expensive, "enterprise-grade" hardware. Quite the opposite — they run on commodity servers. The message here sets the tone for the rest of the book: reliability doesn't come from a single flawless machine, it comes from a software layer designed to tolerate failure. Hardware will fail, obviously. That's not an edge case — it's the starting assumption the whole system is built on.

Inside a Data Center: Clusters, Borg, and Storage

As most of us already know, the machines in a data center are grouped into clusters, and those clusters are managed by a system called Borg. Borg's job is straightforward on paper: decide which job or task runs on which machine, allocate CPU and memory, and restart anything that crashes. Anyone reading that sentence today will have the same reaction — that's exactly what Kubernetes does. And that's not a coincidence: Borg is Kubernetes' direct ancestor and the thing that inspired it.

On the storage side there's Colossus, Google's distributed file system. Built on top of it are distributed databases like Bigtable and Spanner, both mentioned in this section — Spanner in particular stands out for achieving strong consistency at global scale.

Networking: Google's Own Backbone

Data centers connect to each other and to the rest of the world over Google's own private backbone network. There are two kinds of traffic to think about here: traffic between data centers, and traffic being routed from a user to whichever data center is closest or best suited to serve them. That second piece gets a much deeper treatment later, in the load balancing chapters.

The Other Building Blocks an SRE Relies On

The chapter introduces a few more systems that keep resurfacing throughout the book:

• BNS (Borg Naming Service) — the service discovery layer
• Chubby — used for distributed locking and small pieces of configuration data
• Protocol Buffers — the serialization format services use to talk to each other

Why This Chapter Matters

The real point of this chapter is to draw a map. When something goes wrong — say, a service slows down — an SRE needs to be able to tell whether the problem is in the hardware, the network, a scheduling decision Borg made, or the application code itself. Making that call requires actually understanding how every layer underneath works. In that sense, this chapter is really a prerequisite for the troubleshooting and monitoring chapters that come later.

Through a 2026 Lens: Same Ideas, Different Names

What's most striking about reading this chapter today is that none of this architecture disappeared over the past decade — it became the industry standard.

• Borg → Kubernetes. This isn't just an analogy anymore, it's a direct lineage. Some of the engineers who designed Borg later became architects of Kubernetes. Anyone working with Kubernetes today is, in effect, using an open-source, community-built version of something that was Google's internal system a decade ago.
• Chubby → etcd / ZooKeeper. The need for distributed locking and a configuration store never went away — Kubernetes itself runs on etcd under the hood.
• BNS → Kubernetes Service / DNS. Same service discovery problem, just solved today through in-cluster DNS and Service objects.
• Spanner's legacy might be the most interesting of all. The Spanner paper, published in 2012, changed how the industry thought about achieving strong global consistency in a distributed system. Open-source projects like CockroachDB and YugabyteDB are built directly on the ideas it introduced.

What's genuinely interesting here is that Google had already solved these problems a decade earlier — the solutions just stayed locked inside the company. Kubernetes going open source in 2014 was the real turning point that let the rest of the industry in on the secret. Reading this chapter today, you're really reading the DNA of the system we talk to every day through kubectl — just in its earlier, unnamed form.

One more thing worth adding: the "commodity hardware plus smart software" philosophy is now simply the baseline assumption of the cloud-native world. Nobody running workloads on AWS, GCP, or Azure today stops to think about which physical machine they're on. That abstraction feels so natural now that the fact this chapter, back in 2016, still had to spell it out is itself a measure of how far things have come.

Closing Thoughts

The second chapter works as a dictionary and a map for everything that follows in the book. But looking back from today, it turns out this wasn't just a Google-specific dictionary — it was an early draft of the language the entire infrastructure industry would end up speaking.

Thanks for reading, and see you in the next one.