[jamalaramala]

> The question is: Why companies moved from monolithic to microservices? What do they try to avoid?

One of the main reasons why companies move from monoliths to microservices is to promote ownership and accountability in large codebases.

In a monolith where everyone owns the code, developers can break each other's code.

With microservices, each team becomes responsible for one part, and (as long as they keep their SLAs) they can't break each other's code.

When something fails it's easier to identify who needs to fix what.

Microservices don't make much sense for small teams if they don't need or don't have the headcount to split responsibilities.

[fluoridation]

Same-process modularization should solve that problem. Splitting the architecture into separate processes means a crash in one module doesn't propagate to other modules, but the whole system still breaks down if the process is essential.

[zbobet2012]

What same-process modularization does _not_ solve is independent lifecycle management. In a monolithic system your change rate often becomes tied to your slowest, most bug prone module or team. If you've some integration test that bakes some piece of important code for 48 hours, you can only make a change _everywhere_ else every 48 hours.

Now sometimes folks (the Windows team famously did this) build systems which identify which tests to run based on changes that occur in the codebase, but that's _not_ easy.

[SideburnsOfDoom]

Yes. With the microservice as the unit of deployment, the design is about team structure as much as it is anything else. The team of 4-12 people owns and deploys a service at their own pace, without needing to be part of a larger and slower batch.

If you're interested in iterative development and continuous deployment, which of course I am, it is a natural fit. It is productive in that case.

[jamalaramala]

Not all bugs are crashes. It could be a copy text or price calculation.

[thfuran]

A system can break without crashing. Incorrectly processing financial transactions due to a bug in price calculations would be a good example of a serious breakage that may well be worse than crashing.

[fluoridation]

For bugs that don't cause crashes the effect is the same regardless of how you architect the system.

[lolinder]

Yes. And the little-understood reason why microservices became the answer is that the tools for defining clear ownership boundaries in a single service were (and to an extent still are) lacking.

Defining a clear public contract in most existing programming languages that cannot be violated by a lazy programmer is tricky. Java's package-private should be the answer but is too blunt and ends up requiring a team to make things public so they can use them. C# has a bit more control that might make clear contracts possible (I haven't tried), but not everyone wants to use it because Microsoft. And most of the popular languages at the time of the rise of microservices had basically no mechanism for defining public versus private interfaces.

Microservices allow you to do that in any language— your HTTP API is your public interface. Anything inside of that is physically impossible to access without adding an explicit build-time dependency, which would be trivial to catch in code review.

Yes, code review could theoretically solve the same problems, but in practice no organization is that disciplined. You need tooling, and those tools didn't exist yet when microservices came to be. We're seeing them develop now (Rust's visibility modifiers are very powerful, and monorepo tools are starting to develop lints that can impose module boundaries on languages that lack them natively), and it's not a coincidence that around the same time we're seeing a lot of people moving back to monoliths.

[sebazzz]

> With microservices, each team becomes responsible for one part, and (as long as they keep their SLAs) they can't break each other's code.

Well, they still can and do break someone else's code. It is just breaking someones code with more steps in between. And who is at fault isn't necessarily as clear cut.

[breckenedge]

Sounds like extra bureaucracy.

[SideburnsOfDoom]

Yes and no. Would you rather ask for deployment of a microservice owned by a team of 10 people, or a monolith that has changes from a department of 100 people. Which deployment do you think has "extra bureaucracy"? Which one do you think can be done this week?

There are co-ordination costs to microservices. But there are also independence benefits.

[jamalaramala]

It definitely is; but this bureaucracy can be useful when the company has thousands of developers.

[SideburnsOfDoom]

> With microservices, each team becomes responsible for one part, and (as long as they keep their SLAs) they can't break each other's code.

When done well, microservices work as a unit of deployment. The team that owns the service code deploys it on their own pace. Sure there is process to follow, but it involves 10 people in that microservice team not 100 people for the monolithic app. This allow for smaller batches and independence of development.

[mangodrunk]

Having micro services doesn’t protect against affecting another team’s code/service. Think of a service changing some behavior or contract on either side of your service. Are you thinking of a person changing the actual code of another team? That can be solved without micro services.

[ciupicri]

Yet some companies use monorepos, so everybody has access to everything.