Tariq Islam
May 21, 2018 · 5 min read

Running like Google is more than Kubernetes products or a nice UI.

You can’t just do things to this.

In my last post I talked about the dichotomy of how we evaluate technologies versus how we seek them out to enable us. TL;DR on that: Google has long seen tools and technological innovations as derivatives of its culture and its drive to deliver in the best way possible. The “magic” of how Google operates is not so much in its incredible technology, rather it is the culture of Google that permeates into the adopted technology and that enforces a cycle of improvement through that adoption. This realization is the vision that Google has for other organizations and it is this vision that is espoused in Google releasing Kubernetes to the world, as well as through the Google Kubernetes Engine.

And therein lies the rub. If the success of Kubernetes is any indication, the way Google delivers and manages all of its workloads is validated across industries and use cases. Kubernetes is more than just an open source project for container orchestration, it is a legacy of how Google runs and operates at any scale. The thought of being able to run and operate like Google is tantalizing, and such thoughts are made into potential realities with the adoption of Kubernetes.

And therein lies another rub. Adoption of Kubernetes is on an incredible rise, seemingly unstoppable, and yet the pains of adoption are as consistent as the sheer popularity of the platform. It is getting to the point that, as with my point on technology adoption in my previous post being an accepted pain point, we are accepting that Kubernetes is just hard to operate and maintain. Even distributions of Kubernetes that provide automation tools to make things easier still fall short. Here’s why.

When an organization chooses to adopt a technology, they are invariably accepting a certain level of overhead in introducing the tech into the following impacted areas:

  • Team skill sets: This is as much of an issue of enabling as it is about stretching people thin.
  • Organizational processes***: Introducing a technology will offer the opportunity for an organization to improve its processes. This is almost always non-trivial, but always fruitful for those that elect to take the opportunity and run with it.
  • Status quo of day-to-day operations: You’re asking your team, with a finite skill set (see first bullet), to take on additional responsibilities of not just managing and maintaining the new technology, but everything that has to go into supporting that technology. Whether it be infrastructure or even the automation that’s put in place for assisting with day to day operations, it is still an overhead that gets into your head and stays there.

*** We are going to be focusing on the impact to organizational processes because this is the most significant and the most difficult to change or improve. Google’s Kubernetes Engine mitigates the other two. Here’s how:

  • Team skill sets & Status quo of day-to-day Ops: GKE introduces a push-button provisioning capability that immediately, with assurances and SLA’s, provides any number of enterprise-grade Kubernetes clusters managed and maintained by Google’s own SRE team. This offers the organization’s teams the opportunity to be more laser focused around using Kubernetes, and learning how to use it, versus having to deal with any of the low-level plumbing whatsoever. There’s nothing to set up, nothing to procure, and no automation to manage. The result is just about the most minimal overhead you can imagine with adopting enterprise-grade Kubernetes.

The reason GKE is designed this way is because we at Google have been running on the tenets and principles of Kubernetes as well as managing systems like it before it even existed. Just as our best practices for deployment management and orchestration have manifested themselves in Kubernetes for the world to consume, so have our best practices and methodologies for maintaining and managing the technology itself been manifested into GKE.

The Borg, as a primary example, is leveraged as a service for internal development and deployment, where teams do not have to manage or even automate their own clusters. We didn’t get to 4 billion containers per week by having teams manage their own Borg. Even with the best automation in place, it’s not a sustainable or scalable approach.

Just as we at Google are enabled to do more with our methods of adoption, so are you with GKE.

And that’s what it means to run like Google. It’s not the technology itself, but how we deliver that technology in a way that makes it easier to adopt and utilize at scale. That ease of adoption provides breathing room for the other two impacted areas. When I can provision a secure production grade cluster and start using it within two commands, that is an incredibly empowering thing for the individual, the team, and the organization. It allows me to think about how I can inject it into all kinds of processes for improvement, as well as how best to start enabling the overall organization with respect to skill sets to take advantage of these improvements immediately, without a significant ramp-up. As in my last post, here’s how quickly you can get up and running with an enterprise Kubernetes cluster on Google:

$ gcloud container clusters create my-cluster --zone=<pick a zone>

$ gcloud container clusters get-credentials my-cluster

$ kubectl run something-awesome ....

Google, from the SRE perspective, treats each and every GKE cluster as production.

The bad news is that there is no technology or tool in the world today or in the future that’s going to do the work of changing your organizational culture for you. The willingness to embark on that path of improving processes is entirely up to the stakeholders of your organization. But as with how Google operates, GKE can make that journey far easier than any other distribution out there. In my next post, I’ll walk you through the different ways GKE can offer the opportunity to run your organization better through flexible choices of adoption. We’ll look at different organizational use cases and see how GKE can quickly, securely, and easily fit into the vision that is being targeted. We’ll also start getting more hands on.

Google Cloud Platform - Community

A collection of technical articles published or curated by Google Cloud Platform Developer Advocates. The views expressed are those of the authors and don't necessarily reflect those of Google.

Tariq Islam

Written by

Father, Engineer, Googler. All posts and opinions are my own.

Google Cloud Platform - Community

A collection of technical articles published or curated by Google Cloud Platform Developer Advocates. The views expressed are those of the authors and don't necessarily reflect those of Google.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade