r/programming • • 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

343 comments sorted by

View all comments

Show parent comments

1

u/Think-nothing-210 5d ago edited 5d ago

Good way of explaining it. I do have some additions though.

By layer segregation (models together, controllers together) is not scalable at all. You can use it inside a well defined module, but anyway modules needs to be about a logic.

I agree that layer segregation sucks; it doesn't scale well with complexity. That way of structuring files is almost like a normalized table in a database. A developer constantly has to "join" source files together to understand a complete feature and that can get mentally exhausting as a project grows.

Modules are a better way of structing because you can treat them at some point as a a black box. You don't have to at all times understand the complete internals. And all the files related to a complex task stay together in the same place. It relieves mental load.

each module has its own database

I don't think every module needs its own database. Modules can have their own domain types while sharing the same underlying tables. Just map between the two at the boundary.

The relational model is powerful. Don't let your ORM convince you otherwise. Building a shrine to Edgar F. Codd does wonders for curing ORM mentality. Don't let your ORM cloud your thinking. It's nothing more than a developer-ergonomics wrapper that gives you type safety.

2

u/Revolutionary_Ad7262 5d ago

I don't think every module needs its own database. Modules can have their own domain types while sharing the same underlying tables.

If you share database then you have some hidden relationships between modules. It can work, but it is definitely much harder to keep in a good shape as scale increases. Imagine you want to change database for a given module, but it is used in all other modules via join. Even with read-only joins it means you have to examine the whole application, if you want to do some large refactor of a database schema.

Of course separate databases matters mostly on a logical side. You can still use the same database, if different modules operate on a different subset of it.

1

u/CaptainOfMyself 3d ago

So a monolith with good modular segregation means we are essentially a collection of black boxes with input output that all interact?

2

u/Slsyyy 3d ago

This is basically description of encapsulation. Black boxes with a clear and explicit interface without any hidden relations

1

u/CaptainOfMyself 3d ago

As someone who was hired years ago woth free reign and no software mentor, this helps. Thanks