Patterns of evolution from monolith to microservices
- 1. © 2021 Thoughtworks | Confidential Patterns of evolution from monolith to microservices
- 2. © 2021 Thoughtworks | Confidential 2 Sounds familiar? ● Does a small changes imply a new build that takes a lot of time? ● Does solving an incident of a business context interrupt development related to a different context? ● With the increase in the size of the code repo, has it become more complicated to keep the modules independent and contribute to the codebase? ● Is expensive and hard to scale the application because it implies a replication of a heavy process? ● Outdated dependencies requires a heavy maintenance effort? Probably you are facing the challenges of a overweight monolith
- 3. © 2021 Thoughtworks | Confidential Are you considering to move to microservices? or began already your journey of evolution? 3
- 4. © 2021 Thoughtworks | Confidential Karina Mora Tech Principal at Thoughtworks, with a 12-year track record in different business contexts. I had played various roles such as: developer, technical leader, architect and strategic advisor for Technological Initiatives, the role I currently play. Passionate about consulting at the strategy level, as well as being an active part in building the vision of teams that enable strategic initiatives. I am interested in topics related to security, cloud architecture, and technology platforms such as: OAuth and OpenIdConnect protocols, API Management, APIOps, Service Mesh, and Cloud architectures with Kubernetes. I enjoy blending technology with business, meaning understanding the technical details of architecture solutions, communicating them at different levels of detail, and working closely with business roles to connect technology decisions with business needs and priorities. 4
- 5. © 2021 Thoughtworks | Confidential What is a microservice?
- 6. © 2021 Thoughtworks | Confidential What is a microservice? ● Encapsulates one functionality in one process and corresponding independent service ● Changes of that functionality can scale independently 6
- 7. © 2021 Thoughtworks | Confidential Sounds good…there is a clear advantage 7
- 8. © 2021 Thoughtworks | Confidential Why not start directly with microservices?
- 9. © 2021 Thoughtworks | Confidential Defining the limits of each service 9 Going straight to a microservices architecture is risky A monolith allows us to know the complexity of a system as well as the limits of its components As complexity increases, microservices can be extracted You can continue to extract microservices as new boundaries are discovered and the complexity of managing the monolith increases
- 10. © 2021 Thoughtworks | Confidential What conditions do microservices require?
- 11. © 2021 Thoughtworks | Confidential Requirements for using microservices 11 Requirements for using microservices Ability to deploy quickly Monitoring Rapid Provisioning Capability DevOps Culture All of this requirements implies having Implementing a microservice-oriented architecture without having automation for testing or deployment is equivalent to building a building without having built the necessary foundations
- 12. © 2021 Thoughtworks | Confidential Principles followed by microservices 12 Belongs to a business domain It is highly observable Isolate the faults It is deployed independently Decentralize all the things Hide implementation details Has automation Microservices principles
- 13. © 2021 Thoughtworks | Confidential How to start with the evolution?
- 14. © 2021 Thoughtworks | Confidential 14 Referred Domain Driven Design concepts 14 © 2021 Thoughtworks Model Context Bounded context Ubiquitous Language Repository Domain Anticorruption layer A sphere of knowledge or activity A system of abstractions that represent specific aspects of the domain The setting in which a phrase or word appears and which determines its meaning An explicit definition of from and to where a definition of a particular model is correctly defined and applicable Common understanding of the definition that is shared by business experts and technical team Cross-context communication that ensures the isolation of the consumer model from concepts irrelevant to its context Common abstraction of object references for decoupled persistence of domain entities
- 15. © 2021 Thoughtworks | Confidential PATTERN Repository with ACL as a bridge to legacy model 15
- 16. © 2021 Thoughtworks | Confidential Step 1 - Select a context and a use case 16 Belongs to a business domain It is highly observable Isolate the failures It is deployed independently Decentralize all the things Hide implementation details Has automation Microservices principles Context Customer Business Logic New customer registration
- 17. © 2021 Thoughtworks | Confidential Isolate the failures Decentralize all the things Step 2 - Create the microservice 17 Belongs to a business domain It is highly observable Isolate the failures Decentralize all the things Hide implementation details Has automation Microservices principles Context Service Business Logic DB Adapter Repository Data Customer New customer registration without database It is deployed independently
- 18. © 2021 Thoughtworks | Confidential Isolate the failures Decentralize all the things Step 3 - Replace the database with a ACL 18 Context Service Business Logic Repository Customer New customer registration Translator Monolith <->Customer Coordinator ACL Data Monolith API API Belongs to a business domain It is highly observable It is deployed independently Hide implementation details Has automation Microservices principles
- 19. © 2021 Thoughtworks | Confidential Isolate the failures Decentralize all the things Isolate the failures Decentralize all the things Step 4 - Synchronize the monolith and microservice 19 Belongs to a business domain It is highly observable It is deployed independently Hide implementation details Has automation Microservices principles Context Service Business Logic Repository Customer New customer registration ACL Data Monolith DB Adapter Data API API Coordinator Queue Queue Event Retrofit
- 20. © 2021 Thoughtworks | Confidential PATTERN Canary release for incremental substitution 20
- 21. © 2021 Thoughtworks | Confidential 21 Canary release Rollout of functionalities based on business impact. Traffic is directed from a subset of users to the new services (new functionality), after ensuring that no issues were introduced, it is possible to move towards 100% traffic. Belongs to a business domain It is highly observable Isolate the failures It is deployed independently Decentralize all the things Hide implementation details Microservices principles Has automation
- 22. © 2021 Thoughtworks | Confidential Step 1 - Redirect traffic to the microservice ALB Load balancer Repositorio ACL Data Monolith API Event Retrofit 5% 95% Customer API
- 23. © 2021 Thoughtworks | Confidential 95% 5% Step 2 - Increase traffic to the microservice 23 ALB Load balancer Repositorio Data Monolith API 50% 50% API Customer ACL Event Retrofit
- 24. © 2021 Thoughtworks | Confidential 50% 50% 0% 100% Step 3 - Stop the traffic to the monolith 24 ALB Balanceador de carga Data Monolith API ALB Load balancer Repositorio API Customer ACL Event Retrofit
- 25. © 2021 Thoughtworks | Confidential PATTERN Strangle of the monolith 25
- 26. © 2021 Thoughtworks | Confidential Step 1 - Identify key contexts 26 Monolith Data API API API What business functionalities... ● change more often? ● have priority to be brought into production more frequently? ● are Core in the business? ● are strategic and can give me a competitive advantage?
- 27. © 2021 Thoughtworks | Confidential Data 27 Step 2 - Replace the contexts one by one Monolith API API API Event Retrofit Event Retrofit ACL Event Retrofit API Payment API Customer API Offer ACL ACL
- 28. © 2021 Thoughtworks | Confidential Let's not underestimate the cost of change 28 The strangle pattern: ● It seeks to reduce the risk of a more abrupt change such as creating a new system from scratch that replaces the legacy (Big Bang cut-over rewrite) ● Deliver results incrementally by enabling more frequent releases However, we must remember: ● A total monolith replacement can be a multi-year project ● It is essential to identify the key contexts and prioritize them ● When building an application it is better to design it to be throttled, the code of today tends to become a legacy in the future.
- 29. © 2021 Thoughtworks | Confidential 29 A new functionality brings challenges Monolith Data API Payment method registration API Customer API Payment Customer Preferred Payment Method Update Package/class level communication within the same process Network level communication REST request REST response timeout error response Customer Preferred Payment Method Update API
- 30. © 2021 Thoughtworks | Confidential 30 With the scale the challenges increase API API API API API API API API API API API API
- 31. © 2021 Thoughtworks | Confidential And the capabilities that are repeated service to service?
- 32. © 2021 Thoughtworks | Confidential In a microservice 32 API Customer Traffic management Retry rules Security Metrics generation Tracing They are not business logic Belongs to a business domain It is deployed independently Hide implementation details Microservices principles It is highly observable Decentralize all the things Has automation Isolate the failures But are indispensable in the microservice
- 33. © 2021 Thoughtworks | Confidential 33 In a complete ecosystem API API API API API API API API API API API API
- 34. © 2021 Thoughtworks | Confidential Service mesh 34 API Customer API Payment Customer Preferred Payment Method Update Infrastructure layer that allows supporting common capabilities in communication between microservices without having to include them in the code. REST request REST response Payment method registration
- 35. © 2021 Thoughtworks | Confidential Service mesh 35 Payment method registration API Customer API Payment REST request REST response Traffic management Retry rules Security Metrics generation Tracing Traffic management Retry rules Security Metrics generation Tracing Consul client Caches the certificates for mTLS communication Sidecar Proxy Sidecar Proxy Customer Preferred Payment Method Update Consul client Consul follower server Consul leader server Consul follower server Infrastructure layer that allows supporting common capabilities in communication between microservices without having to include them in the code.
- 36. © 2021 Thoughtworks | Confidential When to use service mesh? 36 ● A service mesh is very useful for migration to cloud scenarios, especially when migrating to container orchestration platform as Kubernetes or Nomad, due to its pod model they support multiple options (Linkerd, Consul, Istio). ● Service mesh also prevents that the multiple teams usually involved in microservices ecosystems, spend development time on ad-hoc resolution of these common features. ● Consul provides a good transition by generating a service discovery central registry that generates a layer that abstracts the details of hybrid scenarios like on premise VMs to be moved to containers in cloud.
- 37. © 2021 Thoughtworks | Confidential When to decide to start using events?
- 38. © 2021 Thoughtworks | Confidential PATTERN APIs Composition 38
- 39. © 2021 Thoughtworks | Confidential Step 1 - Create APIs composer 39 API Payment API Customer API Order APIs Composer API Gateway & Microservice (Business Capability API) R E S T re q u e s t R E S T re s p o n s e R E S T r e q u e s t R E S T r e s p o n s e REST request REST response Last orders of a customer with payment information used Data Last orders of a customer with payment information used SELECT DISTINCT c.*, o.*, p.* FROM CUSTOMER c, ORDER o, PAYMENT p WHERE c.id = p.customer_id AND c.id = ? AND o.paid_date >= ? Monolith QUERY
- 40. © 2021 Thoughtworks | Confidential Step 2 - Parallelize and order calls 40 API Customer API Order API Composer Monolito Customer Order Payment Last orders of a customer with payment information used APIs Composer R E S T r e q u e s t R E S T r e s p o n s e REST request REST response API Payment R E S T re q u e s t R E S T re s p o n s e
- 41. © 2021 Thoughtworks | Confidential Unavailability problem with REST 41 Availability depends on the availability of dependencies In a synchronous communication, there is coupling at runtime, which is evidenced by latency and availability. We need resilience mechanisms due to unavailability: - Retries - timeout - Fallback responses API Customer API Order APIs Composer R E S T r e q u e s t R E S T r e s p o n s e REST request REST response API Payment R E S T re q u e s t R E S T re s p o n s e
- 42. © 2021 Thoughtworks | Confidential PATTERN Circuit breaker with async request/response 42
- 43. © 2021 Thoughtworks | Confidential 43 Circuit breaker Avoid retrying an operation that is likely to fail, allowing the flow to continue with default responses while the problem is resolved. Upon detecting that the problem has been resolved, it allows the operation to be executed again normally. CLOSED OPEN HALF OPEN success retry for failure exceeds retries success restart retries failure fallback response
- 44. © 2021 Thoughtworks | Confidential 1 s 2 s 44 Timeout = 10 s Retries = 2 Restart time = 2 Step 1 - Configure the thresholds API Customer API Loyalty Account APIs composer R E S T r e q u e s t R E S T r e s p o n s e REST request REST response New customer registration COMMAND 2 3 1 API User R E S T r e q u e s t R E S T r e s p o n s e Response time: 12 s 22 s Thresholds
- 45. © 2021 Thoughtworks | Confidential 45 Step 2 - Define fallback response API Customer API Loyalty Account APIs composer R E S T r e q u e s t R E S T r e s p o n s e REST request REST response API User R E S T r e q u e s t R E S T r e s p o n s e HTTP 424 New customer registration COMMAND 2 3 1 Response time: 22 s
- 46. © 2021 Thoughtworks | Confidential 46 Step 3 - Complete the flow asynchronously API Customer API Loyalty Account APIs composer R E S T r e q u e s t R E S T r e s p o n s e REST request REST response API User R E S T r e q u e s t R E S T r e s p o n s e Queue 4 New customer registration COMMAND Queue 2 3 1 Notify the client about the update push
- 47. © 2021 Thoughtworks | Confidential Is APIs composition enough? 47 ● API composition is a simple pattern to implement and can be useful for many scenarios, especially querying. ● API composition should be designed considering resilience mechanisms (such as short circuit) and parallelism. ● The nature of the use case guides the decision of synchronous or asynchronous communication. ● We must handle the user experience to handle the expectation of eventually completing your need in the case of async. ● It is possible to have hybrid architectures.
- 48. © 2021 Thoughtworks | Confidential When to go direct for events?
- 49. © 2021 Thoughtworks | Confidential Saga 49 A saga is a sequence of local transactions (each one local to its microservice). Similar to how a DB-level atomic transaction (2PC) resolves data consistency in a monolith, a saga seeks to resolve data consistency in transactions involving multiple microservices. C1 C2 Tn+1 Tn+2 ... Pivot transaction Retriable transaction T1 T2 Compensable transactions
- 50. © 2021 Thoughtworks | Confidential PATTERN Saga orchestrator 50
- 51. © 2021 Thoughtworks | Confidential Compensable transactions by default enriched Pivot transaction Retriable transaction Later states created queued sent failed delivered Saga orchestrator 51 API API Saga orchestrator Send notification to the client based on their preferences COMMAND API Email Sending Whatsapp Sending SMS Sending Persistent object that implements a state machine and is responsible for invoking each participant in the saga Queue Queue Queue Queue Queue Queue API Customer NOTIFICACIÓN notification id Queue Queue push
- 52. © 2021 Thoughtworks | Confidential PATTERN Saga choreography 52
- 53. © 2021 Thoughtworks | Confidential Saga choreography 53 API Customer API Loyalty Account Message broker API User 4 New client registration COMMAND Queue 2 3 1 Queue Queue user id 5 7 8 6 9 Distributed coordination in which each microservice emits and consumes events associated with the transactions of the saga A messaging broker in this pattern makes it possible to guarantee the delivery of messages
- 54. © 2021 Thoughtworks | Confidential Comparison 54 Orchestration ● Centralized decision making ● Asynchronous request/response oriented saga ● The coordination logic is composed of the invocation to each participant, their response events and the compensations invoked by the orchestrator. Choreography ● Distributed decision making ● Event oriented saga ● The coordination logic is composed of events published by each microservice plus the handlers to consume them implemented in each microservice that must execute the compensations
- 55. © 2021 Thoughtworks | Confidential PATTERN CQRS & event sourcing 55
- 56. © 2021 Thoughtworks | Confidential Concepts 56 CQRS ● Segregation of command and consultation responsibilities. ● Use events to update a query replica. ● It can be implemented with event sourcing or with traditional persistence. Event sourcing ● Event driven persistence ● Event storage can act as a broker ● The business entity is persisted as a sequence of state change events. ● The last state is reconstructed based on the events.
- 57. © 2021 Thoughtworks | Confidential A real example 57 Data model for commands Data model for queries Message broker Order Order History Materialized view POST PUT DELETE COMMAND QUERY GET Events Events It can be event sourcing Last orders of a customer with payment information used
- 58. © 2021 Thoughtworks | Confidential Trade offs 58 CQRS ● Useful when API composition is inefficient for queries as it may contain history of combined entities from multiple microservices. ● There is a cost associated with replica storage. ● The materialized view is eventually consistent. Event sourcing ● It is convenient to use it in choreography, since it eliminates the need for translation from event to persistence. ● Ensures the accuracy of audit trails. ● Simplifies queries based on change history. ● Adds inherent complexity to the architecture
- 59. © 2021 Thoughtworks | Confidential Final thoughts
- 60. © 2021 Thoughtworks | Confidential To keep in mind 60 ● Not everything has to be microservices, it is necessary to understand the need we currently have. ● We can have hybrid solutions, with synchronous and asynchronous communication according to each use case. ● In this process of evolution there are multiple patterns that can help us. ● Each step we take made our architecture evolve, whether towards microservices or events, generates value for us, solving problems that we identify along the way, but introduces more complexity, that is why the foundations of a DevOps Culture (Observability, Continuous Delivery, Provisioning) are essential for this.
- 61. © 2021 Thoughtworks | Confidential Questions Karina Mora Tech Principal Thoughtworks Chile kmora@thoughtworks.com 61 Does this architecture evolution journey sound familiar to you? Are you facing similar challenges? Are you considering a event oriented architecture for your solution?