Kubernetes is booming, but consolidation is coming

Source:-zdnet.com

The crowded halls of the official Kubernetes conference Kubecon reflect a nascent but important technology whose best future might be to disappear into the background.

Kubernetes is an important part of the future of computing infrastructure, because containers are an important new tool for the way we build applications.

CLOUD
Microsoft acquires cloud file-migration specialist Mover
Red Hat OpenShift 4.2: Kubernetes for the hybrid-cloud developer
Top cloud providers 2019: AWS, Microsoft Azure, Google Cloud
Adobe’s cloud pivot: What we’ve learned (ZDNet YouTube)
Buy a Google Pixel 4, get 3 free months of Google One (CNET)
How to calculate AWS costs and avoid paying too much for cloud services (TechRepublic)
What we often call ‘cloud-native’ applications are designed to handle failure by just restarting and retrying rather than having enormous fault tolerance and resilience built in – replacing hardware with software but still keeping the rather brute-force nature of turning things off and on. The distributed microservices that make up cloud-native applications help with that, as well as allowing small pieces of the application to be built and updated independently.

That doesn’t mean abandoning all the other technologies that have been useful, and the introduction into Linux of Intel’s KATA isolated containers is validation of Microsoft’s opinion that the security isolation provided by virtual machines is still important. Kubernetes is still catching up in some fairly critical areas; support for combined IPv4 and IPv6 networks has only just been introduced in Kubernetes 1.16. Windows support is only just maturing – with Microsoft’s LCOW (Linux Containers on Windows) work now part of the containerd runtime – and Active Directory service account support still only in beta. Kubernetes isn’t in any sense what you’d call complete.

SEE: Cloud v. data center decision (ZDNet special report) | Download the report as a PDF (TechRepublic)

That’s because rebuilding all the tools and concepts we had before, in Kubernetes, is a lot of work; it may be worth it to get the benefits of containers, but it’s important to keep things in perspective.

To look at Kubecon this year, with its 10-12,000 attendees, you’d think that Kubernetes was well on its way to comprising the entirety of compute infrastructure, from enterprise apps to mobile networks to edge computing to serverless to databases to machine learning to networking to development tools to literally everything else.

Putting all of that together with the on-going developments in Kubernetes itself makes it hard to find any one topic and dig deep on it, because there’s just so much noise. Not only were there more attendees at one session covering a new Special Interest Group than the 550 people who went to the first Kubecon in Seattle in 2015, but there are almost as many organizations who have joined the CNCF as the attendees at that first Kubecon.

Some of that is about the way Kubernetes is becoming a common piece of infrastructure, and some of it is about the millions of dollars sloshing around the Kubernetes ecosystem. Kubernetes has become so significant that large enterprise IT companies from Microsoft to VMware to IBM have hired key developers and made contributions to key projects, either to get the expertise to deliver their own Kubernetes products and services or to move the ecosystem forward in a way that meshes with their existing products and services. The CNCF certification program for Kubernetes distros has allowed the number to proliferate without succumbing to the OpenStack problem of incompatibility between distributions from different vendors.

Some of it is even part of the way that Kubernetes is one of the healthiest open-source projects in recent years, in both senses of the word. The community building Kubernetes is particularly helpful, welcoming, diverse, self-aware and supportive, and while progress on some features like dual-stack support has been slower, regular releases bring new features at a fairly respectable clip. An organized process for rotating who’s working on the launch team stops the same few people from being overburdened, keeps enthusiasm high – and brings a continual stream of new people from more companies into the process.

Kubernetes is still booming, still growing and still producing new projects at a speed that says the ecosystem is still in its pre-Cambrian explosion of species diversity. But every pre-Cambrian explosion is followed by an Ediacaran die-off and if you squint carefully enough you might see the glow from the meteorite plummeting towards you. The explosion of multiple products (five service meshes! Multiple service catalogs!) will get curated down to a more manageable set of choices and ideally, much of Kubernetes will disappear into the infrastructure that most people in technology don’t have to think about any more than they think about the way an OS filing system, a database engine or a hypervisor works.

SEE: Just how popular is Kubernetes?

Kubernetes evangelist Kelsey Hightower noted recently that “The cloud made the hypervisor disappear. Kubernetes will be next.” That doesn’t mean either Kubernetes or the hypervisor is going away (see KATA containers where the oh-so-important isolation is provided by a hypervisor), any more than serverless magically works without anyone having any servers: just that all these trends are about not having to care about that infrastructure to get something done.

For Kubernetes, that might mean caring more about the Kubernetes API that handles the ‘getting things done’ part than the nodes and pods and other Kubernetes concepts that actually do the thing.

There are lots of ways of delivering that – cloud Kubernetes services, virtual kubelets and ephemeral containers and a half dozen other ideas – so there will be multiple projects and vendors springing up like mushrooms in the forest to deliver that abstraction, and infrastructure admins will get to care and worry about all of those. And Kubecon probably won’t get any smaller or more manageable unless it splits into a couple of more focused conferences.

But however ubiquitous the Kubernetes API might get, it’s not going to displace everything else. It might become the new IaaS where workloads run, but there’s still going to be plenty of more specialised PaaS options as well as ways to piece together cloud native applications out of PaaS pieces.

SEE: Serverless Kubernetes containers: Amazon EKS on AWS Fargate

And while Kubernetes itself is fairly new, many of the concepts it delivers aren’t. So yes, Kubernetes can be a big part of the future of computing without anyone apart from the infrastructure team knowing how to work with it directly or maybe even knowing it’s there. But the tools to do that need to shape up and stop treating Kubernetes as some special new thing.

It’s the latest crank of the wheel in computing platforms. It’s the latest abstraction for delivering a platform, likely itself to get abstracted away by some new layer.

It might be more useful to think of Kubernetes as the new Linux kernel rather than the new hypervisor. But whichever layer of infrastructure you think of it as, fast forward a couple of years and the focus will be much more on what you do with Kubernetes than how you do Kubernetes. And maybe Kubecon will be a little more targeted and manageable to go with that progression.