This comment was grayed out at the time I upvoted and am commenting. Either readers don't appreciate pedantry or don't realize what the point was, but for any n > 2, n * logn is a larger number than n.
I believe what the original poster meant to say was microservices grow like O(klogn) and monoliths O(n), i.e. microservices have some upfront constant cost that is large enough that, for small projects, monoliths will still perform adequately and be cheaper to develop and deploy. Once you exceed n large enough to overcome that upfront constant cost, microservices become the superior option.
I'm not agreeing or disagreeing with this, by the way.
Neither agreeing nor disagreeing, either, but the thing is… that both, monoliths and µ-services, are loose concepts, and they mean different things to different people and/or in differing circumstances.
A monolith itself can be monolithic either at the design level (only the whole thing can build and work) or at the deployment level (multiple components build, test and – to a certain extent can work – independently of each other but are assembled into a single deployment unit).
As far as differing viewpoints are concerned, let's consider a hypothetical design where GET, POST, PUT, PATCH and DELETE are a «µ-service» design and deploy as 5x distinct deployment units but as the whole and at once, i.e. leaving the DELETE out of the deployment renders the solution inoperable from the business POV. So far so good, we have a conventional µ-service.
Let's now consider a hypothetical yet real scenario where a single POST invocation triggers a chain of 27x service invocations to 10x different systems to produce a result. The implementation is stateless and idempotent, but the processing logic is complex, and it has to be executed in a particular sequence, intermediate results have to collated or fed into the next processing step – either sequentially, or in parallel, or both. And the processing can't be refactored out into smaller components due to the complexities or the business logic or due to technical constraints that the 10x external systems impose. Is the implementation of POST a µ-service, or POST is a monolith, or POST is a monolith within a µ-service? It can be either, neither or both – depending on the point of view. Such hypothetical design are, in fact, real and are fairly common in large environments.
On the scalability point, there is no single answer, either. A design can have scalability constraints either at the design level or at the deployment level. An example of the design level constraint is the strict processing order requirement that imposes substantial restrictions on what and how it can be scaled. It can typically only scale up but not out with not much room to wiggle around in. If the processing order is not important (i.e. the eventuality – not the linearity – is the only requirement), then scalability (up and out) becomes a deployment level constraint which is easy to fix (i.e. a configuration time or an auto-scaling policy change).
Scalability can also be impaired in both, monoliths and µ-services, if at least one external system is slow to respond, or the response time varies. In such a case, both designs will equally suffer.
> […] and be cheaper to […] deploy.
I have deliberately omitted the «develop» part to emphasise the «deploy» part. The deployment cost has gone down significantly over the last decade alone. What used to be an arduous task requiring a coordination of multiple people has now become a few line deployment file change and a one person job in many cases. Even complex deployments are much easier now than they had ever been. Therefore, I would posit that the cost of monolith and µ-service deployments is roughly the same today compared to monoliths being cheaper to deploy 10+ or so years ago.
I believe what the original poster meant to say was microservices grow like O(klogn) and monoliths O(n), i.e. microservices have some upfront constant cost that is large enough that, for small projects, monoliths will still perform adequately and be cheaper to develop and deploy. Once you exceed n large enough to overcome that upfront constant cost, microservices become the superior option.
I'm not agreeing or disagreeing with this, by the way.