That organizational/architecture benefit is strong though.

It’s depends on how you slice services. For one micro-service per a team I see benefits. On another end of a spectrum a single team managing 10-20 micro-services with more than one service per developer. IMHO it creates more problems than solves. Also it is usually a waste of HW resources because a library call it is cheaper then a network request.

I think it depends on more than that.

A single team managing 10 microservices that actually make sense to be microservices (like the PDF renderer example above [1]) is kinda good and perfectly manageable.

A team with one single microservice that would actually work better if it was part of a monolith is already in the "creates more problems than it solves" territory.

[1] https://news.ycombinator.com/item?id=35812294

I would frame it as a necessity rather than a benefit. Having siloed teams (services) is usually a problem which is better to avoid as much as you can.

Having autonomous teams is great for scaling and allowing everyone to go fast, without teams constantly blocking each other.

Having hundreds of engineers work in a single monolith in a single repo without any kind of (enforced) boundaries is a one way ticket to a big ball of mud. You need to invest heavily in tooling to make it work, and e.g. Google does so.

Having a network in between teams is a relatively easy way to enforce boundaries.

It allows everyone to go fast as long as the work is constrained within one service. It goes very slow once service / team coordination needs to happen and one team alone is not able to deliver the feature. This then often leads to services duplicating logic, amassing responsibilities in order to do as much as possible within "my" service to avoid this coordination bottleneck.

Then you're either not setting up your team responsibilities right, or you're not allowing cross-team contribution, both are fixable mistakes.

Seems like Conway's law applies:-

"Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure." -- Melvin E. Conway

https://en.wikipedia.org/wiki/Conway%27s_law

Came here to say this - and it applies in the other direction. Microservices allow you to split work between teams without having to coordinate deployment and iteration cadence quite so tightly.

If you have a single team, you shouldn't be doing microservices.

I mostly see organizations with multiple internal dev teams who all have shared responsibility over all of the microservices (e.g. no-one is responsible for any service). The worst of both worlds: all of the complexity of microservices architecture, without the benefit of specialization and splitting work between teams.

The organizational structure doesn't have to be reflected in the built artifact(s), though. Just look at Chrome. It has who knows how many teams working on it, but gets built into a single giant DLL (or executable, depending on your platform). And newer languages like Go and Rust make it easier to link everything into one big artifact like this.

I built a little microservice on the side of my monolith for PDF creation. It used headless chrome and ghostscript to render html to a nice PDF. The problem I had with having that code inside the monolith was that it increased my docker image creation for deploys by a lot. And that code pretty much never changed anyway.

I did feel a bit embarrassed having to make a microservice after having argued against them so much over the years. Hopefully I can stop producing PDFs soon so I can delete the entire thing :P

That honestly seems like a reasonable use case for (what I call) auxiliary services serving the monolith. As I imagine, there's no real business logic, no data storage / transactions, no authentication/authorization (besides the service being hidden in the private network probably).

That's exactly what my team did at a former company. We generated reports through a legacy document engine because some customers cannot switch/update their report templates and so we moved the logic out of the monolith into a service to get rid of a large portion of our dependencies.

Moved the monolith to .NET Core, kept the report service on .NET Framework. A win for everybody.

This is absolutely the way to go in my experience. Keep related functionality together, that'll probably result in a big monolith, with maybe a few smaller services orbiting it with very specific roles, or dramatically different traffic patterns. One project I worked on consisted of two monoliths, because we were at the intersection of two business domains, and it didn't make sense to attempt to slap those radically different concepts into one model.

Doesn't Docker use cached image layers to solve that? Your PDF rendering could be in one layer that never changes, and the rest goes on top.

The problem is when you have more than one such service. Now when one of them changes, all of them need to be rebuilt. You can solve this with multi-stage builds, but those only work if your build result can be easily copied.

Is the issue here that images shouldn't be thought of as layers, but rather a tree of cached directory nodes? I don't quite follow what's meant by building here, are you referring to compiling or merging the resulting build artifacts into a final container image?

Non-copyable build outputs sound a bit wild - you're thinking of builds that encode absolute paths into the output binaries?

In theory yes, but that doesn't work well on github actions for example. The cache layering seems quite bad there for some reason.

I feel like it's a semantics thing. To me the meaning of microservices has undergone semantic drift to the antipattern in the article where every little component or database table is its own service with an associated "pizza team".

It's fine to just have plain "services" to do things like this where you need to leverage another OS/framework/whatever and just hive off something like PDF conversion while your core application remains a monolith.

You can produce multiple docker images from the same codebase quite easily. You can deploy and scale them separately. None of that requires separate repositories or expensive RPC instead of local function calls.

Who said I have separate repositories?

What's the difference if they are in one or two repo if they produce two artifacts that are separated? You *will* have network calls between the two, unless you are marrying yourself with a deployment/operational platform that can run the two artifacts together. (ok, there could be a few but I really don't see how this is just using a "monorepo" instead of a "multirepo")

I feel you - I worked on a project with pdf generation and the tool to generate it was quite heavy.

Depends if you're counting all the WordPress level projects. Then it'd be 0.01% Vs 99.99% I'd imagine.

But that just puts into perspective how silly this argument is because I have no idea what a project means to other people.

I'm developing an ML based sideproject. All the modern ML tools are written in python, which is a reality good language for it. However, it is an abysmal project for writing business logic and third party integrations, and if I have some free time I will split the whole thing into one Python and one Typescript service.

There's also developer push from two sides; developers want to do microservices because it gives them gratification (new problems to solve! new architectures! Rewrite!), and employers want to attract developers (we do microservices! Blockchain! IoT!). So much in software development these days is hype and self-gratification.

The problem is that we are now in the golden age of Web services, where everything is headless and controlled via API, so the business logic plugging all those APIs need to live somewhere.

Naturally it could be a single container taking care of all those integrations.