Hacker News Reader

Comment by MatekCopatek | Hacker News Reader

I always felt like the biggest benefit of microservices (for the average company that just jumped on the band wagon) was simply the fact it forced them to break things up. Yes, they could achieve the same result with none of the overhead on a monolith, but it would take... discipline. It's much easier to just enforce a hard external constraint.

Realizing this and circling back is still a useful life lesson.

View on HN

If your code is bad in a monolith, it’ll be bad with Microservices. If you can’t build a good monolith, you can’t build a good Microservices architecture — because it introduces even more complexity and requires even more consideration.

Discipline is fundamental to good software engineering: you can’t force it with Microservices.

I think this, approaching DDD, is the most common reason engineers push for it these days.

It isn't worth the added friction though.

And if you happen to leak concerns in your services (in a monolith), it's really easy to adjust, as opposed to having to coordinate the deployment of 5+ services.

And even then, a distributed monolith is still a risk.

Micro-services add cement to your project. Be prepared to keep boundaries you write for a long time.

Another reason is that it gives you more agency to adjust your code. Want to refactor? Cool, I don't have to talk to 15 teams about how this might impact them. Same thing with changing a schema, changing scaling strategies, etc, etc. I can do things in 2 weeks that would take 2 weeks of just talking to people on a monolith. That might be more organizational than a technical limit, but I've never seen an agile monolith before.

Reply on news.ycombinator.com