The Gravity of Monoliths
One problem is that large microservices attract modifications and new features. They already cover several features; therefore, it seems a good idea to also implement new features in this service. This is true in the case of microservices that are too large but even more so for deployment monoliths. A microservices-based architecture can be aimed at replacing a monolith. However, in that case the monolith contains so much functionality that care is needed not to introduce too many changes into the monolith. For this purpose, microservices can be created, even if they contain hardly any functionality at the beginning. To introduce changes and extensions to the monolith is exactly the course of action that has rendered the maintenance of the deployment monolith impossible and led to its replacement by microservices.
As mentioned, most architectures do not have the problem that they were originally planned in a way that did not fit the task. In most cases the problem is more that the architecture did not keep up with the changes in the environment. A microservice- based architecture also has to be continuously adjusted; otherwise, at some point it will no longer be able to support the requirements. These adjustments include the management of the domain-based split as well as of the size of the individual microservices. This is the only way to ensure that the benefits of the microservice- based architecture are maintained over time. Since the amount of code in a system usually increases, the number of microservices should also grow in order to keep the average size constant. Thus an increase in the number of microservices is not a problem but rather a good sign.