Google on the Inevitable Future of Container-Based Architectures
Container-based microservices are not just for web-scale companies, they also will be the best choice for enterprises as well, asserted Google product manager Craig McLuckie, in a talk at the CoreOS Tectonic Summit in New York, held earlier this month.
“It’s not obvious until you start to actually try to run massive numbers of services that you experience an incredible productivity that containers bring,” McLuckie said.
This container-based architecture will soon become all but inevitable for enterprises, by McLuckie’s reasoning. Should such a future come to pass, it would bring major sea change in how enterprises run their IT operations. Supporting this new architecture was the motivating factor behind Google’s creation of the Cloud Native Computing Foundation (CNCF), which now oversees Google’s open source Kubernetes container management application.
Google is a big user of containers, relying on them for pretty much all of their infrastructure operations. It launches about two billion containers a day. Containers “have given us a set of characteristics around how we build and operate our data centers. It’s pretty central to our operating model,” McLuckie said. Moving to a container architecture has given the company radical performance and efficiency improvements.
Most enterprises are today where Google was about 10 years ago, he said, and it was not an easy time for Google engineers then. In fact, they prefer not to speak those days, he said. If questioned, they twitch nervously and try to change the subject.
They were “struggling to maintain the velocity,” as Google continued to grow by leaps and bounds, McLuckie said. But all this consternation led Google engineers to heavily ponder the most effective architecture for the company’s “incredibly aggressive growth.” What is the most effective way of getting work onto a given machine? And how could a machine be partitioned so it can be run to its fullest efficiency?
The approach they came up with Google now calls “cloud-native computing,” or “type B cloud computing,” to separate from the initial forays of cloud computing in which customers, or internal business units, were basically offered server space carved up into virtual machines.
The new approach offered computing, not computers, which was a jarring concept for the time, McLuckie admitted. But containers were instrumental because they solved the gnarly problems of provisioning and deployment. They provided an encapsulated environment in which applications, or pieces of applications, could be placed.
“That solves a lot of your operational problems right there,” he said. The applications themselves didn’t even need to be in a single container. Different pieces of the software could be decoupled from one another and each would get its own container.
The most powerful aspect of this assembly-line approach is that “it allows you to create a specialization of operations,” McLuckie said. This would encourage reuse of resources, and developers could specialize in each part of the stack. They would no longer need to worry about all the aspects of operationalizing their applications.
The developer’s “responsibility ends where the cluster starts,” McLuckie said. This specialization in turn allowed Google to create much more complex systems.
While Google was devising this microservices architecture, Facebook, Twitter, and other web-scale companies were all working on surprisingly similar approaches. They “all co-evolved the same basic pattern of container-based, dynamically-scheduled microservices architectures,” even if they all had different names for the different components, McLuckie said.
While this made sense for web-scale companies, this approach will increasingly make sense for enterprise companies as well, McLuckie argued. Many are building up Internet of Things-styled sensor networks, which will produce a tsunami of data and require a sophisticated set of computational support of the backend.
Containers are only a part of the solution, however. “Docker will give you an amazing first five hours,” McLuckie said. After that, the focus of operations will quickly switch to other concerns. You also need dynamic scheduling software to understand the operational characteristics of the application and make smart decisions about where and how to run these applications for maximum efficiency and resiliency.
Companies also need a way to controlling and managing large numbers of containers. This is why Google-developed Kubernetes. Kubernetes “is our view of cluster management to the world. It is simple, it’s modular, it’s extensible,” McLuckie said. “It’s our way of thinking about infrastructure management and deploying applications.”
Google engineers don’t treat containers as individual objects, but rather as building blocks for larger applications, with each container holding a separate component of the application as a whole. Different parts of an application may have different resources demands, such as more processing, or I/O. So packaging them separately allows for more efficient use of resources. It also makes it easier to upgrade components without taking down the application as a whole. In Google, applications are assembled from large numbers of containers, into a single identity, called a pod, which is accessed through a single IP number.
To help the rest of the world adapt to similar approaches, Google has open sourced many of the technologies it has developed around this architecture. Much of the work the company did on new technologies such as control groups, needed for resource isolation, was released as open source modifications to the Linux kernel.
“We were tired of explaining why we wanted upstream kernel changes. It was a lot easier to explain if we just contributed the technology as open source,” McLuckie said.
Google released Kubernetes in part to help organizations set up their own operations. CoreOS itself offers a commercially supported version of Kubernetes called Tectonic–hence the reason for this conference. The beauty of Kubernetes is how easily it can run anywhere, McLuckie asserted. It can be deployed on Amazon Web Services, or on an OpenStack implementation.
Google is hoping the software will become a de facto standard for managing containers, which is why the company offered Kubernetes as the seed technology for CNCF.
“The intent is to establish a standard through code rather than spec,” McLuckie said. The approach “is not to create big top-heavy specifications, and expect people to implement those specifications. The intent is to find working code solving real problems, and use that establish a semantic standard, and then promote that API as an API standard,” McLuckie said.
CoreOS and Docker are sponsors of The New Stack.
Feature Image: Craig McLuckie at Tectonic Summit. Photograph by Ben Hider.
