I always tell people: Microservices sacrifice everything at the alter of scalability. Everything but scalability gets harder, not easier. You point out some good examples of places where this is true.
You should not be doing microservices unless you need that scalability. If you don't, regular SOA or even modular monoliths work fine. Microservices live in the place where those break down in scaling. That's a very extreme place, and so microservices are an extreme response.
As an example, let's take scaling services over a hybrid cloud. You have your own metal for the baseline request volume, with the capability to provision more capacity from a public cloud. A modular monolith is obviously out of the picture at this point. You would have two separate monolith instances, and would have to consider how and when to pass work between them... Possible, but at that point you're basically inventing a service architecture within a monolith, so why not just move to SOA? If you already have a SOA system, you still have work: Which services to deploy to the cloud, when to deploy them, how to recover and load balance to them, etc. Specific answers to these decisions are what led to what we consider modern microservices: What to deploy is the smallest unit possible, so that you can keep scaling as fine-grained as possible. Every request is routed through a discovery and load-balancer to any and all available instances.
I disagree, microservices can offer many distinct benefits over a monolith. Yes, fine-grained scalability is a huge benefit, but there are many other advantages as well. I was going to list a bunch but honestly they can be found on google quite easily. More importantly though, is what I think is the key to making microservices deliver on their promises: Well defined and designed API's.
Designing good API's is important for all software, but is critical to making microservices work well; and it is not always obvious how to do this well. I can understand why so many people say you should start with a monolith and then break it up into microservices: With the monolith you have already accumulated a ton of domain knowledge so you can break apart the service-boundaries much easier. However, it can still be tricky to do this because not ever module in your monolith should be a service, infact it is likely that most will not. Microservices are a different level of encapsulation than a module. Sometimes microservices should done one thing well and with authority, sometimes they should do many things within the same domain/context, sometimes they should do an entire class of things to their data source, etc. Designing good API's forces you to understand how execution and data will flow through your system and how you can effectively and cleanly delineate between them.
IMO, the most important thing for a microservice, regardless of its size, complexity or role within your system, is it's API. When you have a well defined API you can encapsulate and abstract that entire service from the rest of your system, which is a wonderful thing. This microservice can now be deployed, updated, scaled, refactored or even rewritten entirely without any of the other services in the system even noticing. It brings a tremendous amount of freedom to managing your software platform. You no longer need to worry about things that don't concern your service, just fulfill your APIs and life is good!
I don't disagree with you, but I do disagree that you need microservices for those benefits. Just regular SOA gets you well defined APIs and contract-based interactions. Pretty much every touted benefit except granular scalability is a property of the underlying service architecture, not microservices.
After reading this thread I had to read this [1], which I found helpful in understanding the discussion. I think in some cases it is just more natural to write microservices but at the end of the day if done right the end user won't really know the difference, it's all just SOA(?)
* Single business function. Microservices don't have to be small, but all their calls should facilitate s single business function.
* Automated deployment. Services are deployed and undeployed live based on load.
* Unknown targets. Services are allocated and deployed to machines at runtime. The machine itself may even be allocated on demand. So service discovery is absolutely required.
* Stateless. Services instances can be spun down at any moment, so they can't be holding transaction state.
I have worked on a project that had millions of users which began to implement a microservice architechture over a monolith. It was completely unnecessary since the monolith could easily support a load of a lot more (we did test that).
I stopped working there (partly because they wouldn't hire anyone to work on the monolith) and afaik the monolith is still in production (or at least the majority of it) since the microservices took so long time to develop I guess someone pulled funding.
I have to say my experience with microservices is a bit limited, but every time I have seen someone do it I just think it is too complicated for very little gain. It takes massive resources to develop it and I am not convinced it's the design that makes it scale better.
As a rule, if you will need your transactions spread around different datacenters over the world (AKA, you are Google), you do need microservices. If you don't have those multiple active datacenters, or don't need coherence, you don't need microservices.
If your cluster of 7 database servers is still too slow when you increase it to 9, you probably need to take a look into database optimization, not microservices. If any of those numbers look laughable to you, you should laugh about microservices too.
That's a great question. I mean ability to serve concurrent requests, or throughput. Microservices will typically worsen other metrics like individual response time.
I am not sure microservices are good for scalability in that sense. Microservices divide your application vertically, but for scalability you want to divide it horizontally. You don't want a separate service for each feature of your app, you want an application server that you can replicate as many times as necessary.
Microservices can scale both directions, same as other systems. You can allocate more resources to individual service instances (vertical), and you can allocate more service instances (horizontal). The later scaling should be done in an automated fashion.
If you look at something like Spring Boot, you will find that an individual service instance is a stand-alone application server. That is what is duplicated when a new service instance is created.
Performance is highly application specific. It may be any combination of [throughput, latency, responsivity] x [maximum, minimum, average, some cut over a distribution, instantly measure on some important time]. And there are probably more possibilities, those are just the usual ones.
Microservices can make any one of them better, very likely at the cost of making other ones worse.
You should not be doing microservices unless you need that scalability. If you don't, regular SOA or even modular monoliths work fine. Microservices live in the place where those break down in scaling. That's a very extreme place, and so microservices are an extreme response.
As an example, let's take scaling services over a hybrid cloud. You have your own metal for the baseline request volume, with the capability to provision more capacity from a public cloud. A modular monolith is obviously out of the picture at this point. You would have two separate monolith instances, and would have to consider how and when to pass work between them... Possible, but at that point you're basically inventing a service architecture within a monolith, so why not just move to SOA? If you already have a SOA system, you still have work: Which services to deploy to the cloud, when to deploy them, how to recover and load balance to them, etc. Specific answers to these decisions are what led to what we consider modern microservices: What to deploy is the smallest unit possible, so that you can keep scaling as fine-grained as possible. Every request is routed through a discovery and load-balancer to any and all available instances.