Why I share this article. Because it coincide exactly to my understanding that if you are going microservices when you are designing an extremely large architecture, you will be paying dearly for all the tracing and logging, orchestration, which adds on much more operating cost than you reap any benefit from such a design.
How large is consider large? Based on what I have come across, anything less than 100 servers is probably still consider small.
The article is describing the corporate that contribute to the well-known Java framework in the industry today - namely Spring Cloud, which is based on Springboot within the Spring framework.
When architects speak of scalability issues in monolithic architecture, we are really referring to large organisations that need extremely large architecture to host all their applications need. If you need to artificially create teams to manage microservice designs, you are definitely doing it wrong. If you need to think hard on how to split your services, you are doing it wrong. If it is within a department that you implement microservices, it is most likely wrong too.
The article describe as each microservice larger than monolithic systems. Monolithic doesn’t mean One, it means homogeneous. Even homogeneous architecture can operate in parallel to scale across a very large user base.
It has nothing to do with which programming language or framework you choose. It has to do with the service and domain you are serving. Do yourself and your project a favour, don’t think microservices until you have exhausted all other options. It should be your last resort. Pay the price of splitting up things only when it make sense