Kubernetes evolution: Platform engineering and serverless future

Bart: Jay, thanks so much for joining us and welcome to KubeFM. Can you tell us who you are, what's your role, and where you work?

Jay: My name is Jason Smith, but I go by Jay. I'll respond to either, so nobody should ever obsess over which one to call me. I am a customer engineer, a cloud architect, kind of used interchangeably at Google Cloud.

Bart: I noticed that the transcript snippet is very short and lacks context. Could you provide the full transcript or more context about the emerging Kubernetes tools that Jason Smith is discussing?

Jay: It's hard to find what is exactly emerging. Some interesting developments I've found include Kuberay, which has been promising lately. I recently got into KRO (Kubernetes Object Resources), which is kind of similar to Crossplane for those familiar with it. That project looks promising, especially since it has backing from the big three clouds. We'll see what happens in the future.

I'm also starting to look more at Dapr. In the vein of platform engineering, it seems very promising, providing an API layer for deploying resources—not just Kubernetes resources, but cloud resources as well. These are emerging technologies I find interesting. I'm sure some listeners might say they've heard about these a hundred times already, but to me, these are genuinely promising developments.

Bart: On the subject of infrastructure as code, one of our podcast guests, Brian, suggested that the current infrastructure as code paradigm has reached diminishing returns. What new approaches could revolutionize infrastructure management in Kubernetes?

Jay: I am a big fan of Pulumi for infrastructure as code. One idea that has been missing is the "code" part. I think what makes infrastructure as code easier, especially for developers and data scientists who use Python and various programming languages, is the approach of platform engineering.

A key question is: How do we make Kubernetes easier to use? One approach would be to write Kubernetes objects as Python objects or in other programming languages, similar to learning a new library like PyTorch. We're seeing more code packages that can transform code into YAML or Terraform HCL.

If we start taking a code-first approach to infrastructure as code, we'll see major changes and make Kubernetes more accessible. According to a recent survey, 50% of people who have implemented Kubernetes believe it could be easier to use. The goal is to meet developers where they are and work with the tools and languages they already know.

Bart: A common thing we hear when asking people about their least favorite feature of Kubernetes is that overall complexity and the steep learning curve are two of the biggest turnoffs. On the subject of platform engineering and tooling, one of our guests, Angel, stressed that standardizing everything makes cluster management easier. What's your advice for building platforms that can be used by several teams in an organization?

Jay: Change management is hard. The first thing I always say is to look at your team and your team's culture—how you operate and do your workflows. Figure out the culture and then find the right tool for that culture. If you try to implement tooling when building platform engineering for your organization and it doesn't make sense to the team, it won't get used. You'll have slow uptake. It's better to understand who you are building for rather than just building something and saying, "We've made things easier," when it's not actually easier for the team.

Bart: On the subject of availability, our guest Martin suggested avoiding pod topology spread constraints, as this is a Kubernetes feature that is simple to understand but has problematic consequences if not understood correctly. Do you have similar examples of something in Kubernetes that looked easy but was an absolute nightmare?

Jay: Auto scalers can be deceptively easy, and some are relatively simple. However, people often set arbitrary maximum numbers like 100 without properly configuring metrics. They might use a generic CPU metric without backtesting or understanding how their application actually performs on Kubernetes.

I've seen clusters scale up unnecessarily when there was plenty of headroom available on pods or nodes, simply because the autoscaler features were misconfigured. People sometimes just plug in numbers that "sound about right" and end up with unexpectedly high scaling, leading to surprise bills or resource overprovisioning.

My recommendation for customers and Kubernetes users is to thoroughly test and understand scaling parameters. You're unlikely to get the configuration perfect on the first attempt. It will take careful testing and iteration to find the right approach for your specific application and infrastructure.

Bart: Kubernetes turned 10 years old last year. What do you expect in the next 10 years to come?

Jay: In the next 10 years, two big things I think are going to happen. One of the big things I'm an advocate of is serverless containers. "Serverless containers" sounds like an oxymoron because it seems like you've figured out how to run Kubernetes without nodes or VMs—but of course not.

What's happening is a focus on being developer and user-centric. Platform engineering is really about building a platform that makes it easy for developers to self-serve and deploy what they need without constant support. Serverless, by definition, is exactly that: a developer-centric approach that abstracts infrastructure away from developers.

I predict more projects will emerge. Right now, there are two major ones like Knative and KEDA around serverless containers. I expect to see more projects grow in this space. Another promising area is Wasm or WebAssembly. I saw some interesting talks at KubeCon about running WebAssembly on Kubernetes. I anticipate we'll start to see not just containers on Kubernetes, but also WASM binaries existing side by side.

Of course, AI will continue to be deployed on Kubernetes for training—a point everyone has likely heard repeatedly. These are two interesting use cases I see happening soon.

Bart: What's next for you, Jay?

Jay: I am going to continue to preach the stories of serverless containers and hope more people use them. Also, since this is a Kubernetes-centric podcast, we have KCD (Kubernetes Community Days) here in the San Francisco Bay Area coming up in May. Please Google that, and you should find the link to sign up.

Bart: What's the best way for people to get in touch with you?

Jay: You can visit my main website at jasonsmith.io or sign up for my serverless newsletter.