[hardware2win]

But if 1 database dies, then all microservices dont work

So why are you even using them?

The benefit of microservices is also reliability, which you just threw away

Isnt this basically distributed monolith?

So you combined bad things of both worlds!

Single point of failure of monolith

And deployment difficulties and need for saga like patterns to deal with network trickiness from distributed designs

Whats the point?

[vsareto]

It wouldn't be unreasonable to say database products are an order of magnitude or two more reliable than code written by many teams.

There's some advantage in having code separation first, but it is admittedly not a benefit of reliability.

These half-measures are generally done when converting an older architecture to a newer one. I don't think many places actually do big bang conversions/releases going from monolith -> microservices where you can do everything correctly. That runs counter to the CI/CD trends that we taught them.

The other issue might be a conflict in database table constraints (or worse, triggers/sprocs) that don't match your microservice boundaries, so the business ends up wanting wins faster than your team can resolve those conflicts.

[ohgodplsno]

Once again, cargo-cultish reasoning, where it's all or nothing.

1/ Replication & read-only copies for resilience exist, to allow you to function in degraded state if your database goes down.

2/ If the database for one service goes down, any service that calls it ends up being down anyways. No, being able to respond with a 503 that says that megatron-service is down and you can't fetch the data isn't different from responding with a regular 500 saying that the database is down and you can't fetch the data..

3/ All of your calls do not necessarily end up calling the database. Your service starts even if the DB is down, some calls will simply fail. You're providing a degraded service.

4/ If they need similar data, you really don't want to have two databases holding that data. Because I can promise you, the cost of having to handle replication, de-duplication, synchronization, configuration, GDPR compliance, etc on X databases is infinitely higher than having a database where you simply turn on a write replica that fails over.

5/ SPOF-fear is bullshit, you always have a single point of failure in your stuff. 2FA service is down ? Sure, your entire service isn't dead, but hey, users can't log in, sounds like a pretty fucking big point of failure. Microservices just distributes your single point of failure into a dozen, equally bad, equally hard to track down problems. And even in a monolith, you can easily work around these problems: what kind of fucking code have you seen that a whole server will not start because it can't connect to a database ?

6/ You do not need your servers to be distributed. That is bullshit, and if you are at the scale where you actually need to, it'll be the least of your problems.

[hardware2win]

1st point is really good, make sense!

Your 3rd point shows scenerio where 2nd point is not applicable.

>what kind of fucking code have you seen that a whole server will not start because it can't connect to a database ?

Server? Idk. App? Sure, CRUD app that requires config/filling cache dictionaries from db

>Once again, cargo-cultish reasoning, where it's all or nothing.

Thats fair point, so what are micro services doing for you then?

Allowing teams to deploy independently?

[ohgodplsno]

The third point is directly linked to the second point: If you are doing a call that requires access to that database, whether it's going through two services or one, will lead to an error (just a different one). If you are doing a call that doesn't require it, it'll go through smoothly.

>Server? Idk. App? Sure, CRUD app that requires config/filling cache dictionaries from db

Not once in my life have I written either a server or an app that will completely fail upon not having a database (the .php files written in early college years don't count.). Either of these can function in a degraded way without the database; In the case of an app, still display your UI, still display everything that can be displayed without the presence of the database, and warn that said database is down. The same way you'd do with micro services.

>Thats fair point, so what are micro services doing for you then? >Allowing teams to deploy independently?

Where I currently work, our services are gathered in various bills of materials to have a set of components that we know works, and that the client requires (government work is always fun). Multiply this by 20 different environments, and you're quite happy to have those BoMs. However, it could very much be done without microservices. Microservices allow us to bypass some problems: One part of the server really, really, really need to read a lot of data and to build a graph before starting, which can in some cases take upwards of two hours. Anything that doesn't depend on this would be very happy to start up without waiting for that to happen, so this is when you split it.

Don't do microservices because it's the hip thing to do. Micro services are just one more tool to alleviate large problems. Sometimes, splitting it into two services is the right thing to do. Sometimes, sharing the database is the right thing to do.