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.
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.
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.
I am yet to see this mysterious phenomenon of AI working so much faster and better than high performing teams. What I see so far, is sloppy code, poor tests and systems that do not scale in the long room.
Yeah, hence the "when/if". Still a few model generations off, IMO. But if it happens, I think "serialization of feature development" is going to have an outsized effect on architecture, process, planning, deployment, etc.
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.
I work on a monolith and deploy 20+ times per day to production, sometimes 100+ times depending on the day. weird that you’d say benefit of microservices is that you can do 5 deployments daily to production, that would not make my top-100 list to use them
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.
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.
You are right but from a different context. In a well thought out microservice architecture, you will not have business logic scattered across multiple services.
We have had instances of microservice architecture where doing one change required changes in 4 different microservices defeating the whole point. Obviously this is bad.
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...
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.
The only reasons I've seen to use microservices:
* It makes it easier to use multiple different languages.
* You can easily scale different parts of your application independently.
* Organisational convenience.
Usually though you don't need any of that.
The ecosystem. Micro services are the most efficient way to integrate CNCF projects deeply with your platform at any size.
The French railway service?
I'm not following. What does CNCF have to do with it?
https://landscape.cncf.io/ are micro services
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.
I am yet to see this mysterious phenomenon of AI working so much faster and better than high performing teams. What I see so far, is sloppy code, poor tests and systems that do not scale in the long room.
Yeah, hence the "when/if". Still a few model generations off, IMO. But if it happens, I think "serialization of feature development" is going to have an outsized effect on architecture, process, planning, deployment, etc.
First two pars are 100% correct. Third par, I'm not so sure about. The jury is still out, I feel.
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.
I work on a monolith and deploy 20+ times per day to production, sometimes 100+ times depending on the day. weird that you’d say benefit of microservices is that you can do 5 deployments daily to production, that would not make my top-100 list to use them
how many developers work on your monolith?
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.
You are right but from a different context. In a well thought out microservice architecture, you will not have business logic scattered across multiple services.
We have had instances of microservice architecture where doing one change required changes in 4 different microservices defeating the whole point. Obviously this is bad.