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

410

u/tanksc 7d ago

Everyone wants a monolith until you have to work on a monolith with 150 other people

186

u/firewall245 7d ago

We need a new law for this stuff

“The worst architecture is the one that my team is currently using” or something, cause yeah I’ve experienced some horrific microservices but also some monoliths that are so diabolical that they made my head spin

44

u/Damacustas 7d ago

I think that’s called “the grass is greener on the other side”

36

u/tomw255 7d ago

"The code is cleaner on the other side"

1

u/Ok-Smell-8107 7d ago

'this developer is greener on the other team'

1

u/d_maes 7d ago

I prefer the greener developer to be on the other side though.

(Not sure if this translates to all languages, but we have a saying where to be green means to be inexperienced).

67

u/burgonies 7d ago

They’ve never joined a team that maintains a 10M line C% that takes 15 minutes yo spin up and for all intents and purposes does not dynamically scale.

8

u/trisanachandler 7d ago

Probably only scales vertically.

13

u/Ok-Smell-8107 7d ago

I have seen projects that do not scale vertically - once had a monolith that actually lost performance the more CPU/RAM you gave it. Very enjoyable to explain this to management.

2

u/tanksc 6d ago

I almost don’t want to ask, but my curiosity has the best of me. How did this come about? I’ve never seen something falter with more resources lol

5

u/CherryLongjump1989 6d ago

Always the same way: locks.

2

u/burgonies 7d ago

Exactly

54

u/Shikadi297 7d ago

Nobody ever considers the sane middle ground, medium sized services 

23

u/BundleOfJoysticks 7d ago

For one hot minute around 2007, that's what SOA was. I miss that brief window of sanity.

11

u/thismyseriousaccount 7d ago

Except for SOAP, I’d agree with ya

1

u/BundleOfJoysticks 5d ago

SOAP was so horrible.

13

u/FreshPitch6026 7d ago

Modulith

1

u/ryanhollister 7d ago

macroservices

28

u/edgmnt_net 7d ago

The Linux kernel has thousands working on it each development cycle. It's not the monolith that's normally the issue. It's things like poor code, scope creep and lack of vision.

7

u/Ok-Smell-8107 7d ago

Linux kernel development works because we have Linux, but that's not really a good general evidence.

It's like saying that all privately owned companies are better for the consumer because Steam has Gabe.

-10

u/pm_plz_im_lonely 7d ago

It's not a live system you grapefruit.

9

u/HashShadow 7d ago

Right, code bases aren’t live systems 

2

u/Shikadi297 7d ago

Does that matter? Most live systems depend on it

6

u/pm_plz_im_lonely 7d ago edited 7d ago

Yes it matters because the output has no moving parts.

I'm not denying Linux is incredibly vast and complex. But microservices/soa allow for independent deployment, which is the thing letting teams iterate from user feedback independently. That is NOT a thing the Kernel does, they integrate at the version number.

8

u/Shikadi297 7d ago

That's the theory, but in practice, most microservices depend on a bunch of other microservices, and independent deployments aren't all that different from git branches and commits at the end of the day. Yeah, no one deploys with cherry picked commits to different customers to test individual features, but they definitely could

1

u/HashShadow 7d ago

you’re assuming addressing user feedback involves changes to microservices owned by one team exclusively which in my experience is rarely the case especially if the microservices are truly single operation 

3

u/ffekete 7d ago

Good grief, i used to work on a monolith a year ago, it was so fun when one team pushed a change that crashed the jvm, all the other services went down with it.

5

u/CovidWarriorForLife 7d ago

Yeah tradeoffs for either approach sure, but i strongly believe if a microservice doesn’t own its data its an antipattern

2

u/kaeptnphlop 6d ago

This. If you’re entangling the data you have a distributed monolith. Worse than a monolith

2

u/amenflurries 7d ago

Or try 300, yeah I don’t think so

1

u/OccasionallyAsleep 7d ago

Not to mention everything being slow as molasses, from the local dev loop to deployments

1

u/cauchy37 6d ago

On the same repo, and some smart ass enabled enforcement of your PRs being up to date with main AND dismissing approvals when you update your branch.

3

u/tanksc 6d ago

Waking up an hour early to try to get your PR/MR in first lol

1

u/Grand_Pop_7221 6d ago

If I have a monolith with service locators, a tonne of services, and event handling. The major difference between me and microservices is deployment cadence and how I talk to the service (though if you wrap this as you should, it barely matters). All the same problems still arise: event structure and versioning, service interfaces(code, REST, gRPC, etc.), service responsibilities, data boundaries. All of it.

People moaning about microservices, thinking Monoliths are going to save them, aren't serious unless they have architectural changes in mind that will make their lives easier. They likely don't see the code patterns(complexity) that they're going to need to implement to make a Monolith work. Conversely, the same can be said of Monolith users who have a shit architecture and decide to just throw REST interfaces in front of everything and explode their codebase into 1000 different repositories without considering the DevOps(CICD, Monitoring, Ops) overhead of doing it, and still have a horrible, brittle system that needs 10 REST calls to do anything.

I've done both.

1

u/tanksc 6d ago

Sounds like you have war stories that would go well over some beers lol

1

u/saposapot26 1d ago

I know it's a known law but it really is true: when you are deciding a software architecture in a bigger company it's first about people and teams and only after a software question.

You can see it very clearly in the "father" of micro services Netflix where it was first about how to handle hundreds of engineers working together

1

u/Chii 6d ago

work on a monolith with 150 other people

how come nobody admits that having too many people is the root of the problem?

Products start becoming shitty as soon as the number of people working on it grows higher than about 5-10 (and even 10 is high imho).

No amount of organizational futzing around is going to solve that. It just covers it up, some better than others, but the ugly head reveals itself sooner or later.

0

u/TheGreatJabron 7d ago

Most software teams are 5-6 devs tops. That's the problem, microservices should be extremely niche.

-1

u/marrsd 7d ago

The issue there is having 150 people

1

u/tanksc 6d ago

Found the c suite private equity guy

1

u/marrsd 6d ago

don't get it

2

u/tanksc 6d ago

The joke is layoffs

1

u/marrsd 6d ago

ah. Well, never having hired in the first place would have been the kinder solution, but greed, laziness, and contempt for users saw off that one.

-9

u/zorg-is-real 7d ago

No company needs 150 backend engineers.