The recent KubeCon North America event in Detroit included a simple-enough sounding panel discussion tasked with predicting “what’s next in cloud native?" That got me thinking that what’s next in cloud native is taking a look at exactly what cloud native needs to be.

The cloud-native space has always been viewed as a driver for new cloud innovations. Developing something that is designed to live and breathe in the cloud should be the ultimate extension of what cloud should be. And, with cloud being viewed as the future of innovation, being at the tip of that movement comes with a lot of expectations.

However, what has happened is that while the cloud-native space has been developing the future, it has also begun to lose touch with the reality that the future needs – or hopefully needs – humans. And by that I mean that the end user, who is typically human, is not as well-versed in the intricacies of cloud native as those who are creating all of the parts feeding into the ecosystem.

As an example, take a look at the current Cloud Native Computing Foundation (CNCF) landscape. Now compare that to some of the first models, and the difference is startling.

Yes, cloud native has taken off over the past five years, and the cloud ecosystem is better for it. But, how is an IT person at an organization tasked with “implementing cloud native” at their organization supposed to tackle this landscape?

Is Kubernetes to blame for cloud-native challenges?

Much of this growth has been on the back of Kubernetes, which was the first project donated to CNCF, has become the halo project within CNCF, and has changed the ecosystem.

Kubernetes altered the landscape by opening up the cloud native and container ecosystem to a platform that was open to everyone, or at least those who could understand the underlying code. It quickly became what everyone wanted to see when they were selecting a container orchestrating system, or really, when selecting anything, it seemed.

But, Kubernetes was never developed on its own to be everything to everyone. The bones are there, but they need finessing, which has led to the development of Kubernetes-adjacent platforms. Those platforms have led to there being more Kubernetes “users” and not enough Kubernetes “knowers,” which is a bottleneck.

This is not a new concern. Members of that KubeCon panel all recognized the complexity and understood the need for change.

But what does that change look like? I don’t think anyone wants to stifle the rampant innovation flowering from the cloud-native space. But if no one can use this innovation, does it do anyone any good?

Matt Klein, a software engineer at Lyft and creator of the Envoy service proxy, noted from the KubeCon panel that simplicity could come from the past.

“I like to joke that we are taking 20 years to go back to Heroku,” Klein said, citing the seemingly ancient platform-as-a-service (PaaS) product. “And, not actually really joking, like that’s basically what’s happened.”

Klein noted that current hyperscale options like Amazon Web Services (AWS) Fargate and Lambda, Google Cloud’s Cloud Run, and Microsoft’s Azure Functions show that this push is not “like 10 years from now, this is right now.”

“I just believe that over time it's going to become increasingly irresponsible for new projects to not use these technologies because they provide so much for users, and their reliability and the robustness and their scalability will only increase because there are so many people working on them,” Klein said.

But the thought of the hyperscalers providing curated content could rub purists the wrong way. And that doesn’t even get into the broader market dynamics discussion.

Will humans or robots be cloud native’s salvation?

Further impacting this space is the increasing lack of qualified developers to help organizations deal with these challenges. Vendors and trade groups have been throwing money at this problem for years, and it seems that this problem is only getting worse. It’s hilarious and scary to always hear a cloud-native executive or engineer plug from an event stage that they are hiring.

A recent Forrester Research blog noted that the United States Bureau of Labor Statistics predicts a 22.2% growth in application development and quality assurance testing demand in the next 10 years. It also cited its own research that found 20% of companies are recruiting non-degree-bearing developer candidates, and 24% state that they recruit university grads with non-IT degrees.

That blog was tied to the topic of low-code/no-code platforms that have been circling the ecosystem as a way to solve the developer and skills channel. These platforms have been able to more deeply integrate automation to help solve some of the challenge, but it’s obviously not been able to completely solve all of them.

Many, like Klein and others, have brought this issue to the forefront, but it takes more than a few to tackle this challenge.

Maybe one answer is that we turn all of this angst over to the robots and let them run these systems. Maybe that can solve the issue, but it seems to be too easy of an answer. Wouldn’t it be better if the humans who developed this strife could also develop its salvation?