This article is more than 1 year old

Look at stupid, sexy Kubernetes with all the cloud firms hanging off its musclebound arms

The container war is won – but what now?

Red Hat, better known for its Linux distro despite years of work in middleware and Java, last week pushed further into cloud through the purchase of CoreOS for $250m.

CoreOS is a 130-strong container startup known for its enterprise-oriented Kubernetes platform Tectonic, the Quay container registry, Container Linux and a distributed data store for Kubernetes called etcd.

Score one more for Kubernetes – the Google-spawned cloud orchestration system has gained major traction in the past year. Kubernetes is under the wing of the Cloud Native Computing Foundation (CNCF).

According to James Strachan, senior architect at CloudBees and self-proclaimed fanboi, Kubernetes is the coolest kid at the party.

"It's completely game over. Kubernetes has won. That's not even in doubt anymore," he said. He loves the cloud orchestration tool because it solves the biggest problem facing companies that want to deploy in a cloud-agnostic way.

"A developer can take any application, package it in a Docker container, describe it with declarative YAML for all the things that developers know about – environment variables, ports, file systems and so forth – and then run it on any public cloud with zero lock-in."

Others point to the broad support that the CNCF gathered for the tool by adopting a professional and inclusive approach to the open-source project. One of them is Chip Childers, CTO of the Cloud Foundry Foundation.

Cloud Foundry is a web-based marketplace for cloud-native developers, which also includes its own cloud orchestration offerings. Its Container Runtime exposes containers to developers using BOSH, which is its own enterprise-friendly Kubernetes-based container runtime manager.

"They did an amazing job of focusing on building the community around the tool," said Childers.

Partying in the cloud

The real wins that guaranteed Kubernetes' fortunes were with public cloud service providers, said Clive Longbottom, co-founder of analyst firm Quocirca, who wrote the book on the evolution of cloud computing.

Kubernetes really does have a lot of friends in the public cloud. In 2017, Amazon announced support for Kubernetes in its Elastic Container Service, while Microsoft rolled out Kubernetes support in its Azure Container Service. Oracle also now supports it with the Oracle Cloud Infrastructure, and IBM invited Kubernetes to its own Cloud Container Service party in May 2017.

These firms are all now CNCF members, providing money and hopefully ongoing support for Kubernetes. It will also create a pull-through effect where companies begin using the technology everywhere, said Longbottom.

"I think that a lot of companies find themselves using Kubernetes because it's going to be built into the AWS's and the Azures and so on," Longbottom said. "So if you're going to be looking at a hybrid cloud then you might as well be putting Kubernetes in place in your private cloud environment, because you'll be able to plug far more easily into the public cloud component of the hybrid."

Still adolescent

While it may be the popular kid in the container orchestration world, Kubernetes is still young, with some growing up to do. "In many projects I've done implementing Kubernetes-based cluster for customers, there has been a lot of work around productionizing it, making sure it's stable, and putting in all the work around the core to make it usable by that business," said Jeremy Bartosiewicz, cloud architect lead at Cloudreach, a professional services company focusing on cloud implementations.

A video interview with Aparna Sinha, group product manager for Kubernetes at Google, suggested the same. A priority for the community behind Kubernetes is moving it towards an increasingly stable core.

Service fabric

That ongoing effort is predictable for a relatively young open-source project, though. A more interesting one is the move towards a service mesh, which was a talking point at KubeCon in December. The idea is to extract network and other system services from applications and put them into a glue that sits between the containers.

These service mesh platforms feature a data plane and a control plane. The former consists of proxies that communicate between a container-based microservice and the rest of the container universe. They handle things like service discovery, health checks, authentication and encryption. They're the worker bees. The control plane is the queen that tells them what to do.

"The service mesh concept is about putting something between those containers and talking to something to get an aggregated picture of everything," said Bartosiewicz. That would help to solve the problem of monitoring potentially tens of thousands of individual containers in a cohesive way, but it isn't just for that.

"There are various use cases. Some could be for monitoring, others could be for security, and others could be providing another layer of functionality which is abstracted away from the developer."

That's increasingly important, Bartosiewicz argued, as developers start to spit out the DevOps Kool-Aid. It's all very well to shatter the glass window between developers and sysadmins, but that forces the devs to start worrying about what they're running on, when all they really want to do is just write the darn code and have it run anywhere.

By abstracting infrastructure considerations from the application code, the developer can write for the container and then give to the operations side, he argued. It also gets us closer to an AWS Lambda-style serverless computing concept, where you just code your app and let the infrastructure handle the basic services it needs without having to worry about library imports, dependencies and the like.

"I think the next step of evolution is for Kubernetes to become a serverless platform," said Strachan. "There will be more tooling to hide Kubernetes from those that don’t want to see it."

One project that several experts talked up to The Reg was Istio. Launched in May 2017 by Google, IBM and Lyft, it's a service platform for container environments that could give Kubernetes and its rivals a boost in the race to service meshery. It includes its own service discovery and load balancing tools to help grease the inter-container wheels.

"For us a big theme is interoperability and integration. The Istio project is a great example of something that has a really good design for a service mesh data plane model for container-to-container communication," said Childers. "It was designed not just to be a Kubernetes project, but it can fit into other environments." That includes Cloud Foundry's own, and others like Mesos.

There is a lot of activity around service mesh. In addition to Istio, there's an ultra-light Kubernetes-specific service mesh called Conduit, which rolled out at KubeCon in December. It's an evolution of Linkerd, a CNCF-housed service mesh that supported several platforms.

Business focus

Service mesh is one example of many third-party components supporting Kubernetes, and that's an important part in its development. These services handle everything from network connectivity (CNI) through to Notary (security) and Jaeger (distributed tracing).

However, it will take more than a diverse and vibrant tooling layer to get Kubernetes enterprise-ready. Someone needs to make it more digestible for enterprise customers.

One of its biggest challenges today is that it is still a "hyper-techie product", said Longbottom. You wouldn't want to let a business analyst anywhere near it. He says this stands in stark contrast to other orchestration products such as Automic, which CA snapped up at the end of 2016.

Today, developers define their primitives and services in Kubernetes using YAML. It takes the YAML-based description file and translates it for whatever cloud-based environment it is running on, setting up the appropriate virtual infrastructure for your workload.

That's nice, but Longbottom would like to see things go further still. In his ideal world, a business analyst, rather than a geek, would be able to describe what they needed. Kubernetes would just go out and do it.

You want a dynamic website drawing data from a NoSQL database, processing streaming data from an online service somewhere? You expect 10,000 visitors in the first week, but that might double? No problem; you can describe that in some non-techie language, and Longbottom's dream container orchestration system would just go and set that up for you.

That's the dream, but as Longbottom points out, few if any products are doing that today. "That's the next stage, not only for Kubernetes but for the group of companies around Kubernetes," he said. "It gives you that flexibility for the workload to run at the right time, in the right place, so that the business has full control over the economics and the risk and everything else around it."

Watching the wallflowers

While the Kubernetes community grows and introduces more tooling for what is now the dominant orchestration platform, what of its competitors? Those we spoke to pointed to Docker's announcement of Kubernetes support as an effective death knell for Swarm.

Nevertheless, there are others. Mesos is still there, as is Hashicorp's Nomad.

There isn't much traction for the other tools, said Strachan. "The one area where other tools could be used is when people have on-premises legacy stuff where you just want to boot up some VMs or something."

Let's hope these alternatives don't just go away. No one likes a monopoly, even if it's a friendly, community-driven one. They may have to find niche areas in which to excel and beat out the Kuber-beast, though. That might take some thinking about. ®

We'll be covering DevOps at our Continuous Lifecycle London 2018 event. Full details right here.

More about


Send us news

Other stories you might like