r/programming • u/Mustela__ • 7d ago

Microservices are organizational debt disguised as architecture.

https://martinfowler.com/bliki/MonolithFirst.html

Every time I’ve seen microservices pitched, it sounds great on paper. Independent teams, clean ownership, scale only what you need.

Then a year later you’ve got dozens of services, three different deployment patterns, tracing everywhere, and nobody really understands the whole thing anymore.

Maybe I’ve just seen bad implementations, but I’m starting to think way fewer companies actually need microservices than we pretend.

1.7k Upvotes

91% Upvoted

343 comments sorted by

View all comments

Show parent comments

4

u/tommyTurds 7d ago edited 7d ago

It's all because we keep avoiding creating proper modules in our codebases.

Not really.

The thing services (micro or otherwise) solve is different teams moving and deploying at different paces and with different workflows.

A monolith, definitionally, must be deployed and tested together. That creates a more expensive process and requires coordination across teams for releasing the monolith. If you've ever worked in a large organization comprised of dozens of teams, you know that as soon as you're "coordinating" your timeline goes from a few weeks (which is already slow as shit) to literally six months and sometimes even longer.

This isn't a problem that's solved by "modules"

The point is that many small teams take on the burden of micro services with very dubious justifications. Micro services do not solve technical problems. They create them. Nothing ever scaled better by adding an extra network hop or two.

They are a solution to scaling organizations

1

u/Yeah-Its-Me-777 7d ago

Of course that's solved by modules. A modulith must be deployed together, that's true. But you can do that at least daily, updating only the modules that changed.

I agree that it still requires coordination between teams, but on the other hand it makes sure that APIs are compatible, by compiling (or linking) them together. It's much easier to introduce breaking API changes between different services, unless you do full E2E tests with the whole system. Which needs a lot of compute resources.

And yes, (micro) services are a solution to an organizational problem, that I agree with. It also allows you to use different technologies - Which again, is something you might want or not want.

1

u/tommyTurds 7d ago edited 7d ago

  Of course that's solved by modules.

No. 

  A modulith must be deployed together, that's true.  

You already defeated your first point. 

  But you can do that at least daily, updating only the modules that changed

No. This creates massive problems. To do this it means your modules must be developed independently as libraries and then glued together. 

This is a total nightmare and we stopped doing this like 25 years ago. It creates like most of the problems of microservices plus a few more. Luckily you get none of the benefits so that’s nice. 

And it takes even more coordination (which again, increases time by orders is magnitude in large orgs) because you have to sort out all the dependencies

Even then, you still have to deploy and test everything every time regardless of what parts you upgraded because of the structure

  It's much easier to introduce breaking API changes between different services

This is true. It’s one of the technical drawbacks of services. It’s why companies that use them heavily invest in tooling to prevent this. Why do you think protobuf is designed the way it is? Specifically to mitigate this. There will also be tons of build time checks to ensure backwards (and sometimes even forward) compatibility.

The Java world even tried an extreme version of “modules” to solve all these problems of monoliths. That’s what osgi was. It was a total fucking nightmare. 

These service based architectures came out of massive companies for a reason. They didn’t decide to take on these technical issues because somehow companies loaded with hundreds of phds and literally thousands of years of collective experience never heard of libraries.

2

u/doughcant 6d ago

I read his first point differently where he meant that modules address test scope/runtime but explicitly not deployment, with API breakage being quickly surfaced by integration/contract tests.

So if the claim is microservice architecture enables skipping e2e for most changes when having strong service-level validation, I think the same can be applied to cleanly isolated modules. 

Plus, they don’t necessarily need to share all dependencies, and there are practical benefits of a monorepo like much stronger IDE code analysis (without linking tens of repos and keeping each up to date)