Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Majority of web apps could just run on a single server

old.reddit.com

Post reply on HN
Print view View original

41–50 of 251 posts

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

#41

Post by fabian2k »

master_crab wrote: post #14

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.

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

#42

Post by hparadiz »

banku_brougham wrote: post #35
hparadiz wrote: post #27

Earlier quoted context omitted.

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.

People arent missing the value, nobody is saying it wont perform as advertised -- the discussion is about the cost.

Setting up a testing & deploy via a CI script is basically free. AWS gives away CodeDeploy for free. Ansible is open source. I learned all this stuff working on open source stuff where platforms like GitHub give you free compute time.

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

#43

Post by rmbyrro »

hparadiz wrote: post #27
api wrote: 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.

The discussion here is not the method of deployment, but the infra architecture.

You don't need k8s, containers, and multiple cloud instances to automate deployment.

It's perfectly possible and simple to implement a button to deploy on a single machine.

Heck, on OVH or Hetzner, you can have a dedicated bare metal machine with many cores and RAM exclusive to you, cheaper than famous cloud instances. These bare metals will handle what takes sometimes hundreds of containers to handle, with a much simple and easy to maintain infra.

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

#44

Post by fsloth »

tambourine_man wrote: post #34
lewisjoe wrote: 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'm convinced it's the hiring that has shaped the scene. If you're hiring, you want to be able to add/replace people as easily as possible. If you're being hired, you want to charge as much as you can. And to satisfy those two demands, the current web stack is great. Almost like it's been built for it. It's got very little to do with the tech itself, a lot more to do with market dynamics. That's the problem it's tryi…

I can’t confirm but it does look like a significant portion of current software engineering zeitgeist is developed for compartmentalized careerism with a good splash of non-value adding complexity.

If that keeps food on the table and the wheels of business spinning, fine, but I’ve seen this leading to situations where a simple thing expands to a role, and then department and … oh, hi, enterprise software, it’s you!

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

#45

Post by eddd-ddde »

vbezhenar wrote: post #19
eddd-ddde wrote: post #5

We use k8s at $JOB for literally no reason other than some engineer decided he wanted to learn k8s. It's the worst, I don't even get to see my server logs because "that would mean giving you access to the entire thing". I'm not a k8s person but surely that has to be missing something. We could literally make do with a cloudflare 5$ plan and have left to work with. With better integration, and better DX.

> It's the worst, I don't even get to see my server logs because "that would mean giving you access to the entire thing". I'm not a k8s person but surely that has to be missing something. I'm pretty sure it's possible to configure access to logs, not to the entire thing (whatever that means). He's probably lazy and does not want to bother. Besides, you should have centralized logging using loki or something similar.…

I know, but we don't get any. I legit had to do logging on my end to a _database_ because they weren't a fan of something like say new relic or similar.

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

#46

Post by toast0 »

hparadiz wrote: post #36
sjducb wrote: post #25

Earlier quoted context omitted.

Master slave failover will give you less than a second of downtime.

Pretty much any provisioned vm can be split down the middle. Got 4 cpus and 4gb of ram? Congrats you have two vms with 2 cpus and 2gb of ram. Throw them into a 50/50 load balancer and never have any downtime.

Two vms on the same machine doesn't help when the machine fails.

Also, I sure hope your loadbalancers don't suck. I've worked with some that had worse uptime than my servers, and worse capacity too. Went back to putting the two host addresses in DNS, which is mostly fine, but means a lot of waiting when you want to take a host out of rotation for disruptive maintenance.

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

#47

Post by Nextgrid »

tambourine_man wrote: post #34
lewisjoe wrote: 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'm convinced it's the hiring that has shaped the scene. If you're hiring, you want to be able to add/replace people as easily as possible. If you're being hired, you want to charge as much as you can. And to satisfy those two demands, the current web stack is great. Almost like it's been built for it. It's got very little to do with the tech itself, a lot more to do with market dynamics. That's the problem it's tryi…

The root cause is the decade of zero interest rates which led to companies intentionally overcomplicating their stacks to justify neverending VC rounds. Early prospective employees took notice and adjusted their skills as a result.

The dangerous part is that in the meantime we've got brand new and budding talent that actually took this charade seriously and effectively got high on their own supply, seeing this performance art as the actual normality even in a post-ZIRP world where tech/engineering is primarily there to drive business profits and not a VC mating ritual.

The only winners are the cloud/infra/tooling providers who got an entire generation of "engineers" to do perpetuate their con without even realizing it.

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

#48

Post by ocdtrekkie »

master_crab wrote: post #14

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 how close to 100% uptime you can get on one machine with well-engineered software. Schedule an automated update and reboot for a time and day of the week you have the fewest customers monthly, and if you have an SSD as the boot drive, unless you are a huge company nobody will notice or care that at 4 AM on Sunday your service was down for a minute and a half.

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

#49

Post by moondev »

rmbyrro wrote: post #43
hparadiz wrote: post #27

Earlier quoted context omitted.

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.

The discussion here is not the method of deployment, but the infra architecture. You don't need k8s, containers, and multiple cloud instances to automate deployment. It's perfectly possible and simple to implement a button to deploy on a single machine. Heck, on OVH or Hetzner, you can have a dedicated bare metal machine with many cores and RAM exclusive to you, cheaper than famous cloud instances. These bare metals…

You can deploy k8s on a single machine though. This way you get the benefit of a standardized, documented API without the burden of multiple machines.

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

#50

Post by dukeyukey »

api wrote: post #16
lewisjoe wrote: 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…

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…

I swear, I've come to identify myself simple stacker. Complexity should be avoided wherever reasonably possible. But where it's not, it's best left and maintained with the devs who want it.
Post reply on HN