
I’ve just finished catching up on all the community content from AWS re:Invent that I missed, and one topic stuck out to me. Pankaj Gupta from VMware’s article on the community blog about VKS and the criteria for picking a container platform (that no one ever thinks about).
It couldn’t be more fitting as this exact conversation came up during last week's roundtable, and in 3 exec conversations I’ve had over the last month and none of the criteria on this list were mentioned. If that’s not proof they’re overlooked, I don't know what is!

Here are Pankaj’s five overlooked criteria you need to keep in mind:
- Faster access to new Kubernetes versions for faster innovation
- Duration of standard support for Kubernetes versions - longer is better
- Flexibility to run multiple Kubernetes versions on the same hosts
- What's included in distribution matters a lot more than you think
- K8s and VMs both need to be treated as first-class citizens
Anyone actively working with K8s knows that the grind of staying on top of 3 major releases a year is never ending, especially at larger orgs with particularly complicated setups. And there is no deluge of K8s experts out there to help you.
You know I’m the first to say that the challenges of platform engineering are overwhelmingly cultural, but Kubernetes complexity and finding the talent to help with it is one of those few very technological challenges that holds back teams.
Culture might be 90% of the battle. But that doesn’t stop that last 10% from grinding everything to a halt. Especially when we aren’t thinking about the problem.
So… what else have you been overlooking?

























.webp)
.webp)




.webp)
.webp)


.webp)
.webp)

.webp)


-1.webp)














.jpg)
.jpg)
.jpg)
.jpg)
.png)
.jpg)
.png)
.jpg)
.jpg)
.jpg)


.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.png)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.png)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)













