Developers love software containers because they let you write an application once and run it anywhere, from your laptop all the way up to a big public cloud like Google’s, without needing to change a single line of code. It’s simple and powerful, and makes it easy for coders to be productive without worrying about the servers they’re running on.
In fact, software containers are such a good idea that Google has put them to use for the better part of a decade behind the scenes to run literally every piece of its own websites. As of last year, Google makes two billion new containers a week, as reported by The Register.
That’s because, while Docker may have made the idea of containers easy for average developers to use, a more basic version has been a feature of the Linux operating system for servers for many years.
Google developed containers out to suit its own needs early on in its corporate lifespan, and has been building on the concept ever since.
Playing the movie
“We often say ‘we’re playing the movie,'” says Google Senior Staff Software Engineer Brendan Burns.
In other words, everything going on with Docker and software containers right now is something Google has dealt with itself, one way or another.
Almost exactly a year ago, Google released Kubernetes (Greek for “Pilot” or “Helmsman”), a piece of free software for managing containers of which Burns led the development. It was designed to take a lot (but not all) of the stuff that Google uses to wrangle its own container usage and package it up in a way that developers could take advantage of with Docker.
Kubernetes has made Google kind of a rockstar in the Docker world — one of the world’s largest technology companies is offering tools and expertise to help developers crest a growing wave. That love has encouraged Google developers on to keep engaged with the Docker community, Burns says.
“So many people at Google never get to talk about what they do,” Burns says, but Kubernetes has thrust a lot of the back-end stuff that never gets any glory straight into the spotlight.
In fact, right before our conversation started, a random DockerCon attendee wanted to take a selfie with Burns (he acknowledged it was weird, but guessed that there was a scavenger hunt going on for DockerCon on-stage speakers).
From a more mercenary standpoint, Burns says his job is “to sell data centres.”
Kubernetes and the Google Container Engine service, which takes Kubernetes and automates a lot of it for heavy-duty business users, launched into beta at DockerCon this week. Those are big features to draw users to the Google Cloud Platform, where customers can swipe a credit card and get access to huge amounts of computing power hosted from Google’s big old data centres.
Down from the mountain
At the same time, Burns says that the last thing he wants to do is come to conferences like DockerCon and tell developers the best way to take advantage of containers. After all, most Docker users are approaching a completely different set of problems, and Google is willing to learn.
“We don’t have all the answers,” Burns says. “We did it one way, but that doesn’t mean it’s the right way.”
At Google, Burns says, building software is an internal affair. If, on the backend, a Google developer is having an issue with a database or web server not running quite right, you have to call the person in the company who developed that service in the first place and get them to fix it. It’s all Google stuff talking to other Google stuff behind the scenes, Burns says.
Outside of Google, though, apps are built from a lot of moving parts that can come from many different vendors. One part of the app might use a MySQL database, and another might use a Redis database, and the way they “talk” to the main app can be totally different from each other.
“The way the world builds applications is different from how Google builds applications,” Burns says.
Burns describes this as a very classic Google sort of problem: The mismatch between how Google likes to do things and how the rest of the world likes to do things.
He cites an anecdote of how internally, Google loves long, drawn out Gmail conversation threads that can go into the “hundreds.” But according to Burns, the Gmail team found that the average thread length outside of Google is just over one single, solitary message.
In short, Google has a lot to learn from watching how people use technology in production.
Google thinks you’ll pick its cloud
Docker and other software containers have this huge potential to upend the cloud market. Since your code can run anywhere, there’s nothing stopping you from picking it up from one cloud vendor and dropping it elsewhere.
Even Google’s Kubernetes, which again is free software, can be run in competing clouds at the developer’s whim.
That’s not really a problem for Google, though. Burns says that with its container know-how, and everything it’s learned by being a part of the community, Google Cloud Platform will be the best place to run these Docker containers — even as competitors like Amazon Web Services and Microsoft Azure look to include container support on their own platforms.
“Running those things on the Google Cloud just makes more sense,” Burns says.
Still, Docker is a fast-growing startup and a fast-growing technology, and Burns says that even if he’s seen this movie before, there are still plenty of twists and turns to come.
“I don’t know the ending this time,” Burns says.