A fast modern 16 core machine with 128 gig of ram can meet a lot of needs.
True, as long as you don't care about redundancy or scalability or wasting money because you actually only use 4GB of RAM and barely any CPU.
> So much kubernetes is just overkill.
Absolutely true. Kubernetes is great in some scenarios, but pretty complex so overkill when starting. Serverless (ideally containers as a service), docker-compose and Nomad* are much better options unless everybody is already a Kubernetes pro that has all the tooling ready.
* - disclaimer, I work at HashiCorp, but I actually believed Nomad is amazing, sufficient in most scenarios, and actually better than Kubernetes in some aspects before joining and it's one of the reasons I joined.
Hetzner will rent you a massive 128GB of RAM server for ~150 bucks a month. In company terms, that is peanuts and whatever time you'd spend installing and managing K8S is pretty much never going to pay for itself, not to mention the added liability of all those moving parts.
The whole "autoscaling" thing is mostly bullshit invented by the cloud providers to make their insane margins more palatable. A dedicated, non-cloud stack sized to peak capacity will be cheaper than the majority of "autoscaled" stacks at minimal capacity.
> True, as long as you don't care about redundancy or scalability or wasting money because you actually only use 4GB of RAM and barely any CPU.
Redundancy: you want two fast machines. More if you want them in multiple locations, but we still see a lot of people with presence only in us-east.
Scalability: You can go to 96-core per socket on commodity x86 servers now; 16 -> 96 is a lot of room to scale. You can also go up to I think 3TB per socket on Epyc Genoa.
Computation is the easy part, you can pick that kind of performance up at your local IT box store.
The hard part, that what Kubernetes makes easy, is the rest: dealing with failing compute nodes, with isolating workloads, writing load balancer configurations, keeping them up to date, setting up and tearing down volatile (=feature branch) environments...
If you want ad hoc rapid setup you can get a managed server up and running about the same time as an instance with AWS too, from a provider that also offers colos and cloud so you can pick and choose and move between the three depending on what is most cost effective for specific needs. In practice, ironically, having that option makes cloud instances even less cost-effective because having the option of spinning up cloud instances an tie them into your environment means your can allow yourself to have less spare capacity on your managed/colo servers.
If you're using Kubernetes, you want a managed cloud storage solution and you want a managed database solution, and AWS is among the best for those. (Though, personally - I prefer GKE). The smaller VPS providers have solutions for those. DynamoDB, though? Not so much.
Nah, I'd recommend serverless for the vast majority of use cases. But otherwise, yeah it gets heavily into the AWS stack with SQS, SNS, Kinesis, S3, DynamoDB, Aurora, etc.
Running k8s on bare metal is incredibly annoying and brittle. Upgrading your clusters is a constant firefighting experience, and because k8s doesn't have something like an LTS version [1], you have to keep upgrading ALL THE DAMN TIME, which often enough means you have to upgrade not just the clusters but also your resource definitions (e.g. ingressClass), or mess around neck-deep in the bowels of MetalLB because it managed to shart all over its configuration yet again.
In contrast, EKS is relatively painless.
I've never met any AWS expert at AWS who isn't quick to tell you when an AWS service isn't a fit for your needs.