3 ms·
I've said it a few times before: k8s is such a distraction for so many startups I've been in (~5). All of them fall into the same trap: write entire arch aroun
by windexh8er 3y ago
I've said it a few times before: k8s is such a distraction for so many startups I've been in (~5). All of them fall into the same trap: write entire arch around k8s and then not really invest the engineering into building it out fully. Instead they all seemed to settle on "hey this works" which kicks off the technical debt receipt printing.
In all of them fixing things often went like this...
* A: XYZ is broke.
* B: OK, is the pod running?
* A: Yeah.
* B: Did you try killing it? That usually fixes the problem.
It's madness k8s is generally always the root cause of the problem because of resource constraints, node issues, a misunderstanding of H/V scaling, and the list seems to just go on.
At this point I feel like k8s is the c4r (cancer) of a lot of startups that would be better off just running in a more traditional VM / container strategy and dealing with growing pains if and when they become apparent. Also, it's almost guaranteed to cost less. Kaa$ is a racket.
- icedchai 3y agoMany startups would also be fine with some serverless container solution (AWS Fargate, Google Cloud Run, etc.) It doesn't fit all applications, but when it does, it's generally less overhead than K8s, both operationally and $ wise.
- scrubs 3y agoLet's put k8s aside. If I had a complex system needing say five boxes, I might be able to admin it well - startup, shutdown, upgrade - if there was a simple orchestrated glue between the boxes e.g. on the control box 1, run a script to start daemons/pids on boxes 2, 5 which blocks until success or failure ... something more sophisticated than remsh/ssh. This is old school, but it's just a script or three.