[mirekrusin]

Decreasing merge conflicts sounds more like muting and/or deferring problems.

Microservice fanaticism seems to be coupled with this psychosclerotic view that world can exist in state of microservices or as monolith.

From what I've seen in last 20+ years, if I had to pick one sentence to describe fit-all enterprise setup (and it's as stupid as saying "X is the best" without context) - it'd be monorepo with a dozen or two services, shared libraries, typed so refactoring and changes are reliable and fast, single versioned, deployed at once, using single database in most cases - one setup like this per-up-to-12 devs team. Multiple teams like this with coordinated backward compatibility on interfaces where they interact.

[blakehaswell]

To clarify, are you saying up to two-dozen services for a development team with ~12 developers on it?

[mirekrusin]

Above all I'm saying that sentences like "microservices are better", "monoliths are better", "42 services are the best" are all stupid without context.

What your business does, how many people you have 3 or 10k, what kind of roles and seniority you have, how long you're in the project - 3 months in or 10 years in, how crystalized architecture is, at what scale you operate, how does performance landscape looks like, what kind of pre-deployment quality assurance policies are dictated by the business, are offline upgrades allowed or we're operating in 24h, which direction system is evolving, where are gaps (scalability, quality...) etc are all necessary to determine correct answer.

Building website for local tennis club will require different approaches than developing high frequency trading exchange and both will be different from approaches for system to show 1bn people one advert or the other.

Seeing world as hotdog and not-hotdog (microservices vs monoliths) makes infantile conversations. There is nothing inherently wrong with microservices, monoliths or any of approaches to manage complexity ie:

- refactoring code to a shared functions

- encapsulating into classes or a typed object

- encapsulating into a modules

- simply arranging code into better directory structures, flattening, naming things better, changing cross-sections ie. by behavior instead of physical-ish classes and objects

- extracting code to packages/libraries inside monorepo or its own repository ie. open sourcing non-business specific, generic projects or rely on 3rd party package/library

- extracting into dedicated threads, processes, actors/supervisors etc.

- extracting to service in monorepo or dedicated repository or creating internal team to black box it and communicate via api specs or use 3rd party service

...bonus points for:

- removing code, deleting services, removing nonsensical layers of complexity, simplifying, unifying etc.

etc

[hackerfromthefu]

I don't know what the op intended, but services can be deployed in process inside one monolith.