Comment by Tabular-Iceberg | Hacker News Reader

Comment by Tabular-Iceberg | Hacker News Reader

Parent Full thread

Tabular-Iceberg

Is there ever a good reason to change from monolith to microservices unless you have already solved the factoring problem in the monolith? The factoring problem doesn't get easier because you add network calls into the mix, but being well factored first makes adding the network calls a lot easier. If you're lucky your framework or platform already has that part figured out.

Maybe one exception is if you absolutely must change the programming language at the same time, but even then I would suggest doing the rewrite as a monolith first for the same reason, so you again don't have to deal with network calls at the same time as solving an already insanely hard problem.

There's the argument that microservices lets you gradually replace the old monolith piece by piece, but there's nothing special about microservices for that, you can do that with two monoliths and a reverse proxy.

And at the end of either you might find that you didn't need microservices in the first place, you just needed to factor the application better.

The benefit of microservices is that you can divide areas of responsibility among teams and (theoretically uncouple the change processes for each)

Dividing areas amongst teams is only a theoretical benefit if you haven't solved the factoring problem. Otherwise teams are still going to be cross-dependent on other teams constantly.

But if you've solved the factoring problem, your team and another team can happily work next to each other in the same codebase with less back-and-forth anyway. And the question reduces largely to if you deploy it all at once or not. Sometimes all at once is much easier anyway.

I've seen microservices used by management as a way to force engineering into factoring their shit correctly far more often than I've seen it done because things were already factored well (because cross-team coordination in different services is much harder than just jumping around in the monolith's single repo in a single PR). It's an easy lever for management to pull, too, because most devs don't see it as something they're being forced to do, they think they're getting their wish at rewriting and modernizing things. ;)

> factoring their shit correctly

When is shit ever factored "correctly"? Next week, your product owner will come over with a new idea for a feature spanning multiple modules and suddenly you will realize you should have factored your shit differently and maybe not split things up into multiple microservices prematurely.

So what I'm trying to say is: Grug is right. Factoring a piece of software correctly is one of the hardest issues. The assumption that you can do it correctly is the reason why so many microservice architectures are such a PITA to work with.

It’s true that factoring is something you can spend an unbounded amount of effort on, but it’s too unwieldy to always say factored “so well that there is no point working more on it because of diminishing returns”. So when you see “correctly”, read that as “so well that there is no point working more on it because of diminishing returns”.

Arguably that is what correct factoring is anyway, because it’s simply not correct in any way to fiddle with a piece of software without generating any real value for either the business objectives or the developers that have to work with it down the road.

I don't understand how this isn't mitigated by a CODEOWNERS file[0]. Give the directories to the teams that should own them, and now they have absolute control over the PR review process accordingly (and responsibility of incoming code for the directories that they own too).

[0] https://docs.github.com/en/repositories/managing-your-reposi...

That just solves one problem, and not the most significant. Other issues, not usually inherent to the monolith pattern but very common:

* Release management coupling

* CI coupling

* Deployment coupling

* Binary bloat

* Monitoring/alerting/logging noise

* Lack of security policy granularity

* Language and library choice coupling

Of course, people mess these things up with the service model as well, but the failure modes there don't propagate as much (unless they're organizationally mandated...)

… which often turns everything into siloes not talking to each other, using different languages/tools/processes/release plans. No thanks.

The world is not so black and white, and silos have legitimate business purposes. The reality is that any one contributor or team can only handle so much. When duties must be split between teams for effective ownership of responsibilities, separation of concerns becomes paramount to the continued progress in any one domain.

If all you have is one team, microservices make no sense.

I've tried searching this and couldn't find anything related to microservices - what is the factoring problem or system that grugbrain is referring to?

Is it something to do with calculating the cost of splitting off a monolith into a microservice vs. some other method?

They are referring to software structure and decomposition.

This is a hard problem that spans architectures; you can have a poorly factored microservice architecture, just as you can have a poorly factored monolith.

These two posts from Shopify are good:

https://shopify.engineering/deconstructing-monolith-designin...

https://shopify.engineering/shopify-monolith

I think they are talking about modularisation, i.e. breaking the code into somewhat independent units.

Reply on news.ycombinator.com