The biggest beef I have with microservice architectures is lack of transactions across service boundaries. We say that such systems-of-systems are "eventually consistent", but they are actually never guaranteed to be in a consistent state -- i.e. they are always inconsistent. That pushes the responsibility for consistency to the system that needs to use the data -- making implementing those either extremely complex -- or more typically -- ignore the problem and introduce distributed timing bugs that are difficult to find in testing. The benefits of microservices are offset by losing the ability to build on database functionality to make your systems robust.

I guess I will never understand the microservices vs monolith debate. What about just "services"? There are 1001 reasons you might want to peel off functionality into a separate service. Just do that, without making it into some philisophical debate.

Unless you have Netflix scale, or Netflix scale problems, why bother with micro-services?

Most mid-scale problems don't demand a micro-services solution, with data ownership, delineation of service responsibilities, etc. Monoliths with single-truth databases work just fine.

Micro-services are an organizational convenience, and not a technology response to complexity. It's easier to manage groups of people than it is to manage complex technology. That's fine if you need it. Normally, it's not.

If it works for you, sure, go ahead. If it doesn't, don't chase a topical orthodoxy.

Microservices seem great when you're writing them, but they become unwieldy pretty fast.

At the beginning, it's nice to know that team A is responsible for service B, so that if there are any bugs/feature requests, you know who to go to.

This neat story falls apart if team A gets dissolved or merged with another team. The new group owning service B doesn't feel the same level of ownership. When maintenance work comes in (security vulnerabilities, stack modernization, migrations), the team is forced to internalize it rather than share it with other teams.

Operational maintenance also becomes a lot harder - deploying many services correctly is much more difficult locally, in pre-prod, and in production. Any benefits you get from writing a single HTTP server quickly are erased in the time spent on integration work with the rest of the company.

Here is a blog post that makes a more expansive argument against microservices: https://www.docker.com/blog/do-you-really-need-microservices...

I believe that microservices (but under a different model than K8s et al expose) are posed to make a huge comeback soon due to agentic development. My company has been investing significantly in this direction for a while, because agents need better APIs/abstractions for execution and interaction with cloud environments.

Once Claude Code came out something new clicked with me regarding how agent coordination will actually end up working in practice. Unless you want to spend a time of time trying to prompt them into understanding separation of concerns (Claude Code specifically seems to often ignore these instructions/have conflicting default instructions), if you want to scale out agent-driven development you need to enforce separation of concerns at the repo-level.

It's basically the same problem as it was 5-10 years ago, if you have a bunch of logic that interacts with each other across "team"/knowledge/responsibility/feature boundaries, interacting with your dependencies over an API, developing in separate repos, and building + rolling out the logic separately helps enforce separation of concerns and integration around well-specified interfaces.

In an ideal world, Claude Code would not just turn every repo into a ball of mud, at least if you asked it nicely and gave it clear guidelines to follow to prevent that. That was always true with monoliths and trying to coordinate/train less experienced developers to not do the same thing when, and it turns out we didn't live in an ideal world back then so we used microservices to prevent that more structurally! History sure does rhyme.

It is not unheard of to encounter a situation in enterprises where microservice architecture has been "too succesful".

There may be even 500 microservices and their number is growing rapidly. The situation might no longer be under control, sometimes even the responsibility for maintaining them is unclear or "shared". It is easier to implement a new microservice than track down who could implement something there.

I have encountered this problem several times, so I started a side project to bring such situations under control. It is still alpha, but first part -- scoping the problem -- is already pretty useful, allowing you to select, visualize and tag etc. microservices.

If anybody is interested, the code is here:

https://github.com/mikko-ahonen/arch-ascent/

The argument here, as far as I care to understand it rn, seems to be that micro services could actually live up to the promises if you follow ALL the rules religiously.

From personal experience, the problem is complexity. Which ends up costing money. At a certain scale, splitting off separate services may or may not make sense. But always building anything and everything as a set of black boxes that only communicate over network APIs, each potentially with their own database; is one of those ideas that sounds like fun until you've had a taste of the problems involved; especially if you have strong ACID requirements, or want to debug pieces in isolation.

> Purpose 1: Minimize Costs of Change

The cost of change is radically increased using micro services.

With microservices you scatter the business complexity across multiple services and lift a considerable amount of complexity from the easily testable code base and into the infrastructure.

IMHO doing a micro service architecture for this reason is horrible.

IME "Risk 2: Distributed Monolith" always comes back to bite. You have a nice separation of concerns at first, but then a quarter later there's some new feature request that cuts across those boundaries, and you're forced into distributed monolith territory.

Then the problem is you can't refactor it even if you wanted to, because other teams have taken dependencies on your existing APIs etc. Cleaning up becomes a risky quarter-long multi-team project instead of a straightforward sprint-long ticket.

I think AI is going to reverse the microservice trend too. The main problem that microservices improves is allowing teams to work more independently. Deployments, and especially rollbacks if there's a bug, can be quick for a microservice but take lots of coordination for monoliths. With AI (once/if it gets better), I imagine project work to be a lot more serial, since they work so much faster, and it'll be able to deploy one project at a time. A lot less chance of overlapping or incompatible changes that block monolith rollouts for weeks until they're resolved. A lot less extra feature-flagging of every single little change since you can just roll back the deployment if needed. Plus, a single codebase will be a lot easier for a single AI system to understand and work with e2e.

Main benefit with microservices is independent deployments.

In my team, we once had 5 deployments of our service in a day and we did not have to coordinate it with anyone outside the team. This is an amazing benefit. Not many realise the cost we pay due to coordination. I can't even imagine how this would work in a monolith. Maybe we would meticulously write code in our dev environment and kinda pray that it works properly in production when our code is released say once a day.

Real life is more messy and it is great that I had the option to deploy 5 times to production. That fast feedback loop is much appreciated.

One of the main advantages of microservices does not work with smaller teams: parallel, decoupled development. This is much easier with a service that is broken down into multiple well defined components than it is with larger chunks because the interfaces are much easier to test against.