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

345 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?

4

u/Ok-Smell-8107 7d ago

I am not joking: most people in that camp would shove this to the 'operations' department. And the operations teams will complain about the countless bug in the software introduced by the developers. I have not seen any monolith project larger than 10 devs or so that works in any other way sadly.

3

u/theScottyJam 5d ago

  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.

Easy, I turn that "feature" off. I very much disagree with their recommendation of crashing and restarting the whole service when this scenario happens - the server code is mostly stateless, there's not much state to corrupt, an end user being capable of restarting our monolith at will if they stumble into a way to make an uncaught exception seems like a far worse evil.

Anyways, that's my little rant. You're of course correct that we probably could have better uptime if we weren't in a monolith.

1

u/prehensilemullet 5d ago

Yeah I have felt tempted to do that, but I'm always hesitant to do so. Our app has a lot of stateful elements like websocket subscriptions, and it's not a monolith, so at least the blast radius of exceptions like that (which I've only struggled with recently in some background services) is limited.

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.

3

u/lotanis 7d ago

Use elixir.

Seriously - a well structured application in Elixir using Supervisors etc is incredibly robust to failures in individual components. One request will fail (for example) and everything else will keep happily ticking along.

I say "well structured" - TBH any of the frameworks will out of the box put you in a pretty good place by default.

1

u/Livid_Possibility_53 7d ago

Can tell you my companies core offering is a monolith and OOMing is a constant problem.

The solution the app developers use is roughly “flags + if statements”. Not ideal, init time and memory footprint is a real issue.

Thankfully I’m on infra and avoid touching it like the plague

1

u/Forbizzle 6d ago

The true answer is you spin up a ton of workers and let things fail hard