Slide 1

Slide 1 text

MICROSERVICES ADOPTION #yte #microservices

Slide 2

Slide 2 text

Who am I? ozay_duman ozayduman ozayduman  12 years of experience  Software Architect  4 years on microservices development & Cloud Native Applications

Slide 3

Slide 3 text

Agenda 1. 2. 3. 4.

Slide 4

Slide 4 text

Architecture matters ? Domain knowledge Architecture

Slide 5

Slide 5 text

Monolith User Interface Business Logic Data Access Layer Team Organizations CI

Slide 6

Slide 6 text

Single Point of Failure

Slide 7

Slide 7 text

Classic Monolith Apps. How to scale monoliths?

Slide 8

Slide 8 text

How to Scale Monoliths Order Review Product LOAD BALANCER Order Review Product 0 .. n

Slide 9

Slide 9 text

Monolith Applications Can not Deliver rapidly, frequently and reliably Deployment frequency Lead time Mean time to recover

Slide 10

Slide 10 text

What is a Microservices Architecture?

Slide 11

Slide 11 text

autonomous work together business domain Microservice

Slide 12

Slide 12 text

maintainable testable loosely coupled independently deployable business capabilities small team Microservice

Slide 13

Slide 13 text

Microservice

Slide 14

Slide 14 text

Enriched SOA?

Slide 15

Slide 15 text

Centralised management of your services Order Service Payment Service Delivery Service Notification Service Accounting Service Enterprise Service Bus

Slide 16

Slide 16 text

Centralised management of your services Order Service Payment Service Delivery Service Notification Service Accounting Service centralized architecture == single point of failure

Slide 17

Slide 17 text

Smart endpoints, dumb pipes Order Service Payment Service Delivery Service Notification Service Accounting Service

Slide 18

Slide 18 text

Conway’s law Melvin Conway (1967) How to organize teams to build a scalable system?

Slide 19

Slide 19 text

How to organize teams to build a scalable system? Frontend Backend Database QA Ops .. Team A Team B Team C

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

Why Microservices? Strong Module Boundaries Independently Deployable & Scalable Improved Fault Isolation Easier to Understand Develop Technology Diversity Autonomous Teams …

Slide 22

Slide 22 text

Scalability Microservices Monolith 1 * instances Partitions 1 * Y- Functional decomposition Z-Data partitioning X- Scale by cloning Chris Richardson

Slide 23

Slide 23 text

Y-axis scaling Order Payment Delivery Accounting Review Order Service Payment Service Delivery Service Review Service Accounting Service WAR/EAR

Slide 24

Slide 24 text

Scalability Microservices Monolith 1 * instances Partitions 1 * Y- Functional decomposition Z-Data partitioning X- Scale by cloning Chris Richardson

Slide 25

Slide 25 text

How to determine boundaries? Sub Domains Bounded Context DDD

Slide 26

Slide 26 text

Business Process Event Storming - DDD AGGREGATE COMMAND DOMAIN EVENT Domain Event Issues Command Aggregate External System View

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

Inter Process Communication (IPC) • • • • •

Slide 29

Slide 29 text

How to implement transactions that span multiple services?

Slide 30

Slide 30 text

• • • • • Distributed Transactions

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

Transactional Messaging Order Service T O P I C Partition Partition Partition Producer Order Table Event Table Message Publisher Database

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

Distributed Sagas-Eventual Consistency Order Service Inventory Service Delivery Service Payment Service REST API Tx:1 Tx:2 Tx:3 Tx:4 Tx:5

Slide 35

Slide 35 text

Distributed Sagas-Compensating Tx Order Service Inventory Service Delivery Service Payment Service REST API Tx:1 Tx:2 Tx:3 Tx:4

Slide 36

Slide 36 text

Distributed Sagas-Compensating Tx Order Service Inventory Service Payment Service REST API CTx:1 CTx:2 Tx:3

Slide 37

Slide 37 text

Orchestration Fisch conducts WA Symphony Orchestra. Credit: WASO

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

Choreography

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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?

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

Design For Failure Image credit: Chaos Monkey Netflix

Slide 46

Slide 46 text

Resiliency Network timeouts Rate Limiting Curcuit Breaker Health Checks Background photo created by mindandi - www.freepik.com

Slide 47

Slide 47 text

Service Mesh REST API Circuit Breaker Service Discovery Load Balancing Security Order Service Distributed Tracing Traffic Routing Sidecar Proxy Deployment Infrastructure

Slide 48

Slide 48 text

Leader Election Order Service REST API Message Broker Publish Publishing Messages @Schedule

Slide 49

Slide 49 text

• • • • Observability

Slide 50

Slide 50 text

Distributed Tracing • Zipkin • Pinpoint • Zaeger

Slide 51

Slide 51 text

Distributed Tracing

Slide 52

Slide 52 text

No content

Slide 53

Slide 53 text

ozay_duman ozayduman ozayduman