As developers, we always try to create reusable components to interact with systems or services in order to avoid writing code more than once. Most monolithic applications that we have built so far have followed a three-tier architectural pattern, as shown in the following diagram:

When a change is required in an application that is built using this model, you often need to modify all three layers. Depending on how the application is created, you might need many deployments. Furthermore, since large monolithic applications share a lot of functionality, it's common to find more than one team working on them, which makes it even harder for them to evolve quickly. Sometimes, specialized teams work on particular layers because these layers are comprised of many components. In this way, changes are applied horizontally to make the application grow and evolve.

With microservices, applications evolve vertically because they are modeled around a specific business domain. The following diagram shows a few microservices for an online store application:

The names by themselves explain the intention and the collection of capabilities associated with the microservices. Just by reading the names, anyone can understand what they do; how the tasks are carried out and how they are implemented is irrelevant at this point. Since these services are built around a well-defined business domain, only one service should be modified when a new change is required. Since no more than one team should work on a microservice, making them evolve is easier in comparison to large monoliths. The team in charge of the service has a deep understanding of how that particular service works and how to make it evolve.