Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Use one big server

specbranch.com

Post reply on HN
Print view View original

201–210 of 601 posts

Re: Use one big server

#201

Post by marcosdumay »

bob1029 wrote: post #96
bombcar wrote: post #70

Earlier quoted context omitted.

> Any technical decisions about how many instances to have and how they should be spread out needs to start as a business decision and end in crisp numbers about recovery point/time objections, and yet somehow that nearly never happens. Nobody wants to admit that their business or their department actually has a SLA of "as soon as you can, maybe tomorrow, as long as it usually works". So everything is pretend-enginee…

> Nobody wants to admit that their business or their department actually has a SLA of "as soon as you can, maybe tomorrow, as long as it usually works". So everything is pretend-engineered to be fifteen nines of reliability (when in reality it sometimes explodes because of the "attempts" to make it robust). I have yet to see my principal technical frustrations summarized so concisely. This is at the heart of everythi…

> The # of businesses that are actually sensitive to >1 minute of annual downtime are already running on top of IBM mainframes and have been for decades.

Is there any?

My bank certainly has way less than 5 9s of availability. It's not a problem at all. Credit/debit card processors seem to stay around 5 nines, and nobody is losing sleep over it. As long as your unavailability isn't all on the Christmas promotion day, I never saw anybody losing any sleep over web-store unavailability. The FED probably doesn't have 5 9's of availability. It's way overkill for a central bank, even if it's one that process online interbank transfers (what the FED doesn't).

The organizations that need more than 5 9's are probably all on the military and science sectors. And those aren't using mainframes, they certainly use good old redundancy of equipment with simple failure modes.

Re: Use one big server

#202

Post by bee_rider »

dekhn wrote: post #42

Science advances as RAM on a single machine increases. For many years, genomics software was non-parallel and depending on having a lot of RAM- often a terabyte or more- to store data in big hash tables. Converting that to distributed computing was a major effort and to this day many people still just get a Big Server With Lots of Cores, RAM, and SSD. Personally after many years of working wiht distributed, I absolut…

On the other hand in science, it sure is annoying that the size of problems that fit in a single node is always increasing. PARDISO running on a single node will always be nipping at your heels if you are designing a distributed linear system solver...

Re: Use one big server

#203

Post by manigandham »

cal85 wrote: post #35

> In comparison, buying servers takes about 8 months to break even compared to using cloud servers, and 30 months to break even compared to renting. Can anyone help me understand why the cloud/renting is still this expensive? I'm not familiar with this area, but it seems to me that big data centers must have some pretty big cost-saving advantages (maintenance? heat management?). And there are several major providers…

You're paying a premium for flexibility. If you don't need that then there are far cheaper options like some managed hosting from your local datacenter.

Re: Use one big server

#204

Post by Closi »

manigandham wrote: post #200
Closi wrote: post #61

Earlier quoted context omitted.

Breaking apart a stateless microservice and then basing it around a giant single monolithic database is pretty pointless - at that stage you might as well just build a monolith and get on with it as every microservice is tightly coupled to the db.

Why would you break apart a microservice? Any why do you need to use/split into microservices anyway? 99% of apps are best fit as monolithic apps and databases and should focus on business value rather than scale they'll never see.

Totally agree.

I guess I just don't see the value in having a monolith made up of microservices - you might as well just build a monolith if you are going down that route.

And if your application fits the microservices pattern better, then you might as well go down the microservices pattern properly and not give them a big central DB.

Re: Use one big server

#205

Post by ericd »

Koshkin wrote: post #95
ericd wrote: post #41

Earlier quoted context omitted.

On a big server, you would probably be running VMs rather than serving directly. And then it becomes easy to do most of what you're talking about - the big server is just a pool of resources from which to make small, single purpose VMs as you need them.

Why VMs when you can use containers?

If you prefer those, go for it. I like my infra tech to be about as boring and battle tested as I can get it without big negatives in flexibility.

Re: Use one big server

#206

Post by throwaway894345 »

cfors wrote: 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…

I'm pretty happy to pay a cloud provider to deal with managing databases and hosts. It doesn't seem to cause me much grief, and maybe I could do it better but my time is worth more than our RDS bill. I can always come back and Do It Myself if I run out of more valuable things to work on.

Similarly, paying for EKS or GKE or the higher-level container offerings seems like a much better place to spend my resources than figuring out how to run infrastructure on bare VMs.

Every time I've seen a normal-sized firm running on VMs, they have one team who is responsible for managing the VMs, and either that team is expecting a Docker image artifact or they're expecting to manage the environment in which the application runs (making sure all of the application dependencies are installed in the environment, etc) which typically implies a lot of coordination between the ops team and the application teams (especially regarding deployment). I've never seen that work as smoothly as deploying to ECS/EKS/whatever and letting the ops team work on automating things at a higher level of abstraction (automatic certificate rotation, automatic DNS, etc).

That said, I've never tried the "one big server" approach, although I wouldn't want to run fewer than 3 replicas, and I would want reproducibility so I know I can stand up the exact same thing if one of the replicas go down as well as for higher-fidelity testing in lower environments. And since we have that kind of reproducibility, there's no significant difference in operational work between running fewer larger servers and more smaller servers.

Re: Use one big server

#207

Post by marcosdumay »

abrax3141 wrote: post #139

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…

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

Re: Use one big server

#208

Post by zhoujianfu »

10 years ago I had a site running on an 8GB of ram VM ($80/mo?) that ran a site serving over 200K daily active users on a completely dynamic site written in PHP running MySQL locally. Super fast and never went down!

Re: Use one big server

#209

Post by marcosdumay »

cal85 wrote: post #35

> In comparison, buying servers takes about 8 months to break even compared to using cloud servers, and 30 months to break even compared to renting. Can anyone help me understand why the cloud/renting is still this expensive? I'm not familiar with this area, but it seems to me that big data centers must have some pretty big cost-saving advantages (maintenance? heat management?). And there are several major providers…

Renting is not very expensive. 30 months is a large share of a computer's lifetime, and you are paying for space, electricity, and internet access too.

Re: Use one big server

#210

Post by AtNightWeCode »

Closi wrote: post #61
cfors wrote: 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…

Breaking apart a stateless microservice and then basing it around a giant single monolithic database is pretty pointless - at that stage you might as well just build a monolith and get on with it as every microservice is tightly coupled to the db.

Agree. Nothing worse than having different programs changing data in the same database. The database should not be an integration point between services.
Post reply on HN