Why containers. Why now.

SCALE: What is your role at Google? There has been some speculation about it, but not a lot of real public discussion.

Eric Brewer: I am working on stuff related to Kubernetes and containers. That’s a project I care a lot about and am certainly pushing Google to do more in that direction. That’s actually very exciting to me.

What was your relationship with containers prior to Google?

The original work that I did on clusters that led to Inktomi predates virtual machines — at least the modern reincarnation of virtual machines. As a consequence of that — and this is true for Google too, which was started in 1998 and which is roughly the same age as the modern version of virtual machines— there was no notion of virtual machines for building services.

You built on the raw hardware. Inktomi and also early Google ended up using essentially a Unix process model and doing everything in terms of processes, running many processes on the same piece of hardware. In fact, Google didn’t use virtual machines really at all until it started doing some corporate stuff where it wanted to run third-party things. But all the internal stuff never used VMs.

“The number of people contributing and commenting [on Kubernetes] is actually, frankly, a little too much to manage.”

In parallel with that, of course, the whole IaaS revolution happened and that was built on virtual machines. So, in a sense, the open source world had to build with virtual machines as its basis, and a lot of the tooling and management was based around how do you operate and manage virtual machines.

In some sense, the container work and Kubernetes are a return back to the original way we did it, which was at this higher level of abstraction. And, in fact, what happened within Google was people were using Linux containers to try to get performance isolation for these different jobs running on the same machine. That’s kind of why containers are very fundamental to the way Google operates.

But really, if you squint, the real reason is because both Inktomi and Google predated the widespread use of virtual machines, so that wasn’t even a tool in the toolbox.

This all kind of sounds like the talk around “utility computing” in the early 2000s revisited, with the idea of getting rid of the server as the unit of measurement.

That was certainly my view starting around ‘97. I talked about that general topic, and I still believe that. We’re just kind of now getting there, in some sense.

The Kubernetes architecture: Source: Google

So have you been surprised by how popular Kubernetes has become already?

I’ll admit that I have been. I thought it would be successful and we planned around it being successful, but at the same time, the number of people contributing and commenting is, frankly, a little too much to manage.

There’s so much excitement we can hardly handle all the pull requests. I think we’re committing, based on the GitHub log, something like 40 per day right now, and the demand is higher than that. Each of those takes reviews and, of course, there’s a wide variety of quality on those. Some are easy to review and some are quite hard to review.

It’s a success problem, and we’re happy to have it. We did scale up the team to try and improve its velocity, but also just improve our ability to interact with all of the open source world that legitimately wants to contribute and has a lot to contribute. I’m very excited that the velocity is here, but it’s moving so fast it’s hard to even know all the things that change day to day.

What is the relationship between Kubernetes, Borg and Omega (the two internal resource-orchestration systems Google has built)?

I would say, kind of by definition, there’s no shared code but there are shared people.

You can think of Kubernetes — especially some of the elements around pods and labels — as being lessons learned from Borg and Omega that are, frankly, significantly better in Kubernetes. There are things that are going to end up being the same as Borg — like the way we use IP addresses is very similar — but other things, like labels, are actually much better than what we did internally.

I would say that’s a lesson we learned the hard way.