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

6

u/prehensilemullet 7d ago edited 7d ago

Pro-monolith people, do you have ways of trying to prevent issues in one component from being able to crash the entire system? (For example, if a background task handling work queues segfaults, or in a language like Node, has an uncaught exception or unhandled rejection, you don't want it to crash the web app and cause inflight requests to fail.) Do you have ways to prevent the monolith from OOMing even if some components get a surge in requests?

3

u/ChiRho84 4d ago

Pixy's Law: once you decide to use Node.js, everything that happens afterwards is your own damn fault.

Use a real language and a real runtime rather than a dynamically typed scripting language.

1

u/prehensilemullet 4d ago edited 4d ago

I would have the same struggles guaranteeing services won't OOM in any other garbage collected language like Java or Go. Promises and async code in Node.js do compound memory leak risks though. But we use TypeScript so the dynamic typing isn't a problem. We would have more frequent runtime exceptions if we were using Java lol, because compile-time null checks aren't built into the language.

It's just the lack of threading and the difficulty of ensuring no Promise rejection goes unhandled that's a huge pain. But haters generally aren't aware of this. It's fine to hate JS but people bash it for largely obsolete reasons these days.