We looked very hard at microservices some 5-6 years ago, and estimated we'd need ~40000 of them to replace our monoliths, and given a scale like that, who'd keep track of what does what ?
Instead we opted for "macroservices". It's still services, they're still a lot smaller units than our monoliths, but they focus on business level "units of work".
That is more or less the approach that I would recommend to modern microservices, I would advise someone to read about domain-driven design and I would ask them to pay very careful attention to the notion of bounded contexts, the idea of a namespace for business level words. If you build your microservices partitioned at bounded context level, and you vehemently resist the idea of a remote procedure call—“under no circumstances are you giving me orders, you are maybe telling me about a state change that has happened to you, but don't you dare tell me what to do and when,” those two principles can guide a decent architecture. Have a message broker. Do “event storming” with non-technical users of the system to get a better model of the domain. Stuff like that.
And yet, I will contradict myself to say that actually, microservices have the potential to be that original vision of object-oriented programming from the 1960s. The fundamental idea is very cheap computational nodes that only interact by passing messages around, with the idea that a recursive design inspired by cells and biology, will be much more successful than traditional programming where you try to separate data structures from the procedures that operate on them. If your microservice has setters and getters, you're missing the point of this original vision of OOP. You could certainly build a system with 40,000 of these live, but probably you would not have 40,000 different chunks of source code behind them.
>And yet, I will contradict myself to say that actually, microservices have the potential to be that original vision of object-oriented programming from the 1960s. The fundamental idea is very cheap computational nodes that only interact by passing messages around, with the idea that a recursive design inspired by cells and biology, will >be much more successful than traditional programming where you try to separate data structures from the procedures that operate on them. If your microservice has setters and getters, you're missing the point of this original vision of OOP. You could certainly build a system with 40,000 of these live, but probably you would not have 40,000 different chunks of source code behind them.
Lovely description of the actor model in erlang/elixir and akka :)
> You could certainly build a system with 40,000 of these live, but probably you would not have 40,000 different chunks of source code behind them.
We're "replacing" an old system that has lived on a mainframe for the past 60 years. In a strict microservice scenario we would indeed need 40000+ microservices to replace our core business.
The thing about (our) mainframe integration is that it is essentially made up of microservices, only they're small chunks of COBOL being called like pearls on a string, each producing output for the next in the chain.
Naïve microservices are separated per data store\DB. Because DBs are usually the bottleneck and we want to scale them separately per usage. Looks like they combined some to make it possible to manage, while not utilizing resources to the max.
The requirement of transactional consistency is one of the ways you identify a bounded domain in DDD. Well aggregates at least.
If you require transaction consistency across multiple microservices. They are to small.
If you don't require transactional consistency across microservices that's ok. Therefor they can be in separate databases anyway and messaging can be used.
Instead we opted for "macroservices". It's still services, they're still a lot smaller units than our monoliths, but they focus on business level "units of work".