Live data from Hacker News

Majority of web apps could just run on a single server

old.reddit.com

101–110 of 251 posts

Re: Majority of web apps could just run on a single server

#101
post #61
post #9

I can confirm. I've had quite a few projects that made it to the front page of HN and handled the traffic like cake. All of them ran on 5$ digital ocean droplets. I accept some projects are more resource expensive than others, but majority of the time you can get away with a bit of asynchronous responses + scheduler/queue to spread the load horizontally over time. Unpopular opinion: I blame the new age devops culture…

> I've never come across a devops person who'd say "Hey, that sofware is too simple to prematurely scale for sudden spikes of irrational amounts of traffic, so why not just deploy it on a cheap vps?" Was a devops engineer at my previous job. We already had k8s clusters setup, pre-made CI templates and pre-tailored helm charts (along with monitoring and much more). All those things you (a developer) could mostly clone…

That's really the kicker for me.

When the company is set up well on k8s, then choose k8s. If the company is set up well on VPS, then choose VPS.

If it got neither, I'm unsure what's the better way to go on a greenfield. k8s has nice tooling, but part of that is required because it is massively complex.

But with managed k8s providers (e.g. GKE with autopilot) you can just put in proper CPU and memory limits and essentially get yourself a VPS provisioned without having to worry about anything by k8s measures.

If you have different pricing or location constraints, then it might be better to go with different models and some custom orchestration.

Re: Majority of web apps could just run on a single server

#102
post #9

I can confirm. I've had quite a few projects that made it to the front page of HN and handled the traffic like cake. All of them ran on 5$ digital ocean droplets. I accept some projects are more resource expensive than others, but majority of the time you can get away with a bit of asynchronous responses + scheduler/queue to spread the load horizontally over time. Unpopular opinion: I blame the new age devops culture…

Maybe that still counts as an unpopular opinion in the large, but I’ve never seen it be an unpopular opinion by the standards of really effective teams or really productive hackers I had the privilege to be around at times, and it seems to me that your good idea is coming back in a big way recently.

When I worked on teams that denominated egress in terrabits/s, TPS in millions or higher (sometime much higher), and daily warehouse ingest in petabytes it was just the default thing to spin up an instance and a hot standby (sometimes per region or something) if that’s all that was required, and containers and whatnot were used only in the context of bare-metal: you do usually want one level of indirection so containers are really useful if you’re racking metal from a small menu of SKUs.

But as for why it ever became conventional wisdom to wrap a venv inside a container on a hypervisor, often with multiple images composed on a dizzying array of low-friction SKUs?

I never got it and still don’t.

Re: Majority of web apps could just run on a single server

#103
I built a site for my dad recently. There was no delusions that it was going to become the next YouTube or anything, but it does require a lot of number-crunchy stuff, so I could justify a slightly-beefier-than-the-minimum box on Hetzner.

I had to resist every urge to do an elaborate Docker Swarm or Kubernetes setup, with replicated databases and async processing across message queues across different machines. I want to do that stuff, but realistically this site is going to get like 12 users a day at most, and doing that would have drastically increased the cost for really no perceivable benefit.

I ended up just installing NixOS, and doing everything with Flakes, on a single machine with a Postgres database. It was cheap and easy, and it probably has saved me a lot of unnecessary headaches; most websites aren't going to be the next Google.

Re: Majority of web apps could just run on a single server

#104
post #16

Earlier quoted context omitted.

The problem with devops replacing the old title “sysadmin” was that the dev part dragged in the worst thing about developer culture: the love of complexity and the tendency to build massive towers of it. Sysadmins usually avoided complexity because their attitude toward it was more sensible: it’s expensive, fragile, and tends to actually multiply failure modes. I also blame cloud marketing. This stuff is a gigantic m…

If you guys don't see the value of being able to click on a button on a website to deploy, perfectly, everytime over some guy sshing into the box and running git pull I dunno what to tell you.

Hey ! I click on a button to deploy. Turns out that button does the sshing but that still counts, right ?

Re: Majority of web apps could just run on a single server

#105
> websites and apps get This is very different from the majority of requests. The majority of requests are going to Google/Youtube/GCP, AWS, Azure, Meta, Netflix, and Clouldflare. I'm sure I'm forgetting someone, but you get the idea.

Medium-sized companies are also past the single server point, and a lot of us will end up working at these companies. While the poster's statement is true, it's only relevant for hobby projects (unless your hobby is devops) and early-stage startups.

Re: Majority of web apps could just run on a single server

#106
post #86

Earlier quoted context omitted.

You're not wrong. K8s, containers in general, aren't solving the problem. Developers write apps, engineers write software. One is installable, it respects the system it lives on, It can be tuned to use the hardware it has or share. The other, the other is a bucket of shit in a bag. The bag protects you and everyone else from it contaminating everything it touches. Containers dont solve the problem they just enable it…

> Developers write apps, engineers write software. That is a classic distinction without a difference! Engineers have been to engineering school. If you have not been to engineering school, you are not an engineer!

It's not a dead language, Im sorry the valley stole your title but that ship has sailed.

Re: Majority of web apps could just run on a single server

#107
post #74
post #9

I can confirm. I've had quite a few projects that made it to the front page of HN and handled the traffic like cake. All of them ran on 5$ digital ocean droplets. I accept some projects are more resource expensive than others, but majority of the time you can get away with a bit of asynchronous responses + scheduler/queue to spread the load horizontally over time. Unpopular opinion: I blame the new age devops culture…

I think that the $5 tier is a little tight for a web app as opposed to a crud app, but 2x $40 tiers is enough for a decent amount of traffic, with one as a failover. The problem is that containers are excellent, and IMO there's a gap in the market between "I want to run one container" and "I want a fully managed k8s cluster"

For my personal projects (that right now seem to revolve around April 1st jokes for people in my industry) - I've found a good middle ground to be K3s on a single Hetzner VM that I scale up and down if I think more/less people are going to be looking at it (i.e. between the 5 - 10 dollar/month price range)

I set this up with Terraform and some bash scripts. Infra as code is just too convenient to pass up on for something that I might not come back to for months at a time (and then ask - how did I set that up?), and containers too mean that I can play with some shiny fun technology one time, leave it in a box, and then come back to a clean-slate for the next thing that I want to play with without having to pay for a new VM etc.

Re: Majority of web apps could just run on a single server

#108

Can the majority of webapps run on a single machine? Probably. Do most of your customers expect close to 100% uptime? Yes. Does one machine provide the uptime required by your customers? Most definitely not.

I don't think the point here changes all that much if you change this to two servers and a load balancer. That's still a pretty simple setup. But I also think that many applications are far more tolerant of small outages than you imply. And a more complex setup also adds more points that can lead to an outage even though it reduces the chance that hardware will cause one.

Wouldn't you also need two load balancers then? Otherwise you've still got a single point of failure. And how do you keep the failover system in sync? It's a whole can of worms to promise 100% uptime. It's super rare that a server physically breaks and suddenly goes dark with less than a day's warning, and for most applications such a once-in-5-years event is tolerable if that means the hosting costs are divided by five as well (so far I'm ~10 years in and haven't experienced such an event yet; disks in RAID have broken but not a cpu or other SPOF)

Re: Majority of web apps could just run on a single server

#109
post #72

Earlier quoted context omitted.

Your still setting up K8's... I have scp'd my go binary and set it up in system d. Nothing about K8 or containers are light... they are buckets where bad devs hide the bodies in most cases.

kubernetes is also a static go binary (kubelet) deployed with systemd!

SO I should put my static go binary in a container, so you can deploy a static go binary to deploy the container with my static go binary in it.

Do you see how many extra steps that is.

Re: Majority of web apps could just run on a single server

#110

Can the majority of webapps run on a single machine? Probably. Do most of your customers expect close to 100% uptime? Yes. Does one machine provide the uptime required by your customers? Most definitely not.

You’d be surprised.

Most people never even test number 2. If your a novel or niche product, you can afford a “lot” of downtime

For number 3, it really all depend on your load. I’ve run most early stage startups on an incredibly simple setup with a proxy placed in front of an app server.

Occasionally, our monitoring will start reporting high p99’s so we go in and bump the servers to the next tier or scale horizontally just a bit more. Eventually, that breaks down but many startups will be well into Series A or Series B point. At that point, you know your customer’s needs and can hire dedicated engineers to solve reliability and uptime.

Post reply on HN