Fwiw I’ve deployed services that could handle 30-50k rps on 1vcpu and 1gb ram. Like a couple bucks a month. It used ssd storage and only hit a main rdbms when there was a cache miss.
When I hear stories like this I’m reminded of how dumb and inefficient most organizations are. My colleagues would over engineer stuff so much and then leave a huge bill and mess behind. The primary reason was so their clueless eng manager would consider promoting them.
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.
I strongly disagree with this statement. Even at the most bubbly of Silicon Valley events you will not see kubernetes for a smaller deployment be an industry standard.
It’s ok to make architectural mistakes, or otherwise over engineer a thing. We all do it. Let’s not standardize it.
And to your credit thank you for publishing this example as a learning opportunity to others.
If jobs are what you are concerned about then I can assure you no company is skipping on software developers because they don't know Kubernetes syntax.
Ansible/Salt/Puppet/Chef/CFEngine are closer comparisons.
It also doesn’t manage your configs; ie if you need to roll back, it won’t do that for you (though git will let you do that pretty easily).
I think Compose is great for the niches it serves; I have a lot of stuff that still runs on Compose because it doesn’t need any k8s stuff yet. I just don’t think it can be honestly called a k8s replacement. Compose offers equivalent features for some kinds of apps in certain situations, but k8s is a broader tool by far (for better or worse).
Tech stack at my last workplace was insane like that. To deploy, they woud have a Buildkite job would launch Terraform, which would then be configured by Ansible, then k8s would deploy on the cluster. I think they could have avoided all this ess k8s and probably Terraform and gotten away with one big box and shell scripts (which they had plenty of anyway), and used swarm/compose, but what do I know.
I self-host ~10 services on a single physical server in my home, defined in a series of docker-compose.yaml files stored in a git repo. It's trivial to set up, declarative, and easier to run locally than k8s.
Obviously not needed for a single node, though.
And I know they say that, but it's more or less YAML-as-a-programming language. It is pretty trivial to have side-effects that will persist well beyond and outside an Ansible playbook.
It's certainly better than a complete snowflake of a VM, but it's really closer to saying "we init this VM with this shell script."