Microservices Adoption

Why Microservice Architecture
Path to Microservices
Obstacles, Patterns
Experiences

Transcript

1. MICROSERVICES ADOPTION #yte #microservices
2. Who am I? ozay_duman ozayduman ozayduman  12 years of experience  Software Architect  4 years on microservices development & Cloud Native Applications
3. Agenda 1. 2. 3. 4.
4. Architecture matters ? Domain knowledge Architecture
5. Monolith User Interface Business Logic Data Access Layer Team Organizations CI
6. Single Point of Failure
7. Classic Monolith Apps. How to scale monoliths?
8. How to Scale Monoliths Order Review Product LOAD BALANCER Order Review Product 0 .. n
9. Monolith Applications Can not Deliver rapidly, frequently and reliably Deployment frequency Lead time Mean time to recover
10. What is a Microservices Architecture?
11. autonomous work together business domain Microservice
12. maintainable testable loosely coupled independently deployable business capabilities small team Microservice
13. Microservice
14. Enriched SOA?
15. Centralised management of your services Order Service Payment Service Delivery Service Notification Service Accounting Service Enterprise Service Bus
16. Centralised management of your services Order Service Payment Service Delivery Service Notification Service Accounting Service centralized architecture == single point of failure
17. Smart endpoints, dumb pipes Order Service Payment Service Delivery Service Notification Service Accounting Service
18. Conway’s law Melvin Conway (1967) How to organize teams to build a scalable system?
19. How to organize teams to build a scalable system? Frontend Backend Database QA Ops .. Team A Team B Team C
20. How to organize teams to build a scalable system? Order Team Payment Team Delivery Team Order Service Payment Service Delivery Service Production CI/CD Pipeline
21. Why Microservices? Strong Module Boundaries Independently Deployable & Scalable Improved Fault Isolation Easier to Understand Develop Technology Diversity Autonomous Teams …
22. Scalability Microservices Monolith 1 * instances Partitions 1 * Y- Functional decomposition Z-Data partitioning X- Scale by cloning Chris Richardson
23. Y-axis scaling Order Payment Delivery Accounting Review Order Service Payment Service Delivery Service Review Service Accounting Service WAR/EAR
24. Scalability Microservices Monolith 1 * instances Partitions 1 * Y- Functional decomposition Z-Data partitioning X- Scale by cloning Chris Richardson
25. How to determine boundaries? Sub Domains Bounded Context DDD
26. Business Process Event Storming - DDD AGGREGATE COMMAND DOMAIN EVENT Domain Event Issues Command Aggregate External System View
27. But there is a price to pay ! Complexity of developing a Distributed System Transaction Management Eventual Consistency Complexity of Deployment & Operating Network Latency Complexity of Testing Requires Cultural Change
28. Inter Process Communication (IPC) • • • • •
29. How to implement transactions that span multiple services?
30. • • • • • Distributed Transactions
31. Broker Based Messaging Order Service Payment Service Delivery Service Notification Service T O P I C Partition Partition Partition Producer Consumer Consumer Consumer • Message Ordering • Delivery Guarantees • Scalability • Persistence • Durability • Duplicate Message Handling
32. Transactional Messaging Order Service T O P I C Partition Partition Partition Producer Order Table Event Table Message Publisher Database
33. Transaction Log Mining (Tailing) Order Service T O P I C Partition Partition Partition Producer Transaction Log Event Table Transaction Log Miner Postgres WAL Debezium LinkedIn Databus Database
34. Distributed Sagas-Eventual Consistency Order Service Inventory Service Delivery Service Payment Service REST API Tx:1 Tx:2 Tx:3 Tx:4 Tx:5
35. Distributed Sagas-Compensating Tx Order Service Inventory Service Delivery Service Payment Service REST API Tx:1 Tx:2 Tx:3 Tx:4
36. Distributed Sagas-Compensating Tx Order Service Inventory Service Payment Service REST API CTx:1 CTx:2 Tx:3
37. Orchestration Fisch conducts WA Symphony Orchestra. Credit: WASO
38. Sagas – orchestration based Inventory Service Delivery Service Payment Service REST API Message Broker Inventory Service Request Channel CreateOrderSaga Reply Channel Payment Service Request Channel Delivery Service Request Channel Create Order Saga Orchestrator Order Service Command Reply
39. Choreography
40. Sagas – choreography based Order Service Inventory Service Delivery Service Payment Service REST API Message Broker Order Events Inventory Events Payment Events Delivery Events Publish Subscribe
41. Self Contained Services Order Service Product Service REST API Message Broker Product Events Publish Subscribe Name Price Discount Products Table Name Price Discount Products Table id … Orders Table Phone 200 TL %3 TL Phone 200 TL %3 TL CQRS
42. Service Discovery Client Service Inventory Service Delivery Service Payment Service REST API REST API REST API 10.150.0.41:8080 10.90.0.23:7519 10.70.2.71:3333 dynamically changed dynamically assigned how to load balance?
43. Service Discovery-Self Registration Payment Service REST API 10.90.0.23:7519 register(‘payment’,10.90.0.23:7519); heartbeat(); unregister(); Service Registry @EnableEurekaClient
44. Service Discovery-Third Party Registration Payment Service REST API 10.90.0.23:7519 register(‘payment’,10.90.0.23:7519); heartbeat(); unregister(); Service Registry Registrator Health Check
45. Design For Failure Image credit: Chaos Monkey Netflix
46. Resiliency Network timeouts Rate Limiting Curcuit Breaker Health Checks Background photo created by mindandi - www.freepik.com
47. Service Mesh REST API Circuit Breaker Service Discovery Load Balancing Security Order Service Distributed Tracing Traffic Routing Sidecar Proxy Deployment Infrastructure
48. Leader Election Order Service REST API Message Broker Publish Publishing Messages @Schedule
49. • • • • Observability
50. Distributed Tracing • Zipkin • Pinpoint • Zaeger
51. Distributed Tracing
53. ozay_duman ozayduman ozayduman