Live data from Hacker News

Majority of web apps could just run on a single server

old.reddit.com

131–140 of 251 posts

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

#131
post #22

If you don't care about downtime or reliability, sure.

The discussion isn't about reliability. It's about resource wastage. It's a bit silly to try to change the topic of the discussion.

Reliability through redundancy is simple, particularly when you aren't replicating multiple machines / machine images.

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

#132

Earlier quoted context omitted.

> 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.…

Isn't that just because Kubernetes makes it unreasonably hard to configure access to logs like that?

No, it is simple to setup.

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

#133

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.

Multiple machines don't automatically mean a better uptime. Outside of the regular maintenance, many problems can affect multiple instances, not just one.

(Regular maintenance meaning OS updates needing a reboot, which happens like what? Once per month for a minute?)

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

#134

Gonna throw out an anti-cirlcenjerk take: We know. Absolutely no one has ever said that your super basic webapp that has the latency requirements of "make sure it works", an SLO of "it's fine most of the time", and a code base under 10k lines of code worked on by one guy, needs these super complicated systems. Even FAANG will run internal services and dashboards on a single binary, but when every second of downtime c…

Unfortunately many of these super-complicated systems run at odds to having a reliable and fast, system even when every second of downtime can be translated into lost money.

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

#135
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"

Why not use a single Fargate task?

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

#136

Earlier quoted context omitted.

> 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.…

Isn't that just because Kubernetes makes it unreasonably hard to configure access to logs like that?

It's really not that hard if you got proper users.

But doing proper users on k8s is hard. I suspect they just run with admin credentials and no real way to generate users.

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

#137
post #121

Earlier quoted context omitted.

> All those things you (a developer) could mostly clone, slightly customize and ship both to a development k8s cluster and to a prod k8s cluster (with all the safety nets already in place). How did/does the devs create, test new code and debug issues? Can they do that locally on their local laptop? If so, how?

> How did/does the devs create, test new code and debug issues? Can they do that locally on their local laptop? If so, how? All those questions are irrelevant to how software gets deployed. Do whatever you want on your laptop.

Then I assume you have a custom Kubernetes LB that can handle non-HTTP TCP and UDP traffic because you choosing Kubernetes and the design restrictions that comes with it does not affect how the dev solves problems?

The underlying orchestrator definitely affects how the software needs to behave and is definitely not irrelevant.

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

#138
post #81
post #61

Earlier quoted context omitted.

> 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…

Yes you took the bait! > This was at a 100+ developers organisation. IMO the vast majority of software development happens in much smaller organisations than that. Dev Ops still matters there, and the requirements are different. I am working in an organisation with one and a half developers. I am lobbying that the third of fourth developer concentrates on Dev Ops here. It is very important. Look at the back up/recove…

> I am working in an organisation with one and a half developers. I am lobbying that the third of fourth developer concentrates on Dev Ops here.

not sure you're doing the right thing here. you might want to consider hiring some kind of linux guy that can can do some basic devops. or maybe hire some devops contractor that can work with you on a part-time basis and "curate" some specific aspects of your operations.

I've seen this done in the past: so you've got this consultant on retainer, and you tell them something like: "i've got this issue, can we do something about it? our constraints would be x y z" and the consultant would make 1-3 proposals (different approaches, different pricing levels, different ETAs etc) and then you agree on what gets done. The key aspect here is that a good devops consultant can get stuff done very quickly.

> It is very important. Look at the back up/recovery procedures at your organisation. Has there ever been a fire drill? Are you sure the back ups are sound? Can you recover? What if data corruption occurred a week/month ago. Have you a back up of the uncorrupted data?

Yes (to all questions). I ended up in working in heavily regulated environments. All the things you mentioned were not just niceties, but mandatory by legal requirements.

> That is a very unsexy aspect of Dev Ops, and without somebody dedicated to the job, your backups will not be any of those things.

That's basic system administration. Most devops engineers are former sysadmins.

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

#139

Gonna throw out an anti-cirlcenjerk take: We know. Absolutely no one has ever said that your super basic webapp that has the latency requirements of "make sure it works", an SLO of "it's fine most of the time", and a code base under 10k lines of code worked on by one guy, needs these super complicated systems. Even FAANG will run internal services and dashboards on a single binary, but when every second of downtime c…

> every second of downtime can be translated into lost money, then you begin to care

You don't even need to be at FAANG-scale for this. Once you have paying customers, you care.

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

#140
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…

But there's a middle ground somewhere.

The current DevOps culture comes from the FAANG guys who really are getting a bazillion requests per second. In the last decade I worked for Amazon, Avalara and Audible Magic. None of these could build an app around a Digital Ocean droplet.

But I think you're pointing out there are PLENTY of useful webapps that can run on a minimal system.

I'm just curious where the middle ground is. Cause I think we've all seen sites blow up after a reference on HN or SlashDot or whatever and by the time you get there the only thing you see is a stock error from the PHP engine saying "My MySQL Engine is Melting" or somesuch.

It would be very cool if one could write an app using {NODE|Ruby|Python|Whatever} and have the infrastructure around it notice when things spike and do some magic under the hood to spin up new containers in geographically distributed data centers and scale up a simple persistence tier.

That way you could move forward with a SIMPLE application instance and not freak out that you'll disappoint new users if there's a spike in demand. You know, sort of like what AWS Lambda was supposed to be.

Hmm... I think I might have come up with a plan for my next startup. Thank you for speaking your truth.

[Edit: To re-iterate, I think I'm saying it's just as wrong to think a small, simple app needs Amazon-level redundancy and immediate scalability as it is to say Amazon could run on a single machine. But... the "Slash-Dotted Website Goes Down" scenario is real and there should be SOMETHING the industry could do that's easier on people than to force them into a custom AWS ECS solution across multiple continents.]

Post reply on HN