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

191–200 of 251 posts

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

#191

Post by bcaxis »

sjducb wrote: post #31

The real reason for cloud micro service architecture is legacy code. Imagine you’ve inherited a 10 year old PHP monolith. The code is almost indecipherable and the business wants new features in a timely and predictable manner. The easiest way is to implement the new features in their own micro services. Sure it makes the complexity problem worse, but that’s a problem for someone else in five years time.

You could solve this other ways. Build a new better monolith and have a reverse proxy route between them and slowly update and move routes over. You will get through a rewrite slowly one bit at a time.

If you keep the same database schema this should generally work pretty well.

I migrated a terribly written web app this way, it worked pretty well.

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

#192

Post by Nextgrid »

ardel95 wrote: post #187
Nextgrid wrote: post #54

Earlier quoted context omitted.

Running two instances of a stateful application in parallel forces you to consider nasty and hard problems such as CAP theorem, etc. If your requirements allow, it's much easier to have an active-standby architecture over active-active.

Totally. But most applications are not stateful.

Most applications as a whole are absolutely stateful. Individual components of them might not be (app servers are stateless with the DB/Redis containing all state), but the whole app from an external client's perspective is stateful.

If we're talking about reliability/outage recovery, we're considering the application as one single unit visible from the external client's perspective - so everything including the DB (or equivalent stateful component) must be redundant.

Sadly this is also where a lot of cloud-native tooling and best practices fall short. There are endless ways to run stateless workloads redundantly, but stateful/CAP-bound workloads seem to be ignored/handwaved away.

I've seen my fair share of stacks that are doing the right thing when it comes to the easy/stateless parts (redundancy, infinite horizontal scalability), but everyone kinda ignores the elephant in the room which is the CAP-bound primary datastore that everything else depends on, which isn't horizontally scalable and its failover/replication behavior is ignored/misunderstood and untested, and they only get away with it because modern HW is reliable enough that its outage/failover windows are rare enough that the temporary misunderstood/unexpected/undefined behavior during those flies under the radar.

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

#193

Post by therealdrag0 »

feverzsj wrote: post #32

If your app doesn't server more requests than sqlite.org daily, you shouldn't pay more than it. > sqlite.org answers more than 500,000 HTTP requests per day (about 5 or 6 per second) delivering about 200GB of content per day (about 18 megabits/second) on a $40/month Linode. The load average on this machine normally stays around 0.5. [0]: https://sqlite.org/althttpd/doc/trunk/althttpd.md

I don’t think this is controversial. 5rps is nothing.

Anyone saying otherwise failed to do basic capacity planning. Granted at any given time the number of junior/untrained/nontraditional engineers outnumber senior engineers so it’s not surprising things are build out of proportion, and I suspect that’s what’s behind the majority of the anecdotes.

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

#194

Post by Nextgrid »

echoangle wrote: post #190
ardel95 wrote: post #187

Earlier quoted context omitted.

Totally. But most applications are not stateful.

Is it really an application if it’s not stateful? Maybe you’re managing the state client-side which makes it easier but I wouldn’t call a plain website an application, or am I missing something?

At the smallest level, even every byte of an in-flight HTTP request is still state. State, and for that matter "uptime" really depend on what the application/service ultimately does and what the agreement/SLA with the end-customer is.

The correct high-availability solution should take business requirements into account and there is no silver bullet. Running everything on a $5 VPS is no silver bullet, but neither is your typical "cloud-native" "best practice" stack that everyone keeps cargo-culting which often leads to unnecessary cost while leaving many hard questions (such as replicating CAP-bound stateful databases) unanswered.

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

#195

Post by Nextgrid »

marginalia_nu wrote: post #87
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…

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

The shift to cloud-based workloads (with oversubscribed CPUs and mandatory networked storage) means that a lot of people lost track of just how fast physical hardware (even mid-range consumer-grade) has become.

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

#196

Post by jauntywundrkind »

jameshart wrote: post #141
acabal wrote: post #56

At Standard Ebooks we serve a respectable number of page views and ebooks each month - and have been on the front page of HN three or four times - all of it done with a single 4GB VPS. And the only reason we upgraded to 4GB from 2GB is because we needed more RAM for the server to build the extremely large Decline and Fall of the Roman Empire ebook - if it weren't for that, our 2GB server would still have been just fi…

More applications should consider git as a content management database. It's great architecture. Statically serving files built by a CI process running on the server is very tidy. But let's be clear, your serving infrastructure is able to be that simple because you outsource donation management to https://fundraising.fracturedatlas.org , contribution management to https://github.com/standardebooks , collaboration, me…

Those other workloads don't sound particularly taxing to me. Many get very sparse traffic; hosting a donation page, web newsgroup/discussions, and user management need not drastically scale up the serving footprint here.

Those hosted services mainly are about not needing to pay the human management/ownership costs.

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

#197

Post by fatnoah »

A long time ago, an F100 company acquired my messaging startup. We hosted client APIs and a web application for 2M monthly users sending 1B messages/month on a single AWS medium CPU server and a SQL Server DB. The rest of our infra was entirely for redundancy and monitoring to enable our 99.995% uptime.

Post-acquisition, the AWS budget I was given to maintain our infra was almost 20x the actual cost, and based on infra that company used to host similar traffic.

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

#198

Post by makerdiety »

polishdude20 wrote: post #161
makerdiety wrote: post #68

Earlier quoted context omitted.

> Similarly, other applications I built so far all also run under five euro VMs. There's no denying you might need more because you have serious peaks in traffic that you cannot handle with only one server, but do the accounting. A simple proportional-integral-derivative controller equipped onto your server resource can help you see if future traffic spikes are occurring. The question is, what kind of person is able…

Wait what would a PID controller do? What would it be controlling?

You're supposed to be repurposing the controller into a reporter. Since you don't need control, you can instead just use the PID portion of the PID controller.

But you can also attach an actual automatic control for when the sensor reports a positive traffic influx prediction value.

And I think stuff like Kubernetes includes this feature. Go figure.

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

#199

Post by ardel95 »

Nextgrid wrote: post #192
ardel95 wrote: post #187

Earlier quoted context omitted.

Totally. But most applications are not stateful.

Most applications as a whole are absolutely stateful. Individual components of them might not be (app servers are stateless with the DB/Redis containing all state), but the whole app from an external client's perspective is stateful. If we're talking about reliability/outage recovery, we're considering the application as one single unit visible from the external client's perspective - so everything including the DB (…

That’s a pretty pedantic interpretation of the word application. In the context of software owned by most teams, that they may decide to run on single vs multiple hosts most applications are absolutely stateless. Most applications outsource state to another system, like a relational database, a managed no-SQL store, or an object store.

And so no, most teams don’t need to worry about the hard problems you bring up.

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

#200

Post by jameshart »

jauntywundrkind wrote: post #196
jameshart wrote: post #141

Earlier quoted context omitted.

More applications should consider git as a content management database. It's great architecture. Statically serving files built by a CI process running on the server is very tidy. But let's be clear, your serving infrastructure is able to be that simple because you outsource donation management to https://fundraising.fracturedatlas.org , contribution management to https://github.com/standardebooks , collaboration, me…

Those other workloads don't sound particularly taxing to me. Many get very sparse traffic; hosting a donation page, web newsgroup/discussions, and user management need not drastically scale up the serving footprint here. Those hosted services mainly are about not needing to pay the human management/ownership costs.

The real win this architecture has is outsourcing its content management database to GitHub. That's where all the complicated stuff like permissions and authentication and change notifications and approval workflows, that make up the bulk of complexity in most bespoke business applications, as well as all the tricky stuff of managing the actual files that the contributors are managing, is all happening. It's a smart decision! There's a lot involved in running a system like that reliably - outsourcing it is a great idea.

If they were to do that in house, by switching to a self-hosted GitLab, say, well... that could be run on a single machine (https://docs.gitlab.com/ee/administration/reference_architec...) at the cost of having to manage scheduled downtime for upgrades. If the user base or activity level grew beyond what that server could handle (and given that the intention of this project is to cultivate an ever growing community of contributors that might be a concern)... the next stop up is an eight node system: https://docs.gitlab.com/ee/administration/reference_architec....

Post reply on HN