Spawn a New Microservice
In addition, it is possible to use part of the code of a certain microservice to generate a new microservice (see Figure 7.7). The advantages and disadvantages are identical to the scenario in which code is transferred into a shared microservice. However, the motivation is different in this case: The size of the microservices is meant to be reduced to increase their maintainability or maybe to transfer the responsibility for a certain functionality to another team. Here, the new microservice is not supposed to be shared by multiple other microservices.
For instance, the service for registration might have become too complex. Therefore, it is split into multiple services, each handling certain user groups. A separation along technical lines would also be possible—for instance according to CQRS (see section 9.2), event sourcing (section 9.3) or hexagonal architecture (section 9.4).
Figure 7.7 Spawning a New Microservice
Finally, an additional way to handle microservices whose structure does not fit anymore is to rewrite them. This is more easily done with microservices-based architectures than with other architectural approaches due to the small size of microservices and their use via defined interfaces. This means that the entire system does not have be rewritten—just a part. It is also possible to implement the new microservice in a different programming language, which may be better suited for this purpose. Rewriting microservices can also be beneficial since new insights about the domain can leave their mark on the new implementation.