4 ms·

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

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.

Closi 4y ago
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.
- adgjlsfhk1 4y ago
  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.
Gigachad 4y ago
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.
- nicoburns 4y ago
  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.
  - collyw 4y ago
    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.
    - adrianN 4y ago
      A thirty row table fits into the CPU cache, a 1 billion row table doesn't.
threeseed 4y ago
> 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.
- jethro_tell 4y ago
  reliability, sometimes sharding just means you don't have to get up in the middle of the night.
- DangitBobby 4y ago
  The only microservices architecture website I've ever dealt with has been an absolute nightmare compared to what the same monolith should have been.
- manigandham 4y ago
  The vast majority is for (unreached) scalability reasons. Also monolithic app/db tend to have far higher productivity, and better security as well.

Closi 4y ago

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.

adgjlsfhk1 4y ago
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.

Gigachad 4y ago

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.

nicoburns 4y ago
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.
- collyw 4y ago
  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.
  - adrianN 4y ago
    A thirty row table fits into the CPU cache, a 1 billion row table doesn't.

threeseed 4y ago

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

jethro_tell 4y ago
reliability, sometimes sharding just means you don't have to get up in the middle of the night.
DangitBobby 4y ago
The only microservices architecture website I've ever dealt with has been an absolute nightmare compared to what the same monolith should have been.
manigandham 4y ago
The vast majority is for (unreached) scalability reasons. Also monolithic app/db tend to have far higher productivity, and better security as well.