[sleiben]

We use the microservices architecture as a single team and don’t have any issues with this for many years. The key is to have a monorepo and stay consistent by following strict coding guidelines.

In my opinion it makes the backend way more resilient than a monolith.

Don’t kill me for this opinion please ;)

[BoorishBears]

How does it make the backend more resilient than a monolith? Do you not realize you have multiple instances of a monolith or something?

[jabradoodle]

There are some reasons it may lead to resiliency; another teams features slow dB queries not being on your db, teams not mutating data in a shared db, memory leaks in someone elses feature not taking your app down. Being able to choose language/libraries and tune the runtime to your requirements.

Of course when you replace function calls with network calls, make everything asynchronous and eventually consistent, there is a lot of work to do to not end up with a less reliable system.

[BoorishBears]

A monolith doesn't force a single database.

A monolith doesn't force a single process. IPC is still simpler and cheaper than network calls.

A monolith doesn't force never having an external service for a specialized use case, or FFI.

[jabradoodle]

> IPC is still simpler and cheaper than network calls.

I specifically called out the extra complexity of network calls in microservices, not sure if you read the full comment.

> A monolith doesn't force a single process

I'm not convinced; if my small/specific code has it's own process, I would say it's a microservice. Sure, we can have replicas for redundancy, that doesn't mean I won't have reliability issues when my process is crashed.

> A monolith doesn't force a single database.

> A monolith doesn't force never having an external service for a specialized use case, or FFI

True, sadly it doesn't usually work this way. People take the path of least resistance.

Also once you add multiple DBs you start to get into eventual consistency; which is one of the harder parts of microservices.

[BoorishBears]

> I specifically called out the extra complexity of network calls in microservices, not sure if you read the full comment.

Calling out networking doesn't preclude me from mentioning IPC. IPC isn't limited to network calls, it can be as simple as shared memory and hit millions of OPS: github.com/OpenHFT/Chronicle-Map

> I'm not convinced; if my small/specific code has its own process, I would say it's a microservice.

And you'd be wrong. A core tenant of microservices is being able to individually deploy your microservices. If I spin up a new process for some high risk, highly memory intensive process I've introduced a fraction of the operational complexity of a seperate server and retained the core value proposition of reducing its blast radius if things go south.

Of course again, if you're having so much trouble handle writing software that's reliable that you being to consider isolating instability as a top benefit from your IPC setup instead of a tiny value add... it might be a sign you're not ready for microservices.

_

> True, sadly it doesn't usually work this way. People take the path of least resistance.

> Also once you add multiple DBs you start to get into eventual consistency; which is one of the harder parts of microservices.

You're making my point: If you don't have the engineering chops as a team to make a robust monolith, you definitely don't have the skills and resources to start looking at microservices.

Eventual consistency is not inherent to having multiple databases. If I have an oft changing ephemeral set of data that only affects one feature and it's creating an impedance mismatch with our main datastore, nothing is stopping us from pulling in Redis for all the queries we were previously sending to Postgres, and as far as anything relying on that feature is concerned, nothing at all changed.

With even half decent engineering, Redis going down doesn't break any differently than it would have for a microservice: you define the same error boundaries as before and the failure case ends up the same.

I mean seriously, if your team can't handle having a second data store, imagine the bedlam when you're trying to handle multiple languages across multiple data sources in a non-centralized manner?

_

Microservices are a pattern for companies where a "microservice" gets the kind of development and devops support that would justify spinning off a new mid-sized enterprise.

When you're Netflix your `api/movies/[movieId]/subtitles` endpoint is serving the kind of traffic most companies will never see in their lifetime and needs optimizations that maybe 100 companies in the world will ever need.

For the rest of us EC2 has 224C/488T CPU 24,000 GB RAM machines with 38 GBPs I/O bandwidth. If your business ever scales so far that you outgrow that, throw some of that X Billion dollar valuation money at the problem and build your microservices.

[jabradoodle]

> Calling out networking doesn't preclude me from mentioning IPC.

You made the same point I made as though it was in contradiction to what I said. Adding a network call adds complexity, yes.

> A core tenant of microservices is being able to individually deploy your microservices.

And why would you not want this to be independently deployable?

> You're making my point: If you don't have the engineering chops as a team to make a robust monolith, you definitely don't have the skills and resources to start looking at microservices.

Firstly, you never made that point. Also, I never argued against it, in fact I agree completely.

> Microservices are a pattern for companies where a "microservice" gets the kind of development and devops support that would justify spinning off a new mid-sized enterprise.

Disagree, netflix has >1000 microservices.

[ahoka]

Bad input crashes app, monolith fails over, other instance crashes. Full outage. Assuming proper vertical separation, this risk can be reduced by microservices.

[elktown]

It might just as well be increased by microservices due to fragile dependency chains and just different people working async and what not.

[ahoka]

Maybe read my comment again.

[elktown]

Care to enlighten me? Your comment reads like "assuming the best case scenario for X and worst case scenario for Y, X can reduce the risk". Well, you don't say.

[BoorishBears]

This is not what microservices solve.

There'll always be critical microservices that keep your app running. It doesn't matter if all your other services are running if the one serving up core functionality goes down.

If your engineering rigor is so poor that you can't get reliable failovers with a monolith, god help you keeping microservices running.

[ahoka]

Hence “assuming proper vertical separation”. The same applies to monoliths, so not really an argument.