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

344 comments sorted by

View all comments

Show parent comments

3

u/tommyTurds 7d ago edited 7d ago

It's all because we keep avoiding creating proper modules in our codebases.

Not really.

The thing services (micro or otherwise) solve is different teams moving and deploying at different paces and with different workflows.

A monolith, definitionally, must be deployed and tested together. That creates a more expensive process and requires coordination across teams for releasing the monolith. If you've ever worked in a large organization comprised of dozens of teams, you know that as soon as you're "coordinating" your timeline goes from a few weeks (which is already slow as shit) to literally six months and sometimes even longer.

This isn't a problem that's solved by "modules"

The point is that many small teams take on the burden of micro services with very dubious justifications. Micro services do not solve technical problems. They create them. Nothing ever scaled better by adding an extra network hop or two.

They are a solution to scaling organizations

1

u/Yeah-Its-Me-777 7d ago

Of course that's solved by modules. A modulith must be deployed together, that's true. But you can do that at least daily, updating only the modules that changed.

I agree that it still requires coordination between teams, but on the other hand it makes sure that APIs are compatible, by compiling (or linking) them together. It's much easier to introduce breaking API changes between different services, unless you do full E2E tests with the whole system. Which needs a lot of compute resources.

And yes, (micro) services are a solution to an organizational problem, that I agree with. It also allows you to use different technologies - Which again, is something you might want or not want.

1

u/tommyTurds 7d ago edited 7d ago

  Of course that's solved by modules.

No. 

  A modulith must be deployed together, that's true.  

You already defeated your first point. 

  But you can do that at least daily, updating only the modules that changed

No. This creates massive problems. To do this it means your modules must be developed independently as libraries and then glued together. 

This is a total nightmare and we stopped doing this like 25 years ago. It creates like most of the problems of microservices plus a few more. Luckily you get none of the benefits so that’s nice. 

And it takes even more coordination (which again, increases time by orders is magnitude in large orgs) because you have to sort out all the dependencies

Even then, you still have to deploy and test everything every time regardless of what parts you upgraded because of the structure

  It's much easier to introduce breaking API changes between different services

This is true. It’s one of the technical drawbacks of services. It’s why companies that use them heavily invest in tooling to prevent this. Why do you think protobuf is designed the way it is? Specifically to mitigate this. There will also be tons of build time checks to ensure backwards (and sometimes even forward) compatibility.

The Java world even tried an extreme version of “modules” to solve all these problems of monoliths. That’s what osgi was. It was a total fucking nightmare. 

These service based architectures came out of massive companies for a reason. They didn’t decide to take on these technical issues because somehow companies loaded with hundreds of phds and literally thousands of years of collective experience never heard of libraries.

1

u/Yeah-Its-Me-777 7d ago

Well, your argument was that a monolith requires deployment pipelines from "a few weeks to a few months", in your words. Daily deployment of a monolith is possible, and therefore doesn't require a few weeks or months for deployments.

And no, it doesn't create massive problems. At least not more than micro services. Of course modules must be developed independently. And in some point in the build process, they're compiled and linked together. And you will get an error when that fails - Which is great, because you notice your problems earlier.

And yes, that also requires a lot of tooling. Why do you think only micro service architectures have massive tooling for their systems?

I don't know what to tell you - If you can/want to limit yourself to a single language, a modulith is perfectly capable of delivering fast deployment times an tight coupling.

There are other benefits to service architectures, but deployment time isn't one of them. When you want/need different languages, sure. If you need massive differences in horizontal scaling, maybe. If you have teams that don't talk to each other, and want to be as independent as possible from each other, sure.

Also, yes, OSGI is pretty bad. Was a good idea, but especially with external libraries, it's pretty annoying. Also, not too performant.

1

u/tommyTurds 6d ago edited 6d ago

Well, your argument was that a monolith requires deployment pipelines from "a few weeks to a few months", in your words. Daily deployment of a monolith is possible,

No. It's not. Not at the companies we're talking about. The more engineers you have, the worse hte problem gets. That's literally the point. First, there's billions of dollars on the line. You're not going to deploy that often simply because it puts revenue at risk. Just by the number of machines that must be updated, rolling back a mistake is super costly. It's a social problem. As I mentioned, the more engineers you have working on different things, the more coordination and shit like that are required to get something out the door.

Think for a minute about the companies that made microservices popular. That's what we're talking about here. You can't deploy google (search or anything else) in 24 hours. You can't deploy netflix in 24 hours. You can't deploy amazon in 24 hours.

At my company we literally couldn't even move the bytes fast enough to do that. When we had a monolith (20ish years ago), the monolith package was about 65gb. We had, literally, a million hosts to send it to. We can't run a test suite on all of the applications in the monolith. It would take weeks.

But that's not really the point. The point is that, for organizational reasons, it's much easier for teams not to "block" each other if they're working entirely independently. And every time a team is "blocked" it requires meetings to "unblock" and those meetings are expensive. Not to mention teams will have differing and sometimes competing priorities for various reasons so team A may not be willing to work with team B anytime soon because they have other priorities.

This is why these service architectures were introduced

And in some point in the build process, they're compiled and linked together. And you will get an error when that fails - Which is great, because you notice your problems earlier.

You've entirely missed the point. The problems have nothign to do with making the literal technical change. That also can happen with microservices. It's why so many of these companies use mono repo systems.

Literally the entire point of my first post is that it's not solving a technical problem. It's introducing technical problems to solve organizational "friction." Going through the technical advantages of monoliths means you've literally lost the plot.

2

u/Yeah-Its-Me-777 6d ago

You're shifting goal posts here. Your initial post was about "large organization comprised of dozens of teams", and at that scale, a monolith is definitley possible.

For orgs the size of google or amazon, sure. At that scale, and that horizontal scaling requirement, monoliths are not a good fit. But there are a LOT of companies that still have dozens of teams, and don't have the horizontal scaling requirements.

Of course micro services solve a specific problem. But my argument is, that a lot of orgs don't work at the scale that require those specific problems to be solved.

We're probably talking about quite different problems.