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

351–360 of 601 posts

Re: Use one big server

#351

Post by hsn915 »

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…

No. Your users have no idea that you rely on AWS (they don't even know what it is), and they don't think of it as a valid or reasonable excuse as to why your service is down.

Re: Use one big server

#352

Post by [deleted] »

arwhatever wrote: post #323

Recent team I was on used one big server. Wound up spawning off a separate thread from our would-be stateless web api to run recurring bulk processing jobs. Then coupled our web api to the global singleton-esque bulk processing jobs thread in a stateful manner. The wrapped actors up on actors on top of everything to try to wring as much performance as possible out of the big server. Then decided they wanted to have a…

[deleted]

Re: Use one big server

#353

Post by rcarmo »

I once fired up an Azure instance with 4TB of RAM and hundreds of cores for a performance benchmark.

htop felt incredibly roomy, and I couldn’t help thin how my three previous projects would fit in with room to spare (albeit lacking redundancy, of course).

Re: Use one big server

#354

Post by hot_gril »

kedean wrote: post #348
cogman10 wrote: post #342

Earlier quoted context omitted.

> 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 to combine these data sources (they don't know how your distributed databases look, and oftentimes they really do not care). This works until it doesn't and then you land in the position…

Many databases can be distributed horizontally if you put in the extra work, would that not solve the problems you're describing? MariaDB supports at least two forms of replication (one master/replica and one multi-master), for example, and if you're willing to shell out for a MaxScale license it's a breeze to load balance it and have automatic failover.

Not without big compromises and a lot of extra work. If you want a truly horizontally scaling database, and not just multi-master for the purpose of availability, a good example solution is Spanner. You have to lay your data out differently, you're very restricted in what kinds of queries you can make, etc.

Re: Use one big server

#355

Post by rkagerer »

runjake wrote: post #349
Flow wrote: post #347

Earlier quoted context omitted.

Do you have Spectre countermeasures active in the kernel of that machine?

What does it matter, in this context? If it's about bare metal vs. virtual machines, know that Spectre affects virtual machines, too.

I think they are implying disabling them (if on) could squeeze you out a bit more performance.

Re: Use one big server

#356

Post by bergkvist »

jethro_tell wrote: post #338
AtNightWeCode wrote: post #210

Earlier quoted context omitted.

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

if you have multiple micro services updating the database you need to have a database access layer service as well. there's some real value with abstraction and microservices but you can try to run them against a monolithic database service

No amount of abstraction is going to save you from the problem of 2 processes manipulating the same state machine.

Re: Use one big server

#357

Post by kbenson »

kedean wrote: post #348
cogman10 wrote: post #342

Earlier quoted context omitted.

> 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 to combine these data sources (they don't know how your distributed databases look, and oftentimes they really do not care). This works until it doesn't and then you land in the position…

Many databases can be distributed horizontally if you put in the extra work, would that not solve the problems you're describing? MariaDB supports at least two forms of replication (one master/replica and one multi-master), for example, and if you're willing to shell out for a MaxScale license it's a breeze to load balance it and have automatic failover.

For what it's worth, I think distributing horizontally is also much easier if you're already limited your database to specific concerns by splitting it up in different ways. Sharding a very large database with lots of data deeply linked sounds like much more of a pain than something with a limited scope that isn't too deeply linked with data because it's already in other databases.

To some degree, sharding brings in a lot of the same complexities as different microservices with their own data store, in that you sometimes have to query across multiple sources and combine in the client.

Re: Use one big server

#358

Post by hot_gril »

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'd say, one big database per service. Often times there are natural places to separate concerns and end up with multiple databases. If you ever want to join things for offline analysis, it's not hard to make a mapreduce pipeline of some kind that reads from all of them and gives you that boundless flexibility.

Then if/when it comes time for sharding, you probably only have to worry about one of those databases first, and you possibly shard it in a higher-level logical way that works for that kind of service (e.g. one smaller database per physical region of customers) instead of something at a lower level with a distributed database. Horizontally scaling DBs sound a lot nicer than they really are.

Re: Use one big server

#360

Post by amrox »

Joeri wrote: post #254
rbanffy wrote: post #150

Earlier quoted context omitted.

> Use One Big Database. I emphatically disagree. I've seen this evolve into tightly coupled microservices that could be deployed independently in theory, but required exquisite coordination to work. If you want them to be on a single server, that's fine, but having multiple databases or schemas will help enforce separation. And, if you need one single place for analytics, push changes to that space asynchronously. Ha…

I have done both models. My previous job we had a monolith on top of a 1200 table database. Now I work in an ecosystem of 400 microservices, most with their own database. What it fundamentally boils down to is that your org chart determines your architecture. We had a single team in charge of the monolith, and it was ok, and then we wanted to add teams and it broke down. On the microservices architecture, we have man…

> What it fundamentally boils down to is that your org chart determines your architecture.

This is Conway’s law

https://en.wikipedia.org/wiki/Conway%27s_law

Post reply on HN