As Kubernetes turns 10, experts predict the future of cloud-native

0
10
As Kubernetes turns 10, experts predict the future of cloud-native


In June, Kubernetes celebrates its tenth birthday. The system is now so widely used by hundreds of thousands of companies worldwide to scale their applications to meet demand it’s hard even to remember a time before it existed. But there was a time when other options were available, and I even remember using some of them. 

Despite this relative vintage, many large developers teams and companies are still yet to embark on a migration to Kubernetes, or are in the middle of the process. But to many developers who like to live on the edge, 10 years of a technology is a long time, and maybe to them, Kubernetes and the whole “cloud native” ethos even feels a little “tired.”

At KubeCon EU in Paris in March, perhaps the biggest and best KubeCon in Europe I’ve attended, I asked European cloud-native thought leaders to consider what the future of cloud-native could hold — or what could replace it.

More control of hosting

Alongside Kubernetes, the three big cloud hosts (Amazon, Google, and Microsoft) were the catalysts for cloud-native computing. One of their initial big selling points in the past was flexible, usage-based billing with the promise to save those with spiky demand scalable workloads that saved money. But that didn’t necessarily turn out to be true for everyone, and moving back to more traditional hosts was a noticeable trend at KubeCon, with three of the large European hosts (OVHcloud and Scaleway from France and CIVO from the UK) with a large presence on the show floor.

Civo’s CTO, Dinesh Majrekar, mentioned that Broadcom’s recent acquisition of VMWare could provide many opportunities for smaller hosts and more data-sensitive enterprise customers, such as those in Europe. As Majrekar said: “Our ability to have a managed enterprise-ready version of a public cloud deployed locally in your own data centre using your own hardware and giving these customers the ability to use VMs in a VMware way will be really interesting.”

The <3 of EU tech

The latest rumblings from the EU tech scene, a story from our wise ol’ founder Boris, and some questionable AI art. It’s free, every week, in your inbox. Sign up now!

Initially, Broadcom announced a significant change in pricing that caused concern for many of its existing customers. However, after many complaints and an investigation from the EU, Broadcom rolled back some of these changes. So how much business it brings to these smaller hosts now remains to be seen.

Write once, run once becoming a reality

Programmers have long dreamed of writing code once and having that code run equally on all operating systems and platforms. From Java to Electron, Flutter, and beyond, developers have strived to create technologies to accomplish this ideal for decades.

Originally created by Mozilla in 2017, WebAssembly, also known as WASM, has quickly become a web standard and is supported by all major web browsers. It allows compiled languages such as C++ and Rust to run applications in browsers. It’s Java web applets all over again!

The ability to run compiled code in browsers (client-side) is interesting enough, but recent developments are what makes WASM more interesting in relation to cloud native. A handful of open source projects and companies are using WASM to run server-side, such as WasmEdge and SpinKube, which is creating interesting competition for containers, the isolated application and dependency units that run on Kubernetes.

Instead of worrying about creating and maintaining secure and optimised containers to run application services — with the myriad complications they present — WASM presents an alternative. The service runs as a compiled binary, including all dependencies. Thanks to WASM’s secure-by-default approach, it’s more efficient and less vulnerable than containers that can potentially have dozens, if not hundreds, of exploits via dependencies and misconfiguration. This doesn’t mean that WASM will replace Kubernetes. Rather, it might replace the containers that Kubernetes typically orchestrates. Kubernetes would still manage scaling, rollout, etcetera.

Civo now offers two options for hosting WASM payloads on their Kubernetes service:, Fermyon Spin and WASMedge.

As Civo’s CTO, Dinesh Majrekar told me: “We want to be there to support new technologies that others don’t, staying up to speed with them and allowing customers to deploy them.”

Sébastien Blanc, Staff Developer Advocate at Finland’s Aiven, echoed the sentiment that WASM is “the next big thing,” adding that he is “betting on WebAssembly.”

Thierry Carrez, the general manager of the Open Infrastructure Foundation, which oversees projects further down the stack and creates and manages data centre infrastructure, shared that view.

“I feel like the container as the computing unit will change,” Carrez said. “There will be at least a variety of options. People realise that VMs are still better at a number of things. WebAssembly is better at some other things, so it’s going to eat a bit at containers. I’m not sure that we’ll end the cloud native trend, though.”

Civo’s Dinesh also mentioned that WASM’s ability to run the same code remotely, locally, or on-device gives developers interesting possibilities for spreading application workloads across devices to where they’re needed most and away from centralised servers. This is exactly the promise of edge computing for cars, smart devices, and small compute devices that are slowly spreading around the world. These devices process their own small payloads but still need to check in with services hosted elsewhere for updates occasionally and to send and receive data.

WASM isn’t suited to all tasks, and methods to allow payloads to communicate with external services like databases are still in progress. As a technology on the verge of wider adoption, it’s definitely worth investigating and keeping an eye on.

Platforms take centre stage

In its 10-year history, Kubernetes and cloud-native has become incredibly complex. Developers and implementers layer abstraction upon abstraction in an attempt to make creating and maintaining infrastructure and services more manageable and flexible.

This has led to an entire trend of “platform teams,” which help build internal self-serve tools that other teams use to create and deploy short and long-term infrastructure and services in a controlled way. Whilst this idea, sometimes called an “internal developer platform,” has gained traction, especially within large companies, not everyone has the resources to bolt together all the pieces needed to create a functioning platform team, so naturally, SaaS companies have emerged to fill that gap.

The term “internal developer platform” is a European invention, coined by Germany’s Humanitec, as is its close relation and precursor, “service catalogue,” coined by Sweden’s Spotify Backstage team. Humanitec’s CTO, Chris Stephenson, was part of the Google team that built the precursor to Kubernetes, “Borg.”

As the platform concept grows, some companies have pivoted to providing tools for internal teams. One such company is Germany’s Giant Swarm. They are relative veterans of Cloud Native, and I have known them for nearly ten years. The company is currently on what they call “3.0” of their product, which aims to provide development teams with what they need to function and create their work.

As Joe Salisbury, Giant Swarm’s VP of Engineering, told me: “We want to help a platform team focus on capabilities and focus on the application team, and we fully take care of the infrastructure. They don’t need to be thinking too much about Kubernetes upgrades or the major infrastructure around monitoring or observability. The idea is that Giant Swarm can holistically manage your platform for you, and you can focus on actual differentiating work for your platform team.”

Often, behind the scenes of a platform as a service provider are infrastructure as code tools such as Terraform. Created and stewarded by HashiCorp and open source since its inception, Terraform caused waves of controversy last year when it ceased open-source development and changed its licence to stop any commercialisation. This led to a rapid effort by the contributor community to create “OpenTofu,” and several companies have already created products on top of that.

Sebastian Stadil, Core contributor to OpenTofu and CEO at Scalr, which offers a scalable SaaS version of OpenTofu, explained how successful the project had been so far:

“The 10 months since the creation of the OpenTofu fork have already led to an ecosystem of Terraform-compatible tools and projects, including Scalr, Terragrunt, and Infracost.”

With so many more companies joining the space as interest grows, I asked Humanitec’s VP of Product and Growth, Luca Galante, how they see the current state of platform engineering — a term that Humanitec, in some ways, helped create.

“We didn’t invent platform engineering, but we did put a name on it,” Galante said. “We’re going to continue to shape that narrative. We’re doing that with thought leadership pieces, regular webinars with practitioners, and our online conference, PlatformCon, had 22,000 attendees last year, and we expect 35,000 attendees this year.”

Regarding a potential distant future for cloud-native, Luca proposed the idea of continued abstraction for infrastructure combined with AI. A model could learn from your specific needs for developer platforms and create them smartly based on simple prompts or requirements. Many years ago, GitHub proposed the idea of “ChatOps,” but the practice lost favour as the chatbots of the time weren’t capable enough. But now, we are fast approaching a new era of Generative AI for infrastructure as code, with companies such as AppCD

10 years from now

Kubernetes and cloud-native, from AI to smart cities, from e-commerce to essential infrastructure, power the innovations of others. Does it also need to innovate when its users already do? Or is it (mostly) silently working in the background enough? I went into KubeCon looking for drastic and dramatic future changes, but in reality, that was never going to be the case.

The work and payloads it supports will change, as will how and where developers and engineers want to use it. But with Kubernetes and its related technologies now so entrenched in our workflows, I think it will take at least another 10 years before even half of its current user base has moved on to the latest hot new trend.

Happy birthday, Kubernetes, and here’s to many more.



Source link

Chris Chinchilla