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

241–250 of 601 posts

Re: Use one big server

#241

Post by pdpi »

gregmac wrote: post #8

> However, cloud providers have often had global outages in the past, and there is no reason to assume that cloud datacenters will be down any less often than your individual servers. A nice thing about being in a big provider is when they go down a massive portion of the internet goes down, and it makes news headlines. Users are much less likely to complain about your service being down when it's clear you're just c…

Another advantage is that the third-party services you depend on are also likely to be on one of the big providers, so it's one less point of failure.

Re: Use one big server

#242

Post by phpisthebest »

lordleft wrote: post #10

Interesting write-up that acknowledges the benefits of cloud computing while starkly demonstrating the value proposition of just one powerful, on-prem server. If it's accurate, I think a lot of people are underestimating the mark-up cloud providers charge for their services. I think one of the major issues I have with moving to the cloud is a loss of sysadmin knowledge. The more locked in you become to the cloud, the…

Given that AWS holds up the entire Amazon Company, and is a large part of Bezo's personal wealth, I think the market up is pretty good.

Re: Use one big server

#243

Post by twblalock »

All your eggs in one basket? A single host, really? Curmudgeonly opinions about microservices, cloud, and containers? Nostalgia for the time before 2010? All here. All you are missing is a rant about how the web was better before JavaScript.

It’s sad to see this kind of engineering malpractice voted to the top of HN. It’s even sadder to see how many people agree with it.

Re: Use one big server

#244

Post by Koshkin »

ericd wrote: post #205
Koshkin wrote: post #95

Earlier quoted context omitted.

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.

In theory, VMs should only be needed to run different OSes on one big box. Otherwise, what should have sufficed (speaking of what I 'prefer') is a multiuser OS that does not require additional layers to ensure security and proper isolation of users and their work environments from each other. Unfortunately, looks like UNIX and its descendants could not deliver on this basic need. (I wonder if Multics had something of a better design in this regard.)

Re: Use one big server

#245

Post by tsmarsh »

BenoitEssiambre wrote: post #226
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 glad this is becoming conventional wisdom. I used to argue this in these pages a few years ago and would get downvoted below the posts telling people to split everything into microservices separated by queues (although I suppose it's making me lose my competitive advantage when everyone else is building lean and mean infrastructure too). In my mind, reasons involve keeping transactional integrity, ACID compliance…

'over the wire' is less obvious than it used to be.

If you're in k8s pod, those calls are really kernel calls. Sure you're serializing and process switching where you could be just making a method call, but we had to do something.

I'm seeing less 'balls of mud' with microservices. Thats not zero balls of mud. But its not a given for almost every code base I wander into.

Re: Use one big server

#246

Post by z3t4 »

gregmac wrote: post #8

> However, cloud providers have often had global outages in the past, and there is no reason to assume that cloud datacenters will be down any less often than your individual servers. A nice thing about being in a big provider is when they go down a massive portion of the internet goes down, and it makes news headlines. Users are much less likely to complain about your service being down when it's clear you're just c…

You also have to calculate in the complexity of running thousands of servers vs running just one server. If you run just one server it's unlikely to go down even once in it's lifetime. Meanwhile cloud providers are guaranteed to have outages due to the share complexity of managing thousands of servers.

Re: Use one big server

#247

Post by throwaway9870 »

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…

How do you use one big database when some of your info is stuck in an ERP system?

Re: Use one big server

#248

Post by PeterCorless »

pclmulqdq wrote: post #166
PeterCorless wrote: post #125

We have a different take on running "one big database." At ScyllaDB we prefer vertical scaling because you get better utilization of all your vCPUs, but we still will keep a replication factor of 3 to ensure that you can maintain [at least] quorum reads and writes. So we would likely recommend running 3x big servers. For those who want to plan for failure, though, they might prefer to have 6x medium servers, because…

I think this is the right approach, and I really admire the work you do at ScyllaDB. For something truly critical, you really do want to have multiple nodes available (at least 2, and probably 3 is better). However, you really should want to have backup copies in multiple datacenters, not just the one. Today, if I were running something that absolutely needed to be up 24/7, I would run a 2x2 or 2x3 configuration with…

Exactly. Regional distribution can be vital. Our customer Kiwi.com had a datacenter fire. 10 of their 30 nodes were turned to a slag heap of ash and metal. But 20 of 30 nodes in their cluster were in completely different datacenters so they lost zero data and kept running non-stop. This is a rare story, but you do NOT want to be one of the thousands of others that only had one datacenter, and their backups were also stored there and burned up with their main servers. Oof!

https://www.scylladb.com/2021/03/23/kiwi-com-nonstop-operati...

Re: Use one big server

#249

Post by skeeter2020 »

altdataseller wrote: post #93
belak wrote: 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…

What if your product simply stores a lot of data (ie a search engine) How is that weird?

This is not typically going to be stored in an ACID-compliant RDBMS, which is where the most common scaling problem occurs. Search engines, document stores, adtech, eventing, etc. are likely going to have a different storage mechanism where consistency isn't as important.

Re: Use one big server

#250

Post by zokier »

If you have just two servers how are you going to load-balance and fail-over them? Generally you need at least 3 nodes for any sort of quorum?
Post reply on HN