Microservices can be replaced more easily than modules in a deployment monolith. Other components utilize a microservice via an explicit interface. If a new service offers the same interface, it can replace the existing microservice. The new microservice can use a different code base and even different technologies as long as it presents the same interface. This can often be impossible or difficult to achieve in legacy systems.
Small microservices further facilitate replacement. The need to replace code in the future is often neglected during the development of software systems. Who wants to consider how a newly built system can be replaced in the future? In addition, the easy replaceability of microservices reduces the costs of incorrect decisions. When the decision for a technology or approach is limited to a microservice, this microservice can be completely rewritten if the need arises.
Strong modularization and easy replaceability enable sustainable software development. Most of the time, working on a new project is straightforward, but over longer projects productivity decreases. One of the reasons is the erosion of architecture. Microservices counteract this erosion by enforcing strong modularization. Being bound to outdated technologies and the difficulties associated with the removal of old system modules constitute additional problems with deployment monoliths. Microservices, which are not linked to a specific technology, can be replaced one by one to overcome these problems.