Ковалевский Кирилл "Модульные монолиты как начальный вариант микросервисов"

В последнее время тема микросервисов постепенно теряет былую популярность и, как следствие, многие разработчики стали смотреть на подобные темы с хорошей долей скепсиса и практицизма. Но, тем не менее, для многих идея разделения большой системы на несколько сравнительно небольших микросервисов все ещё является притягательной и несет определенные бенефиты.

Мы поговорим о промежуточном варианте архитектуры между монолитом и микросервисами, о так называемых «модульных монолитах» и затронем следующие моменты
1. Посмотрим как сделать так, чтобы от модульного монолита можно было действительно легко перейти к микросервисам.
2. Разберем основные составные части модульного монолита и необходимую для него инфраструктуру в системе
3. Поделимся своим опытом использования подобного рода архитектур и расскажем, что нас мотивировало начать именно с модульного монолита.

Transcript

1. Monoliths as an intermediate phase of microservices Modular
2. 2 2 About product • Business domain: Insurance • Product: Policy Management System • Clients: Insurance Companies (b2b) • Target market: USA
3. 3 3 Topics of this meetup • Benefits of microservices • Pitfalls that may occur • How modular monolith may help • Fast transition from modular monolith to microservices
4. 4 4 Why Microservices? Benefits & Pitfalls
5. 5 5 Microservices: Dev benefits • Team expertise • Horizontal scaling • Isolation • Experiments Testing in production?
6. 6 6 Microservices: Business benefits • Fast releases • Product & Organization scaling Convey law • Integration points • With already existing customer’s system • With some already existing system that we can buy • For system integrators
7. 7 7 Cost • DevOps culture • Infrastructure • Logs • Monitoring • Health checks, readiness checks • Tracing • Versioning policy
8. 8 8 Risks
9. 9 9 Incorrect decomposition: consequences • Slow releases • Big-bang deployment • Performance issues • Unexpected eventual consistency • Reliability • Distributed transactions
10. 10 10 Distributed transactions: Two phase commit (2pc)
11. 11 11 2pc: Drawbacks • Performance • Transaction coordinator can be a single point of failure (SPOF) • Vendor lock • Complex configuration
12. 12 12 Distributed transactions: Sagas • A saga is a sequence of local transactions • Local transaction = changes in db + messages • On failure - compensate each local transaction https://microservices.io/patterns/data/saga.html
13. 13 13 Sagas: Drawbacks • Compensations for all business operations • even for async ones • Requires discipline • and testing • What if compensation fails?
14. 14 14 Summary • Microservices have great benefits • For tech and business • But also have pretty dangerous pitfalls • Mostly related to incorrect decomposition • Especially related to transactions / consistency • And high cost
15. 15 15 Just a clever thought https://twitter.com/simonbrown/status/573072777147777024
16. 16 16 Modular Monolith What is it and how it can help?
17. 17 17 Modular Monolith • Consists of components not layers • Component ~ bounded context pure business logic • Component is a black box Classes are internal • Component exports only IoC module • Component lives in some host https://blog.cleancoder.com/uncle-bob/2011/09/30/Screaming-Architecture.html
18. 18 18 Component Host • Final Executable Web service, console app, etc. • Host components as a plugins • Isolates outside world • Infrastructure extensibility point Maybe useful for microservices
19. 19 19 Communications: In Process • Component publishes contract assembly with interfaces and DTOs • Component registers implementation of these interfaces • Other components use interfaces from contracts
20. 20 20 In Process: Drawbacks • Transaction Coupling • Could be compatible only with in process hosting • No any sign of incorrect decomposition • Migration to microservices can be hard
21. 21 21 Communications: Message bus “A Message Bus is a combination of a common data model, a common command set, and a messaging infrastructure to allow different systems to communicate through a shared set of interfaces.”
22. 22 22 Message Bus: Messages 1. Commands 1. Without response (void) 2. With response 2. Queries 3. Responses 4. Events
23. 23 23 Message Bus: Interfaces
24. 24 24 Message Bus: Handling abstractions
25. 25 25 Communication Via Bus • Contract consists of queries, events, commands • Server component handles queries and commands, publishes events • Client component sends queries, commands, consumes events
26. 26 26 Communication Via Bus: Notes • 1 message = 1 transaction • Simpler than REST • Use Cases = Message Handlers + Sagas • Asynchronous communications • Messages are serializable out of the box, by definition • Various transport implementations • InProc • RabbitMq • Azure Service Bus • If decomposition is incorrect you will feel it
27. 27 27 Web API • Controllers convert http requests to messages • No logic in controllers • Can be hosted in a single process
28. 28 28 One Step To Microservices
29. 29 29 Summary • Message Handlers + Sagas = Universal application layer Almost no changes in components • Easy transition to microservices • Flexible hosting model • Infrastructure extensibility point • Logging • Metrics • Tracing • Message processing pipeline https://www.youtube.com/watch?v=gkDqQgcbu08
30. 30 30 Can modular monolith reduce risks of incorrect decomposition? • No • But it reduces cost of boundary changes • Cost of change matters
31. 31 31 Thanks for your attention! Kirill Kovalevskiy Application Architect kkovalevskiy@oneinc.ru