Live data from Hacker News

Use one big server

specbranch.com

181–190 of 601 posts

Re: Use one big server

#181

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…

To clarify the advice, at least how I believe it should be done… Use One Big Database Server… … and on it, use one software database per application. For example, one Postgres server can host many databases that are mostly* independent from each other. Each application or service should have its own database and be unaware of the others, communicating with them via the services if necessary. This makes splitting up i…

OP mentioned joining, so they were definitely talking about a single database

Re: Use one big server

#182
post #89

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.

This is one of those problems that basically no one has. RTT from Japan to Washington D.C. is 160ms. There's very few applications where that amount of additional latency matters.

It adds up surprisingly quickly when you have to do a TLS handshake, download many resources on pageload etc. The TLS handshake alone costs 3 round-trips over the network.

Re: Use one big server

#183
It blows my mind people are spending $2000+ per month for a server they can get used for $4000-5000 one time only cost.

VMWare + Synology Business Backup + Synology C2 backup is our way of doing business and never failed us for over 7 years. Why do people spend so much money for cloud while they can host it themselves less than 5% of the cost? (2 year usage assumed).

Re: Use one big server

#184
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.

That's true, unless you need (1) Different programming languages e.g. you're written your app in Java but now you need to do something for which the perfect Python library is available. (2) Different parts of your software need different types of hardware. Maybe one part needs a huge amount of RAM for a cache, but other parts are just a web server. It'd be a shame to have to buy huge amounts of RAM for every server.…

These are both true - but neither requires service-oriented-architecture.

You can split up your applicaiton into chunks that are deployed on seperate hardware, and use different languages, without composing your whole architecture into microservices.

A monolith can still have a seperate database server and a web server, or even many different functions split across different servers which are horizontally scalable, and be written in both java and python.

Monoliths have had seperate database servers since the 80s (and probably before that!). In fact, part of these applications defining characteristics at the enterprise level is that they often shared one big central database, as often they were composed of lots of small applications that would all make changes to the central database, which would often end up in a right mess of software that was incredibly hard to de-pick! (And all the software writing to that database would, as you described, be written in lots of different languages). People would then come along and cake these central databases full of stored procedures to make magic changes to implement functionality that wasn't available in the legacy applications that they can't change because of the risk and then you have even more of a mess!

Re: Use one big server

#185

Earlier quoted context omitted.

To clarify the advice, at least how I believe it should be done… Use One Big Database Server… … and on it, use one software database per application. For example, one Postgres server can host many databases that are mostly* independent from each other. Each application or service should have its own database and be unaware of the others, communicating with them via the services if necessary. This makes splitting up i…

OP mentioned joining, so they were definitely talking about a single database

You can still do a ton of joining.

I’d start with a monolith, that’s a single app, single database, single point of ownership of the data model, and a ton of joins.

Then as services are added after the monolith they can still use the main database for ease of infra development, simpler backups and replication, etc. but those wouldn’t be able to be joined because they’re cross-service.

Re: Use one big server

#187

Earlier quoted context omitted.

To clarify the advice, at least how I believe it should be done… Use One Big Database Server… … and on it, use one software database per application. For example, one Postgres server can host many databases that are mostly* independent from each other. Each application or service should have its own database and be unaware of the others, communicating with them via the services if necessary. This makes splitting up i…

OP mentioned joining, so they were definitely talking about a single database

[deleted]

Re: Use one big server

#188

It blows my mind people are spending $2000+ per month for a server they can get used for $4000-5000 one time only cost. VMWare + Synology Business Backup + Synology C2 backup is our way of doing business and never failed us for over 7 years. Why do people spend so much money for cloud while they can host it themselves less than 5% of the cost? (2 year usage assumed).

I've tried it all except this, including renting bare metal. Nowadays I'm in the cloud but not cloudy camp. Still, I'm intrigued.

Apart from the $4-5k server, what are your running costs? Licenses? Colocation? Network?

Re: Use one big server

#190
> The big drawback of using a single big server is availability. Your server is going to need downtime, and it is going to break. Running a primary and a backup server is usually enough, keeping them in different datacenters.

What about replication? I assume the 70k postgres IOPS fall to the floor when needing to replicate the primary database to a backup server in a different region.

Post reply on HN