3 ms·

I remember a time where HN was quite critical to the complexity of k8s. After reading top comments, I can see the tide has shifted.

by brumar 3mo ago

canto 3mo ago
This or there's a lot of fresh blood ;-)
- hnlmorg 3mo ago
  I’m one of those top commenters who used to be a K8 naysayer. I’m also definitely not young blood. The reason my position has changed is because: 1. The tooling has gotten better for setting up and managing K8. 2. In two of the last 3 jobs where we opted for a simplified alternative to k8, we came to regret that decision within a couple of years of that decision being made. If you’re core architecture is changing on a timescale of months (not years) then you picked the wrong foundations to build from. That all said, I still think there is a pragmatic decision that needs to be made. And if I were in the author of this articles position I probably wouldn’t have picked k8s for this task either, despite what I said above. But, and as I said in my comment dismissing this article, they are dealing with low traffic and none of the problems that lend themselves to the benefits of k8. So my criticism of this article is that it’s misleading because their problem is easy but they’re writing as if they’re having to deal With problems of scale when they’re actually not.
bizzletk 3mo ago
CTOs have found reasons to standardize on k8s and it's not just for technical reasons. This was recently discussed last week: https://notnotp.com/notes/what-job-interviews-taught-me-about-kubernetes/ https://notnotp.com/notes/what-job-interviews-taught-me-abou... https://news.ycombinator.com/item?id=48546428 https://news.ycombinator.com/item?id=48546428
zug_zug 3mo ago
I used to be critical of almost everyone who used it. Now that I've been learning the ecosystem for a couple years, I'm not as angry about it, and it doesn't affect me as much personally. I still think almost all of my complaints were valid: - not just container orchestration, more like a whole AWS solution (its own routing) - has single-points of failure that would be avoided if you just used aws - unnecessary complexity for almost all use cases - ecosystem easily allows you to 2x-8x that complexity (helm+argocd+istio+carpenter+dozens more=hundreds of new failure modes) - fundamentally moves many teams to a "I don't understand why my service is crashing, so let's just bring up more nodes every time rather than ever learning to debug it" mentality. - All the feature teams that are supposed to "own their own kubernetes implementation for their own services" never do. Of course a lot of that frustration is more at working at a place with a poorly-operated SOA where it takes a half-dozen services to send an email to a client or send a text or something silly. It sure is a waste of runway to obsess over a SOA when you aren't profitable yet. But at this point it's sort of a sunk cost because it's become the industry standard. And AI can help with 90% of the complexity, which is it's own yellow-flag, but here we are.

I remember a time where HN was quite critical to the complexity of k8s. After reading top comments, I can see the tide has shifted.

by brumar 3mo ago

I remember a time where HN was quite critical to the complexity of k8s. After reading top comments, I can see the tide has shifted.

canto 3mo ago

This or there's a lot of fresh blood ;-)

hnlmorg 3mo ago
I’m one of those top commenters who used to be a K8 naysayer. I’m also definitely not young blood. The reason my position has changed is because: 1. The tooling has gotten better for setting up and managing K8. 2. In two of the last 3 jobs where we opted for a simplified alternative to k8, we came to regret that decision within a couple of years of that decision being made. If you’re core architecture is changing on a timescale of months (not years) then you picked the wrong foundations to build from. That all said, I still think there is a pragmatic decision that needs to be made. And if I were in the author of this articles position I probably wouldn’t have picked k8s for this task either, despite what I said above. But, and as I said in my comment dismissing this article, they are dealing with low traffic and none of the problems that lend themselves to the benefits of k8. So my criticism of this article is that it’s misleading because their problem is easy but they’re writing as if they’re having to deal With problems of scale when they’re actually not.

bizzletk 3mo ago

CTOs have found reasons to standardize on k8s and it's not just for technical reasons. This was recently discussed last week: https://notnotp.com/notes/what-job-interviews-taught-me-about-kubernetes/ https://notnotp.com/notes/what-job-interviews-taught-me-abou... https://news.ycombinator.com/item?id=48546428 https://news.ycombinator.com/item?id=48546428

zug_zug 3mo ago

I used to be critical of almost everyone who used it. Now that I've been learning the ecosystem for a couple years, I'm not as angry about it, and it doesn't affect me as much personally. I still think almost all of my complaints were valid: - not just container orchestration, more like a whole AWS solution (its own routing) - has single-points of failure that would be avoided if you just used aws - unnecessary complexity for almost all use cases - ecosystem easily allows you to 2x-8x that complexity (helm+argocd+istio+carpenter+dozens more=hundreds of new failure modes) - fundamentally moves many teams to a "I don't understand why my service is crashing, so let's just bring up more nodes every time rather than ever learning to debug it" mentality. - All the feature teams that are supposed to "own their own kubernetes implementation for their own services" never do. Of course a lot of that frustration is more at working at a place with a poorly-operated SOA where it takes a half-dozen services to send an email to a client or send a text or something silly. It sure is a waste of runway to obsess over a SOA when you aren't profitable yet. But at this point it's sort of a sunk cost because it's become the industry standard. And AI can help with 90% of the complexity, which is it's own yellow-flag, but here we are.