[anonacct38]

I've seen both extremes. For instance I'm told github largely has a rails monolith and that they have to run headless instances of rails to do database leader election (although this statement implies they are trying to break things out).

I've also talked to junior engineers who want to make every function call a pubsub message.

I've heard principals from Amazon promote a model where one service is responsible for one entity.

What I've decided is that the services in your company should follow conway's law. Most of the problems with a monolith come when multiple teams with differing release cycles and requirements are making changes in a shared codebase and they are having trouble keeping their tree green. You should generally have one to a few services per team. Scoping a service to a team ensures that people can have true ownership.

For SREs microservices are harder, but they give SREs the control plane they need to do a good job. If communication happens between services rather than function calls, it's easier to instrument all services in a common way and build dashboards. It's simpler to spin up different instances connected to different datasources.

[mtzet]

I agree wholeheartily that Conway's law is a very useful guiding principle for making "architectural" decisions.

I also think this applies much more broadly than just microservices vs monoliths. I recently moved ~40 repositories into just a few. What I've found is that anything that releases together (by teams and timeframe), should stay together. This helps ease modification of related components in an agile way, simplify tagging components, simplifies CI workflow (no multi-project pipelines).

Anything that breaks with this principle should have a concrete reason for it. If you need to combine the results of several teams into one large release, it may be easier to develop tooling for handling it all in one repository rather than developing tooling for handling many repositories. That's really the monorepo tradeoff.

Similarily, there are concrete reasons for breaking a service into smaller parts. Perhaps you want to horizontally scale a part of the service. Perhaps you need a part of the service to have a different lifecycle. But you're paying with increased deployment complexity, so you'd better get something worthwhile in return.

[NineStarPoint]

Hard agree. As an SRE, half the time my current company splits something off into its own service its for performance reasons driven by us. It’s just as often us working with the devs because we need X service off the primary database or Y service the ability to scale on its own as it is them having created a separate service of their own accord. Plus as an SRE, it’s a lot easier to wrap my head around what each service does on its own and what responsibilities are broken when its down than it is to understand the full workings of a monolith, and building monitoring around the smaller chunks is easier.

Obviously it’s possible to overdo it. Generally it seems that splitting out services as appropriate is more intelligent than just sitting down with the thought “we’re going to build a microservice architecture.” Goes back to the idea that gets banded around a lot that you should start with something as simple as possible and if you get in a situation where you are at the scale to need to rewrite then that’s a good sign for your business.

[chucknthem]

This is the first time I've heard of Conway's law used in a positive or at least non-negative way.

[mirekrusin]

I don't think I ever read mention of conway's law as having positive or negative connotation.

[Aeolun]

The law itself is fine, it’s just that the organisation of most companies is abysmal, so your software is too.

[nafey]

In case of rewriting the codebase it actually makes sense. Your organisation already has a codebase and complementary org structure. Any microservices rewrite should be tailored to the existing boundaries of teams for maximum effectiveness.