Breaking down the monolith - devone

Slide 1

Slide 1 text

Breaking Down The Monolith By Peter Marton

Slide 2

Slide 2 text

- CTO, Co-founder of RisingStack - @slashdotpeter on Twitter - https://blog.risingstack.com $ whoami

Slide 3

Slide 3 text

- Helping companies to succeed with Node.js: - Training, Consulting, Support - Professional services - Trace: Node.js monitoring and debugging tool

Slide 4

Slide 4 text

- Why we moved: monolith, microservices - How we moved: services, teams and principles - Evolutionary design - Reliability and fault tolerance - Debugging and monitoring Agenda

Slide 5

Slide 5 text

Monolith Database

Slide 6

Slide 6 text

- Easy to ship, as all the parts move together - Easy to create a developer environment - Easy to monitor and debug (we have stack traces) - Perfect for MVP and smaller applications Monolith advantages

Slide 7

Slide 7 text

- Larger teams work on the same code base - Distributed teams can be challenging (in location / time) - Hard to keep a good modular structure - Cannot deploy small changes separately - Cannot scale features separately Monolith drawbacks

Slide 8

Slide 8 text

Monolith Database

Slide 9

Slide 9 text

Microservices Database Database

Slide 10

Slide 10 text

- Each element of functionality is a separate service - Split by features - Collection of loosely coupled services - Distributed system with remote calls Microservices

Slide 11

Slide 11 text

- Improves modularity - Smaller scope, easier to understand - Smaller codebase: easy to refactor or throw away - Services can be individually designed, developed, tested, and deployed (self-contained) Microservices advantages 1/2

Slide 12

Slide 12 text

- Services can be scaled separately - Allows technology diversity - Can improve reliability - Autonomous teams Microservices advantages 2/2

Slide 13

Slide 13 text

- Architectural complexity: distributed system - Eventual consistency - Operating complexity - Monitoring and debugging complexity - Not the most performant architectural pattern Microservices drawbacks

Slide 14

Slide 14 text

Complexity: before we moved

Slide 15

Slide 15 text

Complexity: today

Slide 16

Slide 16 text

- Loosely coupled: minimal dependence on other services - High cohesion: closely related functionality should stay together - Single bounded context: encapsulates internal details of a domain Don't be misled by the "micro" prefix. “Micro”services

Slide 17

Slide 17 text

- Avoid distributed transactions - Do not create service until: - You don’t understand the domain very well - When it’s not necessary - To prevent multiple data migrations Avoid: distributed monolith

Slide 18

Slide 18 text

microservice architecture is not a silver bullet

Slide 19

Slide 19 text

Moving to microservices

Slide 20

Slide 20 text

Moving to microservices

Slide 21

Slide 21 text

Microservices require organizational change

Slide 22

Slide 22 text

“organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations” - M. Conway Conway’s law

Slide 23

Slide 23 text

- UI Team - Backend team - Database team Organizing around Business Capabilities

Slide 24

Slide 24 text

Organizing around Business Capabilities Image: https://martinfowler.com

Slide 25

Slide 25 text

- Cross functional teams - Full range of skills: From UX to PM - Each of the teams have: backend, database, ops etc. - Mini products inside the company - Teams ows the full lifecycle Organizing around features

Slide 26

Slide 26 text

Cross functional teams Image: https://martinfowler.com

Slide 27

Slide 27 text

- Distributed teams (different space / time zone) - Smaller teams are usually more efficient - More focused and specialized people - Separate smaller releases are possible Possible business reasons to move

Slide 28

Slide 28 text

Why we moved?

Slide 29

Slide 29 text

- Very different challenges: - time series metrics, distributed tracing - Mission critical features: - alerting Our product has:

Slide 30

Slide 30 text

- We wanted to have focused teams - Develop and ship features separately - Segregate failures - Improve reliability We wanted to separate these features

Slide 31

Slide 31 text

How we moved?

Slide 32

Slide 32 text

- Highly aligned, loosely coupled teams - Principles helps in alignment - Principles should be created together - Teams must follow it Service principles: why?

Slide 33

Slide 33 text

- Automation is a key in building and operating microservices - Setup a new service with CI jobs and monitoring - Easy and fast to deploy and rollback - Testing, Database migration etc. - Reliability automations: auto scaling, rate limiters etc. Service principles: automate everything

Slide 34

Slide 34 text

- Services should own their data - Separate databases per services - Allow polyglot persistence (different database technologies) Service principles: data ownership

Slide 35

Slide 35 text

- Minimize the depth of the service call-graph - Minimize complexity - Increases performance Service principles: complexity

Slide 36

Slide 36 text

- Only high level utility code pieces - Common libraries and frameworks company wide: - High level framework - Libraries for: logging, caching, service communication etc. - Via private npm: scoped packages Service principles: code sharing

Slide 37

Slide 37 text

- We don’t want to version services - We do version endpoints - We create backward compatible endpoints - Use feature flippers / toggles (dark launches) Service principles: versioning

Slide 38

Slide 38 text

- Interface for other teams - Good and available documentation - Update docs and code together Good to start here: https://github.com/Yelp/service-principles Service principles: documentation

Slide 39

Slide 39 text

Evolutionary design

Slide 40

Slide 40 text

- Rewriting your application can be expensive and dangerous - Need to ship features in the meantime - Organizational change takes time Evolutionary design: why

Slide 41

Slide 41 text

Proxy

Slide 42

Slide 42 text

- Client(s) specific things: - Authentication: Cookie headers, JWT token etc. - Protocols: HTTP, WebSocket etc. - Response format: JSON, XML etc. - Combining resources: from multiple services API Gateway

Slide 43

Slide 43 text

API Gateway Img: http://bits.citrusbyte.com/microservices

Slide 44

Slide 44 text

- We moved from a PaaS - Services were communication via public internet - Trusted sources (services) - Request signing between services Security: request signing

Slide 45

Slide 45 text

Security: request signing

Slide 46

Slide 46 text

- Request signing had significant CPU overhead - Added ~10ms to each request - Moved to private networking - One entry point: API Gateway Private networking

Slide 47

Slide 47 text

One entry point: API Gateway

Slide 48

Slide 48 text

Fault tolerance

Slide 49

Slide 49 text

Services fail separately

Slide 50

Slide 50 text

Graceful service quality degradation Service B Service A Service D C Service B Service A Service D C

Slide 51

Slide 51 text

Services fail separately (in theory)

Slide 52

Slide 52 text

Failure Service B Service A Service D C Service B Service A Service D C

Slide 53

Slide 53 text

Resources should be cached Cache

Slide 54

Slide 54 text

- On service level by our communication library - Automatically via response headers (with HTTP): - "max-age" and "stale-if-error" - Multi store caching with stale and failover cache - https://github.com/RisingStack/cache Caching

Slide 55

Slide 55 text

- Services fail separately - Critical resources should be cached - Rate limiters and load shedders - Reliability automations: auto scaling, deploy strategies - Architectural patterns and messaging queues can help Fault tolerance

Slide 56

Slide 56 text

Fault tolerant data collection - CQRS (Command Query Responsibility Segregation) read (sync) write (async)

Slide 57

Slide 57 text

Fault tolerant data collecting Queue size increasing during issue Queue size decreasing after issue resolved

Slide 58

Slide 58 text

Infrastructure

Slide 59

Slide 59 text

- Fast private network - Quick deploys and rollbacks (with immutability) - Zero downtime deployment - Flexible resources, cheap instances Infrastructure: wanted

Slide 60

Slide 60 text

- Started with PaaS - Good at beginning: rollback, zero downtime deployment etc. - Slow and public networking - Expensive and non flexible instance types - Evaluated: more PaaS, AWS EB, Deis (v1) Infrastructure: what we had

Slide 61

Slide 61 text

- We moved to Kubernetes (GCP managed) - Container orchestration (Docker/rkt) - Graceful shutdown - Rolling deployment - Self healing applications - Horizontal autoscaling Infrastructure: Kubernetes

Slide 62

Slide 62 text

Monitoring and debugging

Slide 63

Slide 63 text

Microservices producing lot’s of data - Logs, Errors - Metrics per service - Transactions - Logical connections - Side effects

Slide 64

Slide 64 text

Needle in the haystack

Slide 65

Slide 65 text

microservice monitoring is impossible for humans

Slide 66

Slide 66 text

- Google Dapper white paper - Transaction ID, Correlation ID - Commercial: Trace by RisingStack, Dynatrace, AWS X-Ray - OSS: Jaeger, Zipkin - Instrumentation standard: OpenTracing Distributed tracing

Slide 67

Slide 67 text

Distributed tracing: Trace by RisingStack

Slide 68

Slide 68 text

Distributed tracing: Jaeger

Slide 69

Slide 69 text

Case study: Network delay

Slide 70

Slide 70 text

Case study: Network delay 3.8ms 564.8ms 95th response time: Call depth: 1 service 2 services

Slide 71

Slide 71 text

Case study: Network delay network delay

Slide 72

Slide 72 text

network delay is evil in microservices

Slide 73

Slide 73 text

- Use private network - Keep your applications close to each other - Limit the lengths of service call chains - Cache everything Network delay is evil

Slide 74

Slide 74 text

- https://blog.risingstack.com/tag/node-js-at-scale - https://microserviceweekly.com/ - https://risingstack.com/trainings What’s next?

Slide 75

Slide 75 text

Be confident with Node.js Thanks! Breaking Down The Monolith by Peter Marton, @slashdotpeter