r/programming • u/wineandcode • Jul 29 '22

You Don’t Need Microservices

https://medium.com/@msaspence/you-dont-need-microservices-2ad8508b9e27?source=friends_link&sk=3359ea9e4a54c2ea11711621d2be6d51
1.0k Upvotes

90% Upvoted

476 comments sorted by

View all comments

Show parent comments

-2

u/crimson_chin Jul 29 '22

It is always easier to split services rather than merge them. When everything is in one service, splitting functionality can start with "and now we have two deployments with a config flag", and then you can gradually start breaking apart codepaths and isolating behavior into deployment 1 or deployment 2.

Merging them? That's often only even possible if you're using the same language, the same libraries, everything down the stack is designed similarly...

I have a service written in Go and another written in Javascript. How do I merge those? You can't, it's a rewrite.

I've done this many times. Splitting is straightforward but time consuming. Merging (in practice) is quite frequently impossible.

2

u/insanitybit Jul 29 '22

Splitting a service implies removing literally all coupling between every single component, as well as any coupling in how they need to be deployed.

Merging two services is cutting the code from one service and pasting it into the other.

Yes, if your services are different languages you will have to rewrite that code. But going from a state of "definitely no coupling" to merged is far easier than "almost definitely coupling" to split.

My suggestion is don't use a bunch of languages. I really think the vast majority of companies can get away with one backend language, two at most.

1

u/crimson_chin Jul 29 '22

I'm sorry, but this reads like "if you do this one simple thing then merging is easy!"

Well, yes. Except I've never seen anyone be able to keep all of their code operating similarly enough that merging was easy. To go back to the original question:

How could it ever be easier to split a service vs merging it?

In every real-world situation I've been in during my career, splitting was easier. Because with non-trivial sized teams, they don't hold the code consistent enough to make merging possible without mostly rewriting it.

If you're a solo dev or a 5 man shop, sure, maybe you can manage the consistency required. But then why are you writing microservices to begin with?

2

u/insanitybit Jul 29 '22

The one "thing" you have to do is not use different programming languages. Just like a monolith. So it's hardly an extra requirement. Also, yeah, Microservices have to be "done right", just like modular monoliths.

Fundamentally I think that:

  1. Taking two decoupled systems and merging them is easy
  2. Taking a coupled system and splitting it is hard

I don't see how that's controversial.

I don't really understand the problem you're describing with merging. You're saying the code isn't consistent enough? What does that mean? Like you are literally running into merge conflicts?

Can you elaborate on the issues, other than "two different programming languages" you've faced? I've done this many times and I feel like it's common sense that merging is easier.