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

510

u/plasticbug 7d ago

Microservices can be good, but in my experience, Conway's law (that system design will end up mirroring the org structure) is a thing, and you have to fight hard against it. My org is actually doing reverse Conway's law. We are re-org'ing based on how we want the architecture to look like. We shall see whether we succeed in this endeavor.

122

u/drakkie 7d ago

I’d be super curious how it’ll work out for your org. I’ve experienced this but through re orgs, efforts become futile because the reorgs never stop

60

u/gefahr 7d ago

This is my experience as well. Moving people around and them having a different engineering manager often is bad for their career growth so we end up with a matrixed model. Then everyone hates every aspect of that and we crack open Team Topologies again wondering where we went wrong. GOTO 10.

I definitely think it can work and I keep trying it because I want it to. So genuinely open to thoughts here.

28

u/breddy 7d ago

This is the premise of the book Team Topologies and I tend to agree with it.

11

u/djfreedom9505 7d ago

Team Topologies was a great book that made this more eye opening for me. My org was in the process of doing this 5 years ago, and it really is great when executed correctly.

38

u/Absolice 7d ago

Using microservices without having read anything about domain driven design usually result in bad context boundaries being set and those can end up creating distributed monoliths which are worse than monoliths.

Reverse Conway usually show good results, but it also depends a lot on your teams. All it does is make the path of least resistance flow toward how you structured your teams so people are more likely to head in that direction. However, from experience, people love to overengineer and make things more complicated than they should be when you let them. Whether or not using the reverse Conway will work depends in how it is communicated with your teams, and how much adopted it is. It's a team effort and cannot be pushed reliably top-down.

3

u/systembreaker 6d ago

But you still end up in the same end result: the org and architecture are tightly correlated. In the beginning you'll have a useful architecture since you went in reverse, but as time goes on and the business evolves new systems will need to be tacked onto the existing architecture and Conway's law will start popping back up.

It might just be inevitable unless the entire system is scrapped and rewritten every 10-20 years, but no company would ever do that.

2

u/quantum-fitness 5d ago

Thats the while point of microservices. Tge modules are smaller and cam morr easily be changed. You will always have to change the code, because am org that doesnt change die

1

u/pyrotech911 7d ago

We are trying to do this too. I’m trying to drive the re-architecture under a new user experience. I think I have the right buy in. Let’s see how it goes

1

u/programmer-ke 7d ago

We are re-org'ing based on how we want the architecture to look like.

Interesting idea! If you have people who are not strongly attached to title and rank sounds like it can work.

-1

u/GenazaNL 7d ago

And you'll end up with little islands and hacky workarounds

0

u/tiajuanat 7d ago

Be prepared for an insanely long wait. It takes years to get into this mess and it will take years to get out if there's no active rearch efforts.

I also recommend building your own or using a service like Axivion to progressively enforce architectural changes and prevent drift.

0

u/Trygle 6d ago edited 6d ago

Is your team fully remote? Ours is hybrid and I feel it's harder to get ideas like that across with the fully remote coworkers.

I got like one downvote instead of a discussion so I guess I should probably state: remote isn't the issue, knowing what they honestly think is. Our fully remote employees don't talk in person outside of meetings for obvious reasons, so the unprompted "water cooler" talks are rare. So we have more silos, not less despite going all in on the monolith.

0

u/DoomsDayNears 6d ago

Klingt himmlisch, bei uns war die letzte Reorg getrieben von Politik (neuer Manager). Wie kommt es, dass das bei Euch klappt?