Like a teenager, Kubernetes looks almost grown-up, yet still a bit awkward and confused
Platform: that’s the key word that sprung to mind after attending Kubecon-CloudNativeCon Europe 2022, hosted by the Cloud Native Computing Foundation (CNCF) in Valencia last week. As in, Kubernetes isn’t a project any more, it’s a platform – and it’s one that’s now being used by thousands of organisations world-wide to build very real, very working applications and systems.
Yes, I know there’s not one single Kubernetes platform – every big cloud provider has its own hosted and certified distribution, there are managed services and there’s third-party commercial and free offerings from companies of all sizes (for example, VMware just released a new version of its free Tanzu Community Edition) that application developers can download and just get to work on.
Plus there’s still a host of organisations and individuals assembling their own platforms – indeed, there’s whole new job specialisations emerging, such as platform developers and platform engineers. Even building a platform is easier now, though, thanks to projects such as the Helm package manager, which has also graduated to become part of the Kubernetes furniture.
App devs and platform devs have different jobs and skillsets
But essentially all this is a sign that Kubernetes has matured enough to have two orthogonal things going on. On the one hand, there’s still the platform devs building and finding the tools and components they need to build platforms and systems, and on the other it’s about software coders having stable platforms on which to write web applications. It’s platform deployment versus workload deployment.
There’s also a similar diversity in ops emerging, with platform ops emerging alongside application ops, infrastructure ops and so on. But the key thing is that application developers shouldn’t need to know the details of what’s underneath the platform they program to. This is also considerably helped by newer cross-platform programming environments, in particular WebAssembly, which has emerged as a kind of modern equivalent of Java for building web apps.
Do we need more choice – or less?
It’s not all smooth sailing, however. One aspect that came up in a number of panel discussions and the like was the sheer size of the CNCF landscape, which now includes hundreds upon hundreds of projects at various stages of maturity. While the CNCF reps pitched this as showing the vibrancy of the Kubernetes ecosystem, others were less impressed. Some even spoke of the confusion and hesitation that can come from having too much choice, saying we’d benefit from more standardisation in platforms, rather than people picking (or having to pick) their own tooling and components.
In a similar vein, many of the user-presentations to the conference centred in large part on the tooling choices that they had made in building the platform best suited to their needs and those of their app devs. Again, platform deployment as distinct from workload deployment – but even then, they’re just assembling packaged components, and as I mentioned earlier, you really don’t have to do any of this if an off-the-shelf platform suits your needs.
Quite how this will all evolve in the future remains to be seen. But it’s a reminder that even the best people only have a certain amount of bandwidth, and that every hour a dev spends building their own platform is time they’re not working on real business applications.
And I think it’s a pretty good sign that a technology is maturing into the mainstream if you no longer have to hack and tweak it to make it useful to you.