Microservices are distributed and dynamic

Successful microservices implementations encapsulate logic and data within the service. This results in two unconventional situations:

• Distributed data and logic
• Decentralized governance

Compared to traditional applications, which consolidate all logic and data into one application boundary, microservices decentralize data and logic. Each service, aligned to a specific business capability, owns its own data and logic:

The dotted line in the preceding diagram implies the logical monolithic application boundary. When we migrate this to microservices, each microservice, A, B, and C, creates its own physical boundaries.

Microservices don't typically use centralized governance mechanisms the way they are used in SOA. One of the common characteristics of microservices implementations are that they are not relaying on heavyweight enterprise-level products, such as an Enterprise Service Bus (ESB). Instead, the business logic and intelligence are embedded as a part of the services themselves.

A retail example with ESB is shown as follows:

A typical SOA implementation is shown in the preceding diagram. Shopping Logic is fully implemented in the ESB by orchestrating different services exposed by Customer, Order, and Product. In the microservices approach, on the other hand, shopping itself will run as a separate microservice, which interacts with Customer, Product, and Order in a fairly decoupled way.

SOA implementations are heavily relaying on static registry and repository configurations to manage services and other artifacts. Microservices bring a more dynamic nature into this. Hence, a static governance approach is seen as an overhead in maintaining up-to-date information. This is why most of the microservices implementations use automated mechanisms to build registry information dynamically from the runtime topologies.