Live data from Hacker News

Use one big server

specbranch.com

261–270 of 601 posts

Re: Use one big server

#261

Earlier quoted context omitted.

Why open yourself to random $300k bills from Amazon when the alternative is wasting a $5/month server?

I don’t understand what these numbers are referring to.

One is a normal size of those rare, but not too rare bills people get from Amazon when their unused unoptmized application gets some surprise usage.

The other is how much it costs to have an always-on server paid VPS capable of answering the once a day request you specified.

Re: Use one big server

#263

I have been doing this for two decades. Let me tell you about bare metal. Back in the day we had 1,000 physical servers to run a large scale web app. 90% of that capacity was used only for two months. So we had to buy 900 servers just to make most of our money over two events in two seasons. We also had to have 900 servers because even one beefy machine has bandwidth and latency limits. Your network switch simply can…

Let me take you back to March, 2020. When millions of Americans woke up to find out there was a pandemic and they would be working from home now. Not a problem, I'll just call up our cloud provider and request more cloud compute. You join a queue of a thousand other customers calling in that morning for the exact same thing. A few hours on hold and the CSR tells you they aren't provisioning anymore compute resources. east-us is tapped out, central-europe tapped out hours ago, California got a clue and they already called to reserve so you can't have that either.

I use cloud all the time but there are also blackswan events where your IaaS can't do anymore for you.

Re: Use one big server

#265
post #64
post #56

Yep, there's a premium on making your architecture more cloudy. However, the best point for Use One Big Server is not necessarily running your big monolithic API server, but your database. Use One Big Database. Seriously. If you are a backend engineer, nothing is worse than breaking up your data into self contained service databases, where everything is passed over Rest/RPC. Your product asks will consistently want t…

This is absolutely true - when I was at Bitbucket (ages ago at this point) and we were having issues with our DB server (mostly due to scaling), almost everyone we talked to said "buy a bigger box until you can't any more" because of how complex (and indirectly expensive) the alternatives are - sharding and microservices both have a ton more failure points than a single large box. I'm sure they eventually moved off t…

One issue I've seen with this is that if you have a single, very large database, it can take a very, very long time to restore from backups. Or for that matter just taking backups.

I'd be interested to know if anyone has a good solution for that.

Re: Use one big server

#266
post #28

Earlier quoted context omitted.

> competitively provide residential > Internet service to offset costs. I uh. Providing residential Internet for an apartment complex feels like an entire business in and of itself and wildly out of scope for a small business? That's a whole extra competency and a major customer support commitment. Is there something I'm missing here?

It depends on the scale - it does not have to be a major undertaking. You are right, it is a whole extra competency and a major customer support commitment , but for a lot of the entrepreneurial folk on HN quite a rewarding and accessible learning experience. The first time I did anything like this was in late 1984 in a small town in Iowa where GTE was the local telecommunication utility. Absolutely abysmal Internet…

This is some old school stuff right here. I have a hard time believing this sort of gumption and moxy are as prevalent today.

> The best perk is the number of parking spaces the requisite orange utility traffic cone opens up for you.

That's hilarious.

Re: Use one big server

#267
post #265
post #64

Earlier quoted context omitted.

This is absolutely true - when I was at Bitbucket (ages ago at this point) and we were having issues with our DB server (mostly due to scaling), almost everyone we talked to said "buy a bigger box until you can't any more" because of how complex (and indirectly expensive) the alternatives are - sharding and microservices both have a ton more failure points than a single large box. I'm sure they eventually moved off t…

One issue I've seen with this is that if you have a single, very large database, it can take a very, very long time to restore from backups. Or for that matter just taking backups. I'd be interested to know if anyone has a good solution for that.

Presumably it doesn't matter if you break your DB up into smaller DBs, you still have the same amount of data to back up no matter what. However, now you also have the problem of snapshot consistency to worry about.

If you need to backup/restore just one set of tables, you can do that with a single DB server without taking the rest offline.

Re: Use one big server

#268
One thing to keep in mind is separation. The prod environment should be completely separated from the dev ones (plural, it should be cheap/fast to spin up dev environments). Access to production data should be limited to those that need it (ideally for just the time they need it). Teams should be able to deploy their app separately and not have to share dependencies (i.e operating system libraries) and it should be possible to test OS upgrades (containers do not make you immune from this). It's kinda possible to sort of do this with 'one big server' but then you're running your own virtualized infrastructure which has it's own costs/pains.

Definitely also don't recommend one big database, as that becomes a hairball quickly - it's possible to have several logical databases for one physical 'database 'server' though.

Re: Use one big server

#269

I may be misunderstanding, but it looks like the micro-services comparison here is based on very high usage. Another use for micro-services, like lambda, is exactly the opposite. If you have very low usage, you aren't paying for cycles you don't use the way you would be if you either owned the machine, or rented it from AWS or DO and left it on all the time (which you'd have to do in order to serve that randomly-arri…

If you have microservices that truly need to be separate services and have very little usage, you probably should use things like serverless computing. It scales down to 0 really well. However, if you have a microservice with very little usage, turning that service into a library is probably a good idea.

Yes. I think that the former case is the situation we’re in. Lambdas are annoying (the whole AWS is annoying!) but, as you say, scales to 0 very well.

Re: Use one big server

#270
post #263

I have been doing this for two decades. Let me tell you about bare metal. Back in the day we had 1,000 physical servers to run a large scale web app. 90% of that capacity was used only for two months. So we had to buy 900 servers just to make most of our money over two events in two seasons. We also had to have 900 servers because even one beefy machine has bandwidth and latency limits. Your network switch simply can…

Let me take you back to March, 2020. When millions of Americans woke up to find out there was a pandemic and they would be working from home now. Not a problem, I'll just call up our cloud provider and request more cloud compute. You join a queue of a thousand other customers calling in that morning for the exact same thing. A few hours on hold and the CSR tells you they aren't provisioning anymore compute resources.…

I never had this problem on AWS though I did see some startups struggle with some more specialized instances. Are midsize companies actually running into issues with non-specialized compute on AWS?
Post reply on HN