Had we not gone with k8s and just gone with a vm -- even without docker compose -- but just a monolith we'd have been 1000% further along than when I left.
Even doing everything cloud native means learning how to package your stuff for that provider and go through their docs, learn their idosyncracies, etc.
BUT!!!!
Let's say you hire a kid whose been tinkering with servers in their room since they were teens and know their way around a Linux distro and can package python and run a proxy etc etc
There's a lot of compelling reason to simplify the tech stack and cloud/k8s/etc makes sense only when the scale requires it.
---
That being said -- Hetzner is not the panacea its pricing might suggest. We run our self hosted gitlab on it and we've had 2-3 incidents in the last month that required them to either power cycle a machine or fix some networking thing etc etc. I kinda expected more. But it's hella cheap: where else will you find so much hardware for 200 a month.
If you're running a whole fleet of VMs and need to manage them the pain of doing that is quickly going to exceed the "pain" of using k8s. Do you need something like k8s ingress? Do you need the ability to move workloads if a machine goes down? certs? external-dns? Are you going to deploying tooling that's available off the shelf for k8s? (lessay Prometheus/Grafana?). VMs have overhead and likely waste a lot of resources.
I've seen this "monolith" and I've seen containerized/k8s. For anything that needs to scale and needs similar abstractions you get out of k8s you definitely should not try to reproduce this using VMs.
A lot of applications can fit on a single machine. Single machines have gotten so big: 256+ cores, terrabytes of ram, huge amounts of fast storage, 100+Gbps NICs.
Yeah, you should have 2-4 for continuity, but that doesn't need orchestration.
You really don't need to start thinking about horizontal scaling unless you're getting close to filling a single big machine. Especially since the longer it takes for you to scale to big machines, the bigger the machines will be when you get there.
If your application is very latency sensitive, then maybe you need to run machines in more places, and maybe you want something to orchestrate that...
I'm sure plenty of things fit this model. But many do not. There's going to be a point where you're taking more pain if you chose the wrong model.
Go can serve about 500M users per month on Xeon E3 v2 CPUs.
Why, except for HA do you need more?
Do you know how much 5000 (and more in reality) concurrent requests are, and I'm just talking HTTP1.1 requests?
And with HTTP/2 and 48 cores 96 threads and even 24c/48t commodity hardware that's multiples of 5k concurrent rps.
Of course if you insist on using low performance php, node, ruby, elixir that's your own fault.
"Scale" my ass. Just another FUD buzzword to sell expensive proprietary services.
> Go can serve about 500M users per month on Xeon E3 v2 CPUs. > Why, except for HA do you need more?
Because not everything is a simple CRUD website. The last place I worked had a website that appeared to only be moderately more complex than such a site, and had well under 500M users per month. But parts of the application involved complicated processing of many dozens of TBs per day of newly collected data to optimize the content being served (some stream processing, some batch). We had multiple clusters of 1,000+ machines coming and going for an hour or two at a time (often overlapping).
Most of my experience is with high performance software. C++/C and yeah lots of Go. My observations aren't related to performance. There's more to scale and providing a reliable service than performance. I am totally onboard with the idea that people often go horizontally when they don't need to performance-wise because they choose slow tools. This is not what I'm talking about here.
That said, there's probably a class of problems that are fine with just one VM. So if that's what you have, go for it (which is what I said in my original comment).
My app is a stateless monolith hosted with Fargate and RDS. I don't have to think about K8s, or look at it, or know how it works.
The pricing is relatively garbage, but it doesn't matter: now I don't have to think about devops as a concept.
I don't get how people are screwing up this cloud thing: it's as simple as you make it. Being pennywise and pound foolish trying to engineer complex solutions on the "cheaper" parts of cloud providers makes absolutely zero sense to me.
9 times out of 10 you hear X startup paying stupidly expensive bills it's because they tried to build out something that the cloud provider would have provided with a 50% markup but with an architecture you can't screw up.
Because we were dumb and thought k8s meant we had to go microservices.
> if the app can fit on a single VM …
Well of course. If and when it out grows the vm hopefully you’ve found product market fit and are bootstrapped and making money and have hired proper platform and dev teams to do it right and the single VM PoC is redone.
Or so that is what we are sold. In reality things happen piece-meal and more chaotically.
[1] https://web.archive.org/web/20200418170753/https://twitter.c...
But we're entering leaner times. Many younger people haven't been through this before. Others may not remember. Investors are going to demand more responsible spending, and better balance books, sooner.
If you can start on a shoestring and hold on until you need to scale, you have an advantage in this market that you didn't have 5 years ago.
That and a lot of the cloud stuff comes with an inherent complexity. Architecting for cloud hosted K8 and various cloud services comes not only with a $$ cost but a software architecture complexity & labour overhead.
A single server can do a lot these days. Many many businesses think they need to scale out of the box a lot more than they do.
You can spin up a single server in the cloud as simply (or more so) than in a colo. Then you can add a load balancer and auto scaling in a few hrs (or less depending on experience) if you reach the point where you need to scale.
Yes u need to get to Pmf first but you can do that without a kubernetes architecture or deploying a highly available app in 5 different zones.
AI does seem different in that regard, I think it is providing tremendous value to people. Just probably not in the random places where people are throwing it in where it doesn't actually fit.