You're missing the biggest challenge of all: observability. How to trace the path of a single request through a variety of microservices that may communicate synchronously or asynchronously, prevent infinite loops and generally see what happened and why.
Not only that. Complexity of the whole system is much higher, much more moving parts, much more failure scenarios, and so on and so forth. There should be really important reasons to choose microservices and usually those reasons are not technical but organizational.
well, I generally agree with the exception of the last point. Sure, it varies with your personal experience but I worked a bit in insurance and there it's a great technical reason to have (micro) services (I'd say services, not focus on micro-by the book) when you have a lot of moving parts (interactions with backends of insurers of different layers, payment backends and their feedback, management of insured information, policy logic and so on) where it's a HUGE advantage to be able to scale them independently (scaling an insurance or just a payment monolith is insanely costly).
Well, strictly speaking you can always solve something by a nice technical solution OR by throwing money/resources at it, so you can view the need as either technical or organisational depending on which restriction came first, but if you're at the point when it's either microservices or your company goes bankrupt - then it's already too late. It's better to build up the microservice knowledge with some minimal investment so that you have the option before you haphazardly rush into it and make a bigger mess.
In majority of cases services don't do any heavy-lifting and usually I/O bounded (most often - DB bounded). In this case advertised microservice-style scaling by adding more instances is useless.
And microservices itself are not a solution which can prevent bankrupcy of the company. Actually microservices just enforce cleanup/rework of the design of the system. And this cleanup/rework is the main source of improvement. But it can be done without microservices as well, just not everybody realize that.
Beside breaking monolith into a set of separate applications, there is another option - embed services consisting monolith into data grid node. It has most benefits of microservices along with a number benefits unique to this approach. And it avoids all downsides of microservices and monoliths.
With this approach there are several ways to scale:
nearlty linear horizontal scaling by adding more nodes to the grid
scaling computationally-intensive services by running more instances of services at different nodes
scaling by using "data affinity" - colocating related data at same nodes and performing procesing at these nodes (i.e. instead of fetching all data every time they're necessary, process data locally at nodes which hold the data). In addition there is possibility to maintain several data replicas, so processing can be scaled by adding more replicas.
So, yes, there are alternative approaches, but they are not hype. Perhaps because they don't feed cloud providers as good as microservices :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
You're missing the biggest challenge of all: observability. How to trace the path of a single request through a variety of microservices that may communicate synchronously or asynchronously, prevent infinite loops and generally see what happened and why.
Not only that. Complexity of the whole system is much higher, much more moving parts, much more failure scenarios, and so on and so forth. There should be really important reasons to choose microservices and usually those reasons are not technical but organizational.
well, I generally agree with the exception of the last point. Sure, it varies with your personal experience but I worked a bit in insurance and there it's a great technical reason to have (micro) services (I'd say services, not focus on micro-by the book) when you have a lot of moving parts (interactions with backends of insurers of different layers, payment backends and their feedback, management of insured information, policy logic and so on) where it's a HUGE advantage to be able to scale them independently (scaling an insurance or just a payment monolith is insanely costly).
Well, strictly speaking you can always solve something by a nice technical solution OR by throwing money/resources at it, so you can view the need as either technical or organisational depending on which restriction came first, but if you're at the point when it's either microservices or your company goes bankrupt - then it's already too late. It's better to build up the microservice knowledge with some minimal investment so that you have the option before you haphazardly rush into it and make a bigger mess.
In majority of cases services don't do any heavy-lifting and usually I/O bounded (most often - DB bounded). In this case advertised microservice-style scaling by adding more instances is useless.
And microservices itself are not a solution which can prevent bankrupcy of the company. Actually microservices just enforce cleanup/rework of the design of the system. And this cleanup/rework is the main source of improvement. But it can be done without microservices as well, just not everybody realize that.
If you can tell me how to scale independent domains of a large monolith without breaking it into separate applications (micro or not) please share :)
Beside breaking monolith into a set of separate applications, there is another option - embed services consisting monolith into data grid node. It has most benefits of microservices along with a number benefits unique to this approach. And it avoids all downsides of microservices and monoliths.
With this approach there are several ways to scale:
So, yes, there are alternative approaches, but they are not hype. Perhaps because they don't feed cloud providers as good as microservices :)