1. Microservices
or
does the size matter?
Yuriy Senko
During the 2 past days I attendant several talks that were related to microservices architecture.
However all of them where dedicated to some kind of tooling or technics which allow to organize or implement microservices in a different ways.
But non of them made emphasize on how to design a proper microservices system, and especially how big or small your micro services should be.
And the size of the services impacts performance, robustness, reliability, testability and even development.
2. Grains of Sand
There is more or less well know pitfall in microservices architecture called “Grains of Sand”. It describes the situation when an architect or developer created services that
too fine-grained. So you may end up managing dozens or even hundreds of services in your system.
5. Analyze DB Transactions
ACID vs BASE
(BASE == basic availability, soft state, eventual consistency)
In a monolithic systems transactions usually provided on a database level.
However it’s very hard to achieve ACID transactions with micro services architecture.
If you analyzed your transactions needs and found that you cannot live without strong consistency than your services is probably too fine-grained.
6. Analyze Choreography
• Performance
• Reliability
• Robustness
Srv1
Srv2 Srv3
Srv4 Srv5
Analyze intern-services communications that are required to complete some business transactions.
If you end up making too much calls than your services are probably too much fine-grained.
7. Know You Business Driver
• Why are you doing microservices?
• What are the primary business driver?
• What architecture characteristics are most
important?
8. Common Business Drivers
Better time to market
via effective
development and
deployment pipeline
OR
Increase overall
availability, robustness
and scalability.
More fine-grained
services
More coarse-
grained services
Better time to market => more fine-grained services
Better availability, robustness and scalability => more coarse-grained services.