Live data from Hacker News

Majority of web apps could just run on a single server

old.reddit.com

81–90 of 251 posts

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

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

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/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?

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.

Bitter. Experience.

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

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

Yeah, I'm an independent, selling these solutions. My minimum stack costs about $500/mo in AWS costs- and you could save 90% of that. But then you'd be paying me $20k more to set it up again when you expand to another dev team, while this way I can add your second dev team for $10k and practically zero additional AWS cost.

Going straight to overkill is good business sense for any company that's going to make it to a medium-sized business, and it's not going to be the differentiating factor for a company that burns out.

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

#83
post #28

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.

Well if you can spin up a new environment in less than a minute – does it matter? I mean if you are Facebook yes, but having worked with a lot of people building things like web shops – having a minute downtime I would say is fine because I've seen so many of these people shoot themself in the foot trying to build high-availability solutions and having constant downtimes just because they can't handle their own compl…

Our environments are entirely automated on AWS. It takes about 10 minutes to get an ALB and a mysql instance just on the AWS side. We've configured ECS to have the quickest health checks we can manage, and it still takes 3 minutes from the initial call before everything is happy.

Our environments are easily repeatable, they're very maintainable, but they're not quick to start up

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

#84
post #67

Earlier quoted context omitted.

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

> The root cause is the decade of zero interest rates which led to companies intentionally overcomplicating their stacks to justify neverending VC rounds. Extended hot take: the true customer of a company are the current and prospective holders of capital, whether VC, private investment, or public markets. Keeping them happy is the main goal of the exec. If your owners' portfolios include real estate, you push "back…

[deleted]

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

#85
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?"

I’ve lost startup jobs for basically this. As in “let’s focus on our mvp instead of adopting k8s and discussing “the definition of done” for literally six hours a week”. That one ran out of money and folded, sadly. They had tons of potential and a few bad hires.

But also on the other side, my time is expensive, engineering time is expensive, downtime is catastrophic for a new business. Some people want to spend 4 5 or 6 figures to save twenty dollars a month. Imagine my time is worth $500 an hour, if the effort to make something cheaper doesn’t pay for itself in a year then it’s probably a waste of resources.

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

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

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!

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

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

Yeah my search engine, back when it was hosted on a PC in my living room off domestic broadband would shrug off HN[1][2] without the fans even spinning faster than usual.

And like, internet search should be more resource heavy than the sort of websites that regularly do keel over to HN. Every query is like up to 50 MB in disk reads.

[1] https://news.ycombinator.com/item?id=28550764 [2] https://news.ycombinator.com/item?id=35611923

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

#88
post #22

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

Most companies are too full of themselves to do an honest assessment of their uptime requirements though. Every company out there loudly claims they need 100% uptime, which grifters will be happy to sell them knowing nobody will actually put their solution to the test and if it does fail they'll have a myriad of moving parts to shift the blame to. If you look at the very few things that do actually need 100% uptime (…

You are aware bloomberg presents at CNCF?

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

#89
post #3

A $5 VPS, with almost any app, can handle the front page of hacker news. If I remember correctly I'd even venture to say hacker news runs on a one or two core box. It should be the standard

My impression is that your standard wordpress + Apache + mod_php + mysql on same server install cannot, without plugins that improve wordpress' caching behaviour, and that's a large portion of the sites that do fall over.

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

#90
I agree w/ the sentiment, but the author doesn't seem to understand why people tend to like touching the customer at the edge. Since everyone is doing TLS these days, you have to do a TCP connect round-trip and a TLS round-trip before you can start yammering over a connection securely. So that's at least three round-trips. If you're one-way latency is 200ms, that's about a second of delay before things start happening. The benefit of the edge is you can establish a connection with an endpoint that's "nearby" with less latency for the TCP & TLS round-trips and then use a previously established connection (that does not require you to do the TCP & TLS roundtrips.)

There's still latency, but the impact of the round-trips at connection time is reduced.

Also, web-apps use horizontal scaling largely to reduce the impact of head of line blocking (where requests are queued up at the client waiting for the current request to complete.) Browsers will sometimes (often?) open multiple connections to the same endpoint to reduce HoL blocking impact. But, sometimes apps are inherently serial (you don't know what the next request is until you get the response back from the current request) so YMMV. Also... HTTP/2 and QUIC are cool, and I think most major browsers support either or both.

Amazon is also sort of (in)famous for triple-redundancy. Their apps run in at least three different availability zones (think different data centers) to avoid the impact of one data-center going down. Sure, it doesn't happen very often, but Amazon REALLY doesn't want their site to be down at all.

So sure... you COULD run the overwhelming majority of web apps on a single container in a small VM on a single machine somewhere, but it's more than just resource utilization. It's also responsiveness and resistance to single data-center failures.

But don't confuse my comments with a callous disregard for the OP's concerns. Dude has a point. I think anyone who tries to deploy a web app to AWS (or Azure or GCP or ...) is barraged with messages about how you have to deploy things in multiple data-centers and you're not a REAL developer until you've crafted your own customized templating engine for spitting out TerraForm or CloudFormation scripts that automagically deploy to N+1 unique datacenters.

There's probably a market out there for a simplified system that's "here's a simple {Node|Python|Ruby} app. Automagically distribute the backend to N different data-centers, maybe only one is up at a given time and the other N-1 are hot spares. And make the persistence tier indistinguishable from a local DB like Mongo or PostgreSQL (or some weird Prevayler-like thing.) Don't make me craft custom TF or CF to manage redundancy.)"

Please note. I'm not talking about using SAM.

To recap... I think the OP has a very valid point, but may not be familiar with all the current triple-redundancy dogma.

Post reply on HN