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

41–50 of 601 posts

Re: Use one big server

#41

Post by ericd »

reillyse wrote: post #12

Nope. Multiple small servers. 1) you need to get over the hump and build in multiple servers into your architecture from the get go (the author says you need two servers minimum), so really we are talking about two big servers. 2) having multiple small servers allows us to spread our service into different availability zones 3) multiple small servers allows us to do rolling deploys without bringing down our entire se…

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.

Re: Use one big server

#42

Post by dekhn »

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 absolutely enjoy working on a big fat server that I have all to myself.

Re: Use one big server

#43

Post by hans1729 »

taylodl wrote: post #38
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…

Users are much more sympathetic to outages when they're widespread. But, if there's a contractual SLA then their sympathy doesn't matter. You have to meet your SLA. That usually isn't a big problem as SLAs tend to account for some amount of downtime, but it's important to keep the SLA in mind.

This just holds when you are b2b. If you’re serving end users, they don’t care about the contract, they care about their UX.

Re: Use one big server

#44

Post by Nextgrid »

softfalcon wrote: post #37

So... I guess these folks haven't heard of latency before? Fairly sure you have to have "one big server" in every country if you do this. I feel like that would get rather costly compared to geographically distributed cloud services long term.

As opposed, to "many small servers" in every country? The vast majority of startups out there run out of a single AWS region with a CDN caching read-only content. You can apply the same CDN approach to a bare-metal server.

Re: Use one big server

#45

Post by bombcar »

saulrh wrote: post #28
stevenjgarner wrote: post #6

If you are not maxing out or even getting above 50% utilization of 128 physical cores (256 threads), 512 GB of memory, and 50 Gbps of bandwidth for $1,318/month , I really like the approach of multiple low-end consumable computers as servers. I have been using arrays of Intel NUCs at some customer sites for years with considerable cost savings over cloud offerings. Keep an extra redundant one in the array ready to sw…

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

You're missing "apartment complex" - you as the service provider contract with the apartment management company to basically cover your costs, and they handle the day-to-day along with running the apartment building.

Done right, it'll be cheaper for them (they can advertise "high speed internet included!" or whatever) and you won't have much to do assuming everything on your end just works.

The days where small ISPs provided things like email, web hosting, etc, are long gone; you're just providing a DHCP IP and potentially not even that if you roll out carrier-grade NAT.

Re: Use one big server

#46

Post by nostrebored »

tboyd47 wrote: post #29
nostrebored wrote: post #5

As someone who's worked in cloud sales and no longer has any skin in the game, I've seen firsthand how cloud native architectures improve developer velocity, offer enhanced reliability and availability, and actually decrease lock-in over time. Every customer I worked with who had one of these huge servers introduced coupling and state in some unpleasant way. They were locked in to persisted state, and couldn't scale…

Could confirmation bias affect your analysis at all? How many companies went cloud-first and then ran out of money? You wouldn't necessary know anything about them. Were the scaling problems your single-server customers called you to solve unpleasant enough put their core business in danger? Or was the expense just a rounding error for them?

From this and the other comment, it looks like I wasn't clear about talking about SMB/ME rather than a seed/pre-seed startup, which I understand can be confusing given that we're on HN.

I can tell you that I've never seen a company run out of money from going cloud-first (sample size of over 200 that I worked with directly). I did see multiple businesses scale down their consumption to near-zero and ride out the pandemic.

The answer to scaling problems being unpleasant enough to put the business in danger is yes, but that was also during the pandemic when companies needed to make pivots to slightly different markets. Doing this was often unaffordable from an implementation cost perspective at the time when it had to happen. I've seen acquisitions fall through due to an inability to meet technical requirements because of stateful monstrosities. I've also seen top-line revenue get severely impacted when resource contention causes outages.

The only times I've seen 'cloud-native' truly backfire were when companies didn't have the technical experience to move forward with these initiatives in-house. There are a lot of partners in the cloud implementation ecosystem who will fleece you for everything you have. One such example was a k8s microservices shop with a single contract developer managing the infra and a partner doing the heavy lifting. The partner gave them the spiel on how cloud-native provides flexibility and allows for reduced opex and the customer was very into it. They stored images in a RDBMS. Their database costs were almost 10% of the company's operating expenses by the time the customer noticed that something was wrong.

Re: Use one big server

#47

Post by taylodl »

throwaway787544 wrote: post #16

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…

That's a good point about cloud services being retail. My company gets a very large discount from one of the most well-known cloud providers. This is available to everybody - typically if you commit to 12 months of a minimum usage then you can get substantial discounts. What I know is so far everything we've migrated to the cloud has resulted in significantly reduced total costs, increased reliability, improved scalability, and is easier to enhance and remediate. Faster, cheaper, better - that's been a huge win for us!

Re: Use one big server

#48

Post by terafo »

FartyMcFarter wrote: post #30
kubb wrote: post #3

As per usual, don't copy Google if you don't have the same requirements. Google Search never goes down. HN goes down from time and nobody minds. Google serves tens (hundreds?) of thousands of queries per second. HN serves ten. HN is fine with one server because it's small. How big is your service going to be? Do that boring math :)

Even Google search has gone down apparently, for five minutes in 2013: https://www.cnet.com/tech/services-and-software/google-goes-...

There were huge availability issues as recent as December 14th 2020, for 45 minutes.

Re: Use one big server

#49

Post by notjustanymike »

ramesh31 wrote: post #14
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…

Nobody ever got fired for buying IBM!

We may need to update this one, I would definitely fire someone today for buying IBM.

Re: Use one big server

#50

Post by tjoff »

andrepew wrote: post #32
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…

This is a huge one -- value in outsourcing blame. If you're down because of a major provider outage in the news, you're viewed more as a victim of a natural disaster rather than someone to be blamed.

This seems like a recently popular exaggeration, I'd wager no one but a select few in the HN-bubble actually cares.

You will primarily be judged by how much of an inconvenience the outage was to every individual.

The best you can hope for is that the local ISP gets the blame, but honestly. It can't be more than a rounding error in the end.

Post reply on HN