Live data from Hacker News

Majority of web apps could just run on a single server

old.reddit.com

151–160 of 251 posts

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

#151

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.

You can also avoid most reboots by livepatching the kernel.

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

#152

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

If your database is a long ways off an edge connection could end up with a worse latency situation than TLS setup.

Distributed database is usually painful.

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

#153

Earlier quoted context omitted.

I mean it really depends on what your doing. If you’re just serving static content then of course you can get away with one small box. If you have user content that’s being constantly updated and inserted you need a lot more. You need databases, caches, and in our case elastic search (with ~10 billion documents). The data needs to be indexed 16 ways to Sunday to make sure that a user hitting the page with this filter…

> dynamic pages on the SQLite website typically do about 200 SQL statements each. [0]: https://www.sqlite.org/np1queryprob.html

How many of the request on sqlite.org go to the "dynamic pages"? I would assume by far most are on the static docs. The forum and other "dynamic" content is quite hidden.

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

#154
post #121

Earlier quoted context omitted.

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

Which LB doesn't support non-http flows?

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

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

Hipster devops was overcomplicated long before kubernetes.

In my 1st job we had autoscaling on AWS to handle peaks… except that our servers took about 30 minutes to do the upgrades, download gcc, compile all the needed python modules… We'd always reach the autoscaling limit because the new servers weren't doing anything at all. All of them would be downloading and compiling the same things.

I was very junior, but I told my boss if we shouldn't maybe use base images that already contained everything, instead of a default blank ubuntu for the servers.

The boss said no, because that wouldn't be agile.

The whole thing of using yaml files to configure servers already existed, it worked terribly.

It was basically meme development there. Including using mongodb for no reason at all, and using it badly so that every write was actually moving thousands of records around.

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

#156
Docker (and to an extend, Docker Swarm) is a good alternative where simplicity, lightweightness and stability are key points. Using it for almost 4 years in many projects with thousands of views each day, both on single or two VMs. No failures, no surprises, no pitfalls, automated CI via Git. No devops required.

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

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

> IMO the vast majority of software development happens in much smaller organizations than that

I guess it's okay to have an opinion about that, but this seems like something that should probably be a fact. Unfortunately, not sure I can find reliable stats on sizes of engineering organizations.

The thing is, while there are obviously lots of small companies, there are also some really big software development organizations out there. A company like Netflix has 2,500 engineers. Microsoft employs over 100,000 engineers. Walmart employs over 15,000 software developers.

You need a lot of little 10-50 engineer dev shops to add up to the combined size of the engineering orgs of the Fortune 500.

According to https://www.statista.com/statistics/507530/united-states-dis..., at least, 29.4+25.8 = 55.2% of the US "IT Industry" workforce are employed in companies with >100 employees. That's a Long way from telling us about sizes of engineering orgs though.

But still... I'd be careful assuming that the vast majority of developers are in organizations of less than 100 people.

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

#158

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…

this is the correct take, imo. i think a lot of projects start out overly complicated with the expectation of getting huge and needing to scale horizontally in a hurry, which a monolith cannot really do well. of course these expectations rarely become reality and you end up with some huge web of microservices that two devs need to orchestrate and manage for no benefit.

at Grafana we're now decoupling a monolith primarily so teams working on different parts can manage their own deployments/rollbacks/incidents independently of "official" monolith versions. it's a very hard/expensive refactor once you're at a scale of millions of users and hundreds of engs. but really an impossible thing to predict at inception.

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

#160

Earlier quoted context omitted.

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.

You can also avoid most reboots by livepatching the kernel.

Indeed. I come from the Windows world where things are a lot slower and there are less options for things like livepatching. So my "minute and a half downtime" is definitely pessimistic compared to what you can accomplish on a Linux server.
Post reply on HN