Hacker News Reader

Comment by htrp | Hacker News Reader

This is also the right way to deprecate. Charge people an arm and a leg to keep things running (and eventually force them to migrate).

View on HN

100%. People are responsible for an ever-increasing amount of things; people will focus on business priorities and stuff that is working will be left the hell alone. As long as the bills are manageable and the business pays - the lights will be kept on forever. Passing increasing support costs to customers realigns interests between customer and provider without danger of user impact.

And for Kubernetes, honestly, charging 6x for extended support is probably a bargain, considering the pace of change and difficulty of hiring engineers for unsexy maintenance work.

I do appreciate that the devil is always in the details, but I'll be straight that their new(?) "Upgrade insights" tab/api <https://docs.aws.amazon.com/eks/latest/userguide/cluster-ins...> goes a long way toward driving down the upgrade risk from a "well, what are we using that's going to get cut in the new version?"

We just rolled off of their extended version and it was about 19 minutes to upgrade the control plane, no downtime, and then varying between 10 minutes and over an hour to upgrade the vpc-cni add-on. It seemed just completely random, and without any cancel button. We also had to manually patch kube-proxy container version, which OT1H, they did document, but OTOH, well, I didn't put those DaemonSets on the Nodes so why do I suddenly have to manage its version? Weird

Touching CNI is always a potential downtime inducing event, but for the most part it was manageable

Agreed. I would imagine the previous approach of forced upgrades ended up burning lots of customers in worse ways than just their pocketbook.

True, but I guess it'll be a surprise to many. And, unfortunately, upgrading isn't always the easiest thing with deprecations and stuff

Reply on news.ycombinator.com