[Olphs]

Do you think it's good idea to migrate from monolith to microservices before scaling the team?

We are essentially doing this right now, I personally don't think the teams are yet large enough to warrant this migration, but leadership says that we can't scale further before we have microservices. Imo most of the problems could be solved with increased testing and knowledge about the system. The tech also could definitely still scale with just by boosting the hardware and occasional performance passes on slow endpoints/queries.

[yakshaving_jgt]

> but leadership says that we can't scale further before we have microservices

These are depressingly common alarm bells.

There are companies with valuations over 12 figures which don't do microservices, so the scaling justification is dubious at best.

[mikeryan]

can't scale further before we have microservices.

Scale what? Load (Seems not)

Scale the team? This is often an overlooked aspect of microservices you're able to isolate the domain knowledge to smaller services and hire more specialized engineers who can focus on a specific silo of the app and only have to work to discrete APIs.

Scale features? There's a legit argument to be made that if you see yourself going to a microservice architecture in the future based on your current codebase or product roadmap that doing it sooner then later is always going to be preferable. The bigger the monolith the harder it is to unwind. It could also be that there's some tech debt that's something of a limiting factor, making the change in architecture could be an opportunity to address some of that.

[iamflimflam1]

Are you doing “extreme” micro services? A esperare database for each micro service, one endpoint for each microservice etc.. or the slightly more sensible - let’s split the monolith up into obviously independent system (very much like the article talks about).

[hardware2win]

>extreme microservices

>separate databases

Isnt it like the basic thing?

[ohgodplsno]

If your database isn't the performance issue and those two services spent 99% of the response time on calculating the 15755th digit of pi, not separating the database isn't a problem. Similarly, if both of your services need to fetch some user information, but you haven't created a user information service with its own database they could both talk to, having a shared database is fine.

Splitting each and every service with its own database, talking to other services to access their database by default is cargo-cult behavior. All it's going to do is make it hell for you to work on those services.

[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?

[dontlaugh]

Why even bother then? If your code shares the same database then it’s a single service. Anything else is just unnecessary overhead.

[withinboredom]

Wut? You can share databases and simply not write to the shared database because it’s a read only replica. Saves a bunch of overhead…

There’s a dozen reasons to share a db.

[dontlaugh]

Then you're depending on the schema of the other service, which means you can't deploy them independently. You might as well have kept everything in a single service.