CHICAGO — Top Kubernetes engineers are agreeing: K8s is getting too complex, for end-users and maybe even for the core maintainers themselves. Time to put complexity on a budget.
For his Thursday keynote at this week’s Kubecon+CloudNativeCon, Kubernetes co-founder and Google Distinguished Software Engineer Tim Hockin set out to reflect on the first nine (and a half ) years of Kubernetes and what the future may hold for the open source software. Kubernetes may have started largely powering highly scalable web applications, but it is now increasingly becoming the platform of choice for even more complex jobs — such as machine learning inferencing — which means the pressures to expand K8s for more use cases are growing significantly.
To help with his talk, Hockin asked others in the cloud native community about what they saw as the most pressing challenges for Kubernetes. A big reoccurring theme, as you might have guessed by now, is grappling with the sometimes daunting complexity of the deploying and maintaining the container orchestration engine.
One person even went as far as to say it was the “biggest existential threat” to K8s.
“Something has to give, ” Hockin said. “There’s a finite amount of complexity that we can absorb into the project over a certain amount of time,” he said. The more complexity there is, the less agility the core maintainers have to make changes in the future easily.
At the same time, the more complex the software, the more resistance it will get from users.
The software around Kubernetes has been community-driven: More than 74,000 contributors have been added to the project thus far. This first generation of users took an interest in K8s and many worked to make it better.
But as new users continue to come on board, they will inevitably have less interest in how Kubernetes works. So it is incumbent on the maintainers to make it easier to use, Hockin noted.
“The more complex something we add is, the more of our budget that we eat up. And when the budget runs out, bad things happen, ” he said. Innovation stops, and users drift to other solutions.
Hence, Kubernetes project managers need to think about complexity as a finite resource that can be drawn upon: a “complexity budget” of sorts.
Hockin admitted that he did not know how to measure the complexity of a piece of software, much less the amount of patience end-users have for dealing with complicated pieces of software.
However he noted that engineers generally know when they are overspending on a budget. So when thinking about adding a new feature, they must ask the question: do we have enough left in the complexity budget to afford this? And is this something we should spend a limited budget on?
Part of an engineer’s job is to weigh the trade-offs of any decision, and the additional complexity a new feature may bring should be one factor to be evaluated.
Some augmentation to the code base may bring about a 5% performance improvement in some aspect of the software, but is it worth it if it creates more internal complexity for the maintainer to deal with. If an API is altered to meet a niche use case, is it worth burdening all the other users with this change?
“Raising the bar requires all of us to be willing to say no, to be willing to say no to things that we really do want, things that are not bad ideas, things that seem obvious and easy on their own. And things that honestly the company is paying us might really want,” he said.
By saying no to some proposals leaves some room in the complexity budget to tackle more pertinent projects down the road.
“We’ve got to say ‘no’ to things to today, so we can afford to do interesting things tomorrow,” Hockin said.
There is a lot left to do for Kubernetes, but this does not mean all of it would need to be done right away. We are all accustomed to always thinking more is better, but Kubernetes may be getting to the case where less now equals more, Hockin said.
As one person suggested to Hockin: to stay vibrant, Kubernetes should stay unfinished.
The post Tim Hockin: Kubernetes Needs a Complexity Budget appeared first on The New Stack.
Kubernetes core maintainers should weigh the benefits of proposed new features against the additional complexity they would bring, the Kubernetes co-founder advised at this year's KubeCon.