According to some reports, Amazon Web Services (AWS) feels threatened by Kubernetes, and not because Kubernetes has become a rallying cry for the “Anyone but AWS” club. As Kubernetes becomes the industry’s default way to manage containers, and as the enterprise goes gaga for containerization, Kubernetes gives enterprises a way to run workloads across different clouds–not merely AWS.

AWS, apparently, is now building a Kubernetes service, though the company refused to confirm or deny this when I asked. In so doing, AWS is likely responding to Kubernetes’ promise well beyond orchestrating containers. That may be short-sighted. As Bitnami’s Sebastien Goasguen told The Register, Kubernetes “should be seen as a platform you can build on,” and not merely a container tool.

Clear and present danger

Inside sources who do business with AWS have revealed that apparently AWS “feels threatened” by Kubernetes because “they don’t own it.” This may be true in part, but AWS builds services with lots of open source code that it doesn’t own, per se: RDS is just one prominent (and profitable) example.

With Amazon’s ECS service paling in popularity in comparison to Kubernetes, it would make sense for AWS to get deeper into the Kubernetes game. As CoreOS (and Kubernetes contributor) CEO Alex Polvi highlighted in an interview with me, “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. Amazon doesn’t like to waste time on open-source development.”

SEE: Why Kubernetes may be a bigger threat to Amazon than Google’s cloud (TechRepublic)

In other words, AWS’ commitment to Kubernetes indicates a deep and abiding interest in the technology.

The reason, however, may not be tied to containers. I would hazard a guess that the truly threatening thing about Kubernetes is that it promises to be such a broad platform, one that makes it easy to take workloads away from AWS and run them, for example, on Google Cloud, where they allegedly run better. But it’s not just about containers.

The everything platform

Kubernetes has much more promise than its day job as a container management tool. 451 Research analyst Jay Lyman touched on this when he wrote that Kubernetes can help to “create a consistent developer deployment model across on-premises and hybrid clouds.” In other words, companies can use Kubernetes to power workloads on AWS…but also to take those workloads elsewhere. With Kubernetes, it becomes straightforward to orchestrate containers wherever they may live.

Or to build out a mesh network. Or to manage a database, as Goasguen noted:

By using third-party resources, you can extend Kubernetes and build your own API. For example, if you can use Kubernetes to manage a database, you can define that database as an object; the API gets extended and recognises the database.

SEE: The cloud war moves to machine learning: Does Google have an edge? (TechRepublic)

According to Ocado’s Mike Bryant in an interview with The Register, Kubernetes’ value goes beyond its pliability. It also affords the opportunity to run demanding workloads on decidedly undemanding hardware: “Most people run Kubernetes on high-performance servers, we run it on PCs – it’s a very dramatic cost saving. And it’s not just the servers, we don’t need enterprise network cabling, we don’t need high-end networking kit, we save on cooling – we’re really cutting costs.”

Kubernetes role as the default container orchestration platform would be enough to signal danger to AWS. But Kubernetes’ expanding option as a broad platform makes it even more important that AWS not merely offer Kubernetes as a hosted option, but to deeply integrate it into the AWS fabric. As such, we should expect to see AWS engineers contributing more code to Kubernetes as it seeks to become an influencer on the project.