Microservices Intro + Communication Patterns

1. Microservices. Intro
Oleksandr Gavrisyuk, Pavlo Serdyuk

2. The Scale Cube
Marton Abbott & Michael Fisher

3. X-axis scaling
• Load balancer
• Many copies of same application
• OK with Monolithic approach
• OK together with Y-scaling for Microservices approach
• Disadvantages
• Same DB anyway (CAP theorem)
• Upgrades and releases are complex
• Inefficient with increasing development and application complexity

4. Z-axis scaling
• Scale by data
• Each server runs an identical app (as in X-scale)
• Each server is responsible for only a subset of the data (for example, region
– Europe, America, etc)
• Disadvantages - Increased application complexity.
• Partitioning scheme
• Search service consists of a number of partitions
• Query aggregator
• Doesn’t solve the problems of increasing development and application complexity.

5. Y-Axis Scaling
• Split by functionality
• Each service is responsible for one or more closely related functions.
• Different way of decomposition – DDD, verb/noun-based
decomposition
• Disadvantages
• Decomposition complexity
• Interactions complexity

6. Microservices
• Microservice architectural style is an approach to developing a single application as a suite of small services,
each running in its own process and communicating with lightweight mechanisms, often an HTTP resource
API.
• https://www.martinfowler.com/articles/microservices.html

7. Architecture sample

8. Scaling Microservices vs Monolitic

9. Scaling
• Один функціонал може бути більш запотребований ніж інший.
Мікросервіси оптимально вирішують проблему навантаження за
допомогою різної кількості екземплярів
• В монолітному ми маємо “Купити корову заради склянки молока”

10. Technology Heterogeneity
• Technology Heterogeneity

11. Resilience
• Якщо один завалиться, то інші працюватимуть (на відміну від
моноліта)
Фейл
моноліта
Фейл
мікросервісу

12. Фейли розподілених систем
• Інша проблема – фейл може лишитись непомітним
• Health/monitoring Check

13. Ease of Deployment
• Доставляти можна частинами
• Але монолітним деплойментом простіше керувати
• При монолітному підході робота зупиняється під час деплойменту

14. Інші переваги
• Organizational Alignment
• При розподіленій розробці кожна команда може відповідати за свої
сервісі – менші затрати ні інтеграцію
• Кожна команда може мати свої технології
• Composability
• Легше компонувати – можна легше перейти на іший клієнт (десктоп,
мобільний, веб)
• Optimizing for Replaceability
• Мікросервіси менше схильні переростати в Legacy code

15. Microservices pros and cons
• Independent, easy and frequent
deployment. Customers are
happy
• Scalability
• Independence in case of failure
• Independent and parallel
development
• *High testability
• *Independent technology
stacks
• Increased effort for operations,
deployment and monitoring.
• Increased configuration
management
• More complex development
• Unsafe distributed
communication.
• Transaction
• Performance

16. Concepts
• Small, and Focused on Doing One Thing Well
• Autonomous

17. Microservices communication patterns

18. Microservices communication

19. Message Bus/Event Bus/Event Stream

20. Other:
Kafka
MapR

21. Message bus
• Events are grouped into logical collections of events called Topics
• Topics are partitioned for parallel processing
• Kafka
• Unlike a queue, events are persisted, even after they are delivered they
remain on the partition, available to other consumers.
• Messages are not deleted from Topics when read, and topics can have
multiple different consumers, this allows processing of the same messages by
different consumers for different purposes.
• Older messages are automatically deleted based on the Stream’s time-to-live
setting

22. Orchestration Versus Choreography
• Orchestration
• Ми керуємо з одного центру (як
диригент), жостка синхронізація
• Choreography
• Кожна частина має більше самостійності
(як танцюристи), синхронізуються між
собою самі в разі потреби

23. Orchestration Versus Choreography
• Приклад. Додаємо нового користувача
• Створюється новий запис в БД
• Нараховуються бонуси за референство (loyalty )
• Висилаємо лист на електронну пошту
• Висилаємо інформаційний пакет

24. Pattern: Saga
• Each service has its own database.
• Some business transactions, however, span multiple service
• http://microservices.io/patterns/data/saga.html
• Example: You must ensure that a new order will not exceed the
customer’s credit limit

25. Choreography-based saga

26. Example: Orchestration-based saga
1.The Order Service creates an Order in
a pending state and creates a CreateOrderSaga
2.The CreateOrderSaga sends
a ReserveCredit command to the Customer
Service
3.The Customer Service attempts to reserve
credit for that Order and sends back a reply
4.The CreateOrderSaga receives the reply and
sends either
an ApproveOrder or RejectOrder command to
the Order Service
5.The Order Service changes the state of the
order to either approved or cancelled

27. Pattern: Event sourcing
• The event store also behaves like a message broker
• Event sourcing persists the state of a business entity such an Order or
a Customer as a sequence of state-changing events.
• Whenever the state of a business entity changes, a new event is
appended to the list of events.
• Applications persist events in an event store, which is a database of
events.
• The store has an API for adding and retrieving an entity’s events.

29. Pattern: Command Query Responsibility
Segregation (CQRS)
Split the application into two parts:
• command-side
• the query-side