Making Kubernetes work for the average engineer—via PaaS

Despite being the hottest thing since, well, Docker, Kubernetes remains a dark art for most mainstream enterprises

Making Kubernetes work for the average engineer—via PaaS
Thinkstock

Too consumed with your OpenStack deployment to put a Kubernetes cluster on the blockchain? Not to worry: Most people are still trying to figure out Kubernetes. Despite being the hottest thing since, well, Docker, Kubernetes remains a dark art for most mainstream enterprises. Birthed by the engineering gods at Google, Kubernetes still has a lot of abstractions to learn before it will be approachable by an average engineer.

Which is fine, because most developers won’t have to bother. The great thing about technological complexity is that there are companies set up to remove it. Indeed, as one HackerNews commentator said, “Most startups—most large companies—would be far better served with a real PaaS, rather than container orchestration.”

Fortunately, we have a few vendors doing just that.

Do you really want to be like Google? Then deploy your own Kubernetes

Google, where Kubernetes was born, has big data problems that most companies can hardly even imagine, much less replicate. Even so, as companies struggle to deal with rising data levels, technologies like Kubernetes seem like a good idea.

“Seem” being the operative term.

It’s not that Kubernetes is bad technology, or even a bad idea. It’s just that it’s pretty complex. As Google’s David Aronchick has made clear, there’s only so much simplicity you can bring to Kubernetes, given what it aims to solve: “Distributed systems arehard. I’m not sure how much you can reduce complexity without being a black box.” Joe Beda, CEO of Heptio and part of the founding Kubernetes engineering team, said it this way: Kubernetes “was based on lots of experience at Google but that experience doesn’t always translate.”

Google engineers, in other words, took what they knew about running containers at scale and tried to encapsulate that learning in Kubernetes. Part of the problem buried in that statement is that these engineers (like Beda) grew up with Google infrastructure, working with complex systems and perhaps not quite understanding how to make it less complex for others with different backgrounds. As he went on to state, “As engineers, we tend to discount the complexity we build ourselves vs. the complexity we need to learn.”

Datadog engineer Jason Moiron followed up with this: “In the real world, these biases are amplified because ‘things we build ourselves’ is actually ‘things we already know,’ and this includes ‘things we already learned.’”

Which means, I suspect, that you’d be well-served by going with a trusted vendor that abstracts the complexity of Kubernetes (or insert your-technology-of-choice here) for you. Someone that turns it into a PaaS or, yes, a “black box,” like Aronchick posited.

Make Kubernetes easier: Google and Red Hat are doing their bit

As easy as it is to become blinded to complexity by having too close a familiarity, with an open source project like Kubernetes it’s even more dangerous to try to tame it from a distance. It’s one thing to spot problems that linger in Kubernetes; it’s quite another to actually be able to dig into the code and fix it. For that ability to fix Kubernetes, Google and Red Hat are the top contributors by a significant margin and thus are best positioned to make tangible improvements.

For its part, Google makes it straightforward to run Kubernetes as a managed cloud service (via Google Kubernetes Engine). Although most Kubernetes workloads actually run on Amazon Web Services, Google has a strong claim to knowing how best to tweak the underlying open source project for developers and to streamline the running of Kubernetes in its GKE service.

As enterprises kick the tires on Kubernetes and discover just how difficult it remains, I suspect we’ll see more companies try Google Cloud Platform as a way to escape some of Kubernetes’s complexity, especially because Amazon’s announced Elastic Kubernetes Service still doesn’t exist. (This is an anomalous example of AWS pre-announcing a nonexistent service. Usually AWS announcements are accompanied with the URL of a live service. Not so EKS, a testament to AWS perhaps surprised by just how fast momentum around Kubernetes was moving.)

Red Hat, the other big Kubernetes contributor, goes a bit further than Google in terms of turning Kubernetes into a PaaS offering: OpenShift. Red Hat president Paul Cormier identifies Kubernetes/OpenShift as a platform that “provides consistency and abstraction, enabling IT teams to focus on embracing innovation rather than trying to desperately integrate legacy technologies with screaming-fast emerging cloud services.”

There’s undoubtedly some hype in that statement; the reality of blending cloud-specific services like AWS Lambda with datacenter-tied workloads is messy and hard—but aspirationally it’s the right direction. Enterprises want a common platform to tie together their inevitably hybrid IT environments. Kubernetes can help, particularly if a provider like Red Hat can help to alleviate its complexity.

It may be, as Moiron argues, that “the Kubernetes elevator pitch is straight up dogshit,” too overblown with marketing hype to ever live up to its lofty promises. And yet Aronchick is almost certainly correct to counter that Kubernetes “actually solves the ‘we need to do what Netflix does, but do it with 100X fewer engineers’ by implementing declarative config, service discovery, health checking, gradual rollout, key management,” and other services.

Perfect? No. Perfectly implemented? Absolutely not. And yet plausible, with companies like Google and Red Hat actively contributing to the underlying open source project to improve Kubernetes for all, even as they build out higher-order services to make it even easier to consume for their customers.

We’ll undoubtedly see even more companies get involved, including Heptio and others. That’s for the good, as competition is ramping up to simplify Kubernetes for mere mortals (and the enterprises that employ them) to use.

Copyright © 2018 IDG Communications, Inc.