Monoliths as an intermediate phase of microservices Modular

2 2 About product • Business domain: Insurance • Product: Policy Management System • Clients: Insurance Companies (b2b) • Target market: USA

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 Why Microservices? Benefits & Pitfalls

5 5 Microservices: Dev benefits • Team expertise • Horizontal scaling • Isolation • Experiments Testing in production?

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 Cost • DevOps culture • Infrastructure • Logs • Monitoring • Health checks, readiness checks • Tracing • Versioning policy

8 8 Risks

9 9 Incorrect decomposition: consequences • Slow releases • Big-bang deployment • Performance issues • Unexpected eventual consistency • Reliability • Distributed transactions

10 10 Distributed transactions: Two phase commit (2pc)

11 11 2pc: Drawbacks • Performance • Transaction coordinator can be a single point of failure (SPOF) • Vendor lock • Complex configuration

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 Sagas: Drawbacks • Compensations for all business operations • even for async ones • Requires discipline • and testing • What if compensation fails?

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 Just a clever thought https://twitter.com/simonbrown/status/573072777147777024

16 16 Modular Monolith What is it and how it can help?

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 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 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 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 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 Message Bus: Messages 1. Commands 1. Without response (void) 2. With response 2. Queries 3. Responses 4. Events

23 23 Message Bus: Interfaces

24 24 Message Bus: Handling abstractions

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 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 Web API • Controllers convert http requests to messages • No logic in controllers • Can be hosted in a single process

28 28 One Step To Microservices

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 Can modular monolith reduce risks of incorrect decomposition? • No • But it reduces cost of boundary changes • Cost of change matters

31 31 Thanks for your attention! Kirill Kovalevskiy Application Architect kkovalevskiy@oneinc.ru