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

281–290 of 601 posts

Re: Use one big server

#281

Post by arwhatever »

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…

When migrating from [no-name CRM] to [big-name CRM] at a recent job, the manager pointed out that when [big-name CRM] goes down, it's in the Wall Street Journal, and when [no-name] goes down, it's hard to get their own Support Team to care!

Re: Use one big server

#282

Post by dsr_ »

thayne wrote: post #265
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…

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.

Here's the way it works for, say, Postgresql:

- you rsync or zfs send the database files from machine A to machine B. You would like the database to be off during this process, which will make it consistent. The big advantage of ZFS is that you can stop PG, snapshot the filesystem, and turn PG on again immediately, then send the snapshot. Machine B is now a cold backup replica of A. Your loss potential is limited to the time between backups.

- after the previous step is completed, you arrange for machine A to send WAL files to machine B. It's well documented. You could use rsync or scp here. It happens automatically and frequently. Machine B is now a warm replica of A -- if you need to turn it on in an emergency, you will only have lost one WAL file's worth of changes.

- after that step is completed, you give machine B credentials to login to A for live replication. Machine B is now a live, very slightly delayed read-only replica of A. Anything that A processes will be updated on B as soon as it is received.

You can go further and arrange to load balance requests between read-only replicas, while sending the write requests to the primary; you can look at Citus (now open source) to add multi-primary clustering.

Re: Use one big server

#283

Post by HeavyStorm »

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…

> they don't know how your distributed databases look, and oftentimes they really do not care

Nor should they.

Re: Use one big server

#284

Post by altdataseller »

IggleSniggle wrote: post #276
altdataseller wrote: post #161

Earlier quoted context omitted.

What if you are using the database as a system of record to index into a real search engine like Elasticsearch? For a product where you have tons of data to search from (ie text from web pages)

In regards to Elasticsearch, you basically opt-in to which behavior you want/need. You end up in the same place: potentially losing some data points or introducing some "fuzziness" to the results in exchange for speed. When you ask Elasticsearch to behave in a guaranteed atomic manner across all records, performing locks on data, you end up with similar constraints as in a RDBMS. Elasticsearch is for search. If you'r…

Having just an Elasticsearch index without also having the data in a primary store like a RDMS is an anti-pattern and not recommended by almost all experts. Whether you want to call it a “system of record”, i wont argue semantics. But the point is, its recommended hacing your data in a primary store where you can index into elasticsearch.

Re: Use one big server

#285

Post by lrvick »

A consequence of one-big-server is decreased security. You become discouraged from applying patches because you must reboot. Also if one part of the system is compromised, every service is now compromised.

Microservices on distinct systems offer damage control.

Re: Use one big server

#286

Post by tzs »

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…

I don't understand the pedestal approach. Do you put your server in the pedestal, so the pedestal is in effect your data center?

Re: Use one big server

#287

Post by yomkippur »

What holds me back from doing this is how will I reduce latency from the calls coming from other side of the world when OVHcloud seemingly does not have datacenters all over the world? There is an noticeable lag when it comes to multiplayer games or even web applications.

Re: Use one big server

#288

Post by corford »

mwcampbell wrote: post #238
MrStonedOne wrote: post #97

/tg/station, the largest open source multiplayer video game on github, gets cloudheads trying to help us "modernize" the game server for the cloud all the time. Here's how that breaks down: The servers (sorry, i mean compute) cost the same (before bandwidth, more on that at the bottom) to host one game server as we pay (amortized) per game server to host 5 game servers on a rented dedicated server. ($175/month for th…

> $175/month for the rented server with 64gb of ram and a 10gbit uplink) Wow, what provider is that?

Hetzner's PX line offers 64GB ECC RAM, Xeon CPU, dual 1TB NVME for < $100/month. A dedicated 10Gbit b/w link (plus 10Gbit NIC) is then an extra ~$40/month on top (incls. 20TB/month traffic, with overage billed at $1/TB).

Re: Use one big server

#289

Post by sebzim4500 »

phkahler wrote: post #120
treis wrote: post #53

Earlier quoted context omitted.

I think it's more of a shield against upper management. AWS going down is treated like an act of god rendering everyone blameless. But if it's your one big server that goes down then it's your fault.

>> AWS going down is treated like an act of god rendering everyone blameless. Someone decided to use AWS, so there is blame to go around. I'm not saying if that blame is warranted or not, just that it sounds like a valid thing to say for people who want to blame someone.

I doubt anyone has ever been fired for choosing AWS. I know for a fact that people have been fired after deciding to do it on bare metal and then it didn't work very well.

Re: Use one big server

#290

Post by jasonlotito »

phkahler wrote: post #120
treis wrote: post #53

Earlier quoted context omitted.

I think it's more of a shield against upper management. AWS going down is treated like an act of god rendering everyone blameless. But if it's your one big server that goes down then it's your fault.

>> AWS going down is treated like an act of god rendering everyone blameless. Someone decided to use AWS, so there is blame to go around. I'm not saying if that blame is warranted or not, just that it sounds like a valid thing to say for people who want to blame someone.

"I think it's more of a shield against upper management."

"Someone decided to use AWS, so there is blame to go around."

Upper management.

Post reply on HN