Hacker News Reader

Comment by sazz | Hacker News Reader

Speaking from a Release Management point of view going from a monolith to microservices is often done for the wrong reasons.

The only valid reason for actual doing the change seems to be for scaling reasons due to performance bottlenecks. Everything else is just shifting complexity from software development to system maintenance.

Of course, developers will be happy that they have that huge "alignment with other teams" burden off their shoulders. But the clarity when and how a feature is implemented, properly tested across microservices and then activated and hypercared on production will be much harder to reach if the communication between the development teams is not mature enough (which is often the actual reason from breaking up the monolith).

View on HN

There are many valid reasons (and many wrong reasons). I would say: If you have multiple stakeholders, evoling business needs and many ( > 10) developers, there might be a good reason to have independent deployable, testable and releaseable units. Having few developers with a well defined context working on multiple microservices is a pain, though.

Regarding "Everything else is just shifting complexity from software development to system maintenance.": This sounds reasonable if your software is actively developed. Development is expensive. It may very well be, that the costs of maintaining a distributed system is lower then the cost of developing a very large monolith with a large team. In the end, it depends.

"There might be a good reason to have independent deployable, testable and releaseable units"

Of course this is the bottom line. But everything you define in the sentence can be achieved with a proper pipeline and repository architecture based on a monolith as well. For example teams could use a branch setup where they own their own team branches capable of merging to master and deploying. Each team could then define their own testing strategy and Definition of Done on their "team master".

Having the ability to release independently is actually a social problem, not a technical one. But the symptom of that social misalignment often shows up as a technical problem (dropping release KPIs, etc.)

So changing from a monolith to microservice will most likely only fight the symptom, not the root cause.

First, you offer technical solutions (pipelines, branching...).. The cost of having multiple teams branching and merging the same code base can be significant. It's often not as easy as you make it sound.

In the end it is exactly the same technical complexity, it is just shifting complexity from point to another.

A proper branching strategy is not a technical solution but a social alignment of people contributing to common product. And it doesn't matter if they are contributing on different repositories or on the different branches. The technical complexity of aligning interfaces is the same in both cases.

"It's often not as easy as you make it sound."

No, it's of course not easy. But the costs in splitting teams up into different repositories and aligning their interfaces is not easy either. My point is they are both the same - just expressed differently.

This is the sole reason we're considering breaking this out into a separate component of our app. It's become too large to maintain effectively. The rest of the app will remain unchanged

Reply on news.ycombinator.com