Hacker News Reader

Comment by Closi | Hacker News Reader

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.

View on HN

To note that quite a bit of the performance problems come when writing stuff. You can get away with A LOT if you accept 1. the current service doesn't do (much) writing and 2. it can live with slightly old data. Which I think covers 90% of use cases.

So you can end up with those services living on separate machines and connecting to read only db replicas, for virtually limitless scalability. And when it realizes it needs to do an update, it either switches the db connection to a master, or it forwards the whole request to another instance connected to a master 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. Splitting the software up and deploying the different parts on different machines can be a win here.

I reckon the average startup doesn't need any of that, not suggesting that monoliths aren't the way to go 90% of the time. But if you do need these things, you can still go the microservices route, but it still makes sense to stick to a single database if at all possible, for consistency and easier JOINs for ad-hoc queries, etc.

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!

No disagreement here. I love a good monolith.

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.

In this example, it's the job of the "database access layer service" to manage those processes and prevent issues.

But, terrible service name aside, this is a big reason why two services accessing the same database is a capital-H Huge anti-pattern, and really screams "using this project to learn how to do microservices."

Why would you break apart a microservice? Any why do you need to use/split into microservices anyway?

99% of apps are best fit as monolithic apps and databases and should focus on business value rather than scale they'll never see.

> 99% of apps are best fit as monolithic apps and databases and should focus on business value rather than scale they'll never see

You incorrectly assume that 99% of apps are building these architectures for scalability reasons.

When in reality it's far more for development productivity, security, use of third party services, different languages etc.

The vast majority is for (unreached) scalability reasons. Also monolithic app/db tend to have far higher productivity, and better security as well.

The only microservices architecture website I've ever dealt with has been an absolute nightmare compared to what the same monolith should have been.

reliability, sometimes sharding just means you don't have to get up in the middle of the night.

Totally agree.

I guess I just don't see the value in having a monolith made up of microservices - you might as well just build a monolith if you are going down that route.

And if your application fits the microservices pattern better, then you might as well go down the microservices pattern properly and not give them a big central DB.

The one advantage of microservice on a single database model is that it lets you test the independent components much more easily while avoiding the complexity of database sharding.

Where I work we are looking at it because we are starting to exceed the capabilities of one big database. Several tables are reaching the billions of rows mark and just plain inserts are starting to become too much.

Yeah, the at the billions of rows mark it definitely makes sense to start looking at splitting things up. On the other hand, the company I worked for split things up from the start, and when I joined - 4 years down the line - their biggest table had something like 50k rows, but their query performance was awful (tens of seconds in cases) because the data was so spread out.

Am I missing something?

2 ^ 30 is over 1 billion. So a properly indexed table with 1 billion rows will take a similar effort to search as a 30 row unindexed table.

Or are there other factors coming into play that I haven't thought of.

A thirty row table fits into the CPU cache, a 1 billion row table doesn't.

I disagree. Suppose you have an enormous DB that's mainly written to by workers inside a company, but has to be widely read by the public outside. You want your internal services on machines with extra layers of security, perhaps only accessible by VPN. Your external facing microservices have other things like e.g. user authentication (which may be tied to a different monolithic database), and you want to put them closer to users, spread out in various data centers or on the edge. Even if they're all bound to one database, there's a lot to recommend keeping them on separate, light cheap servers that are built for http traffic and occasional DB reads. And even more so if those services do a lot of processing on the data that's accessed, such as building up reports, etc.

You've not really built microservices then in the purest sense though - i.e. all the microservices aren't independently deployable components.

I'm not saying what you are proposing isn't a perfectly valid architectural approach - it's just usually considered an anti-pattern with microservices (because if all the services depend on a single monolith, and a change to a microservice functionality also mandates a change to the shared monolith which then can impact/break the other services, we have lost the 'independence' benefit that microservices supposedly gives us where changes to one microservice does not impact another).

Monoliths can still have layers to support business logic that are seperate to the database anyway.

Absolutely. I know someone who considers "different domains" (as in web domains) to count as a microservice!

What is the point of that? it doesn't add anything. Just more shit to remember and get right (and get wrong!)

Reply on news.ycombinator.com