Microservices

Microservices are small autonomous services that work together and ensure safety and change speed

characteristics of microservices

• small in size
• messaging enabled
• bounded by contexts
• autonomously developed
• independently deployable
• decentralized
• built and released with automated processes
• frequently deliver value to customers

Integrating applications

requirements

• Application coupling: applications should minimize their dependencies on each other so they can evolve without causing problems to others.
• Data timeliness: minimize time between ona application sharing data and other receiving it.
• Data or functionality: not share data but also functionalities, due to it provides a better abstraction between them
• Reliability: Reliable and asynchronous communication allows source application do other work

communication styles

• File Transfer
• Shared database
  • Domain logic associated with the data is likely to be repeated across consumers of the data
  • Different domain contexts impose different requirements on the data.
• messaging

With synchronous communication we face that service may be unavailable, take too long to respond (flaky) or respond with an error

• we should keep track of unsuccessful requests
• treat service as broken given certain threshold
• in case of broken service, we need a fallback solution
• healthcheck the service to use it again when it's available

Microservices layers

Modularized architecture

• deployed independently: have their own deployment flow
• provide communication interfaces,
• are tested
• can be coding-languages polyglot.

coercive architecture

they should not need a lot of communication with other microservices.

systematized architecture

gain insight in what happens in the system at large

Independence requires alignment

If teams do not talk with each other, you will end up with:

• duplicated effort across multiple services that cold have been reduced to a single and coordinated effort
• wrong decisions being made due to lack of domain knowledge and business vision and goals. OKRs must be visible by the whole company.

Changing from Monolith architecture

Everybody might think they made "design mistakes", but these mistakes are fruit of the required architecture for that phase of the project. Having a monolith allows figuring out the right services boundaries before implementing a microservices design and developing microservices prerequisites.

Identifying microservices

If you are aiming for a microservice architecture, it can be smart to divide the system info several grained services first in bounded contexts, see DDD

Existing departments

If the company has different departments already established, they have likely being formed around different business activities. People in these departments probably:

• use different parts of the software of in a different way
• look for other types of information or modify data instead of view it. Having these, we can define different software boundaries based on these teams. For each of these teams, we will have one product development and delivery team, limiting the interaction with other teams and the cost associated to it.

Domain experts

Another way to know how to divide the monolith into different service boundaries is talking to domain experts who have a deep knowledge of the application.If they remark to ask another persona about some concept, it's a clear sign of different boundary.

Data islands

Those data island may form clues as to which services may be able to function in an independent way. The danger is that you may divide based on data instead of domain.

Process stages

Another way to determine the service boundaries is look for clear demarcations between the steps in the business process you are trying to model. This may imply that changing one process has an impact in another process.