Why the Kubernetes Kids can't hurt Bezos' Amazon beast

Good luck, Anyone-but-AWS club. You'll need it

Kubernetes may be the hawtest thing in container orchestration, but Redmonk analyst James Governor has a different label for it: the "Anyone but Amazon" club. It's an interesting name for a club that includes, ironically, Amazon, but as AWS continues its march to enterprise IT domination, Kubernetes increasingly looks like a rallying cry for erstwhile enemies to combine against a common foe.

Good luck with that.

Remember OpenStack?

Our industry has a long, unfruitful history of banding together to stop a disparate array of 800-pound gorillas. Remember United Linux? Perhaps not, because that ill-fated attempt to combine against Red Hat never made much of a mark. OpenOffice? That was Sun Microsystems' (and, sadly, almost entirely Sun's) attempt to rally the industry against Microsoft's Office.

More recently the concern is a waxing Amazon Web Services, giving rise to an "Anyone but Amazon" club.

The club used to be about OpenStack, but that didn't go far. For years the OpenStack community ripped itself apart over whether or not it should strive for API compatibility with AWS, only to belatedly discover that all the talk of cloud-bursting and such was mostly mirage, and that OpenStack needed to focus on narrower priorities than upending AWS.

Not that OpenStack's only failing was technical, says former Googler (turned Cloud Foundry father and Apcera co-founder) Derek Collison. Collison told me open source used to comfortably commoditize old markets once they were heavily funded and well understood. OpenStack, in like manner, tried to commoditize VMware, but problems emerged as the project spiralled into warring vendor fiefdoms, incapable of aligning on key components because they couldn't agree on what OpenStack even meant.

Would-be enterprise customers, he claims, were never willing to spend money on a mishmash of open-source components. This froze out all but the most committed large enterprises while smaller startups tried to subsist on professional services revenue, then abandoned the market. As such, despite starting with football stadium-sized crowds madly chanting OpenStack's name, very few, Red Hat foremost among them, have been able to turn OpenStack into a saleable product.

In this way, OpenStack's aspirations to boom as a Linux-like community to stand against AWS went out not with a bang, but a whimper.

Round II: Kubernetes

Though Kubernetes is very different from OpenStack, and can happily be used in conjunction with it, Kubernetes, too, owes at least some of its popularity to its "Anyone but Amazon" mystique. Kubernetes gives enterprises the tools to run like AWS (or Google) without necessarily running on AWS (or Google). Released by Google as a way to foster an open-source path to the Google Cloud (nicely paved with GCP-compatible APIs), Kubernetes dramatically improves on OpenStack's unsuccessful "Anyone but AWS" offer.

Billed by 451 Research analyst Jay Lyman as a way to "create a consistent developer deployment model across on-premises and hybrid clouds", Kubernetes loosens AWS's hold on enterprise workloads, without forcing enterprises to choose against AWS.

This is one reason that Red Hat has been so keen on Kubernetes (Red Hat is second only to Google in Kubernetes contributions): built into its OpenShift product, Red Hat can now credibly claim that OpenShift is the "Red Hat Enterprise Linux" of the cloud.

As Red Hat's Daniel Riek explains on LinkedIn: "OpenShift, [built on Kubernetes and] which includes Red Hat Enterprise Linux (RHEL), extends its role as a common application runtime into the new world of orchestrated, multi-container applications and microservices architecture.

"OpenShift expands RHEL from binary runtime of an individual service up to a higher level of integration and offers a comparable experience with increasingly better capabilities than AWS alone, without the vertical integration and vendor lock-in."

With such a goal, Kubernetes has seen rising investment from those that have most to lose from AWS. Collison believes such vendor interest will quickly lead to another OpenStack implosion. "With Kubernetes Google is trying to open source the API ecosystem to drive workloads to its cloud. What happens if that doesn't work as Google wants? What if something else drives workloads to its cloud more effectively? Will Google still care about K8s at that point? Likely no."

This isn't going to happen, Apprenda executive Chris Gaun told me. "Google is not going to abandon Kubernetes. It is one of their best sellers." If smaller companies like Apprenda have been able to cash in on Kubernetes' popularity, Google is ringing the register even more often.

Still, what if, for whatever reason, Google did recuse itself from a strong Kubernetes leadership position? "Then Kubernetes will become a crazy quilt of competing interests," says Collison. "Each of the big Kubernetes contributors is in it for their own ends, steering it toward their own goals." Not so, Red Hat senior director of OpenShift product management Joe Fernandes told me: "Kubernetes is not dependent on one vendor and is not slowing down. Rather, it has a sizeable and thriving community and it is accelerating the pace of container innovation."

That community now includes Google, Red Hat, Microsoft, Oracle, IBM, Fujitsu, and a host of others. Granted, there are varying levels of love for Kubernetes within this crowd (Microsoft, for example, has tended to invest more heavily in Apache Mesos and Docker), but Kubernetes may well be their best hedge against a rampant AWS.

Killing lock-in, but softly

For enterprise customers, it's also clear why Kubernetes matters. As CoreOS co-founder and CEO Alex Polvi told me, AWS is the mother of all lock-in. Using AWS DynamoDB as an example, Polvi called it "the most proprietary thing in the history of software" because there is no open-source alternative and it's completely tied into AWS services, and only runs on AWS. While developers may love the convenience, he noted, "their only way out is to rewrite their applications."

Ask AWS about this, and they put a more positive spin on it. Deepak Singh, general manager of AWS Container Services, told me: "Most requests are for more integration, not less. Most customers want want more convenience, not less." AWS started building out its Elastic Container Service (ECS) before Kubernetes existed, and continues to offer both the ability to tightly integrate with its homegrown services as well as use external options like Kubernetes.

In fact, Polvi muses, "I wouldn't be surprised to see AWS release a Kubernetes-as-a-Service" offering as "customers are asking for it. Look closely and you'll see AWS in the Kubernetes community already," a good sign that AWS takes Kubernetes seriously. "Amazon doesn't like to waste time on open-source development."

Still, as one Kubernetes insider told me: "Offering Kubernetes as a service makes it easier to run things on AWS and also leave AWS," which doesn't exactly align with AWS interests. Nor does having an entirely open stack. Though "the value of software has shifted from the software product itself to the running of it," Polvi pointed out, having a cloud software stack fully open and available to all, filled with great technology like Kubernetes, is critical to giving enterprises a way out of "the mother of all lock-in".

Voting for convenience

I don't think it will work. Not entirely. Sure, as Red Hat director of OpenShift product strategy Brian Gracely posited to me: "Hybrid cloud will be the dominant buying model for the next decade" as enterprises struggle to juggle where they want to go (public cloud) with where they are (data centres all the way down). But a rising percentage of workloads will go to the public cloud, which means they'll mostly find their way to AWS, the clear cloud leader yet again (and by a long way) in Gartner's annual Magic Quadrant ranking.

This will continue because, as Singh underlined, convenience is king (or queen) with developers. Kubernetes will absolutely fill a hole in managing containers at scale, but developers' initial lines of code are more likely going to be written on AWS than anywhere else going forward.

This won't stop the Red Hats of the world from selling products like Kubernetes-based OpenShift as a common application layer, and to good effect. Kubernetes in this world becomes ever more relevant and important.

But none of it promises to make the "Anyone but Amazon" train a superior experience to the AWS cloud, given its promise of tight integration between its own proprietary services and close collaboration with third-party services on its platform, including Kubernetes. Every good hegemony eventually meets its end, but it's not yet remotely clear what will come along to displace AWS. Kubernetes, far from doing that, will simply give it another way to onboard applications. ®