Breaking down the monolith - devone

Breaking down the monolith - devone

The story of how we broke our Node.js monolith into 20+ services in just a couple of weeks. The talk will focus on what we have learned during the journey and what technologies we use. This is the tale of how we did this rather than what microservices are in general. Attendees are going gain a better understanding on how a microservice architecture effects a company's structure and the daily work. The talk also highlights the key concepts and challenges of the microservice migration with providing practical solutions as well.

https://devone.at/

1e2275ae49fccaa79d88fa6539492640?s=128

Peter Marton

June 01, 2017
Tweet

Transcript

  1. 2.
  2. 3.

    - Helping companies to succeed with Node.js: - Training, Consulting,

    Support - Professional services - Trace: Node.js monitoring and debugging tool
  3. 4.

    - Why we moved: monolith, microservices - How we moved:

    services, teams and principles - Evolutionary design - Reliability and fault tolerance - Debugging and monitoring Agenda
  4. 6.

    - 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
  5. 7.

    - 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
  6. 10.

    - Each element of functionality is a separate service -

    Split by features - Collection of loosely coupled services - Distributed system with remote calls Microservices
  7. 11.

    - 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
  8. 12.

    - Services can be scaled separately - Allows technology diversity

    - Can improve reliability - Autonomous teams Microservices advantages 2/2
  9. 13.

    - Architectural complexity: distributed system - Eventual consistency - Operating

    complexity - Monitoring and debugging complexity - Not the most performant architectural pattern Microservices drawbacks
  10. 16.

    - 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
  11. 17.

    - 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
  12. 22.

    “organizations which design systems ... are constrained to produce designs

    which are copies of the communication structures of these organizations” -  M. Conway Conway’s law
  13. 23.
  14. 25.

    - 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
  15. 27.

    - 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
  16. 29.

    - Very different challenges: - time series metrics, distributed tracing

    - Mission critical features: - alerting Our product has:
  17. 30.

    - We wanted to have focused teams - Develop and

    ship features separately - Segregate failures - Improve reliability We wanted to separate these features
  18. 32.

    - Highly aligned, loosely coupled teams - Principles helps in

    alignment - Principles should be created together - Teams must follow it Service principles: why?
  19. 33.

    - 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
  20. 34.

    - Services should own their data - Separate databases per

    services - Allow polyglot persistence (different database technologies) Service principles: data ownership
  21. 35.

    - Minimize the depth of the service call-graph - Minimize

    complexity - Increases performance Service principles: complexity
  22. 36.

    - 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
  23. 37.

    - 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
  24. 38.

    - 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
  25. 40.

    - Rewriting your application can be expensive and dangerous -

    Need to ship features in the meantime - Organizational change takes time Evolutionary design: why
  26. 41.
  27. 42.

    - 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
  28. 44.

    - We moved from a PaaS - Services were communication

    via public internet - Trusted sources (services) - Request signing between services Security: request signing
  29. 46.

    - Request signing had significant CPU overhead - Added ~10ms

    to each request - Moved to private networking - One entry point: API Gateway Private networking
  30. 54.

    - 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
  31. 55.

    - 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
  32. 59.

    - Fast private network - Quick deploys and rollbacks (with

    immutability) - Zero downtime deployment - Flexible resources, cheap instances Infrastructure: wanted
  33. 60.

    - 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
  34. 61.

    - We moved to Kubernetes (GCP managed) - Container orchestration

    (Docker/rkt) - Graceful shutdown - Rolling deployment - Self healing applications - Horizontal autoscaling Infrastructure: Kubernetes
  35. 63.

    Microservices producing lot’s of data - Logs, Errors - Metrics

    per service - Transactions - Logical connections - Side effects
  36. 66.

    - Google Dapper white paper - Transaction ID, Correlation ID

    - Commercial: Trace by RisingStack, Dynatrace, AWS X-Ray - OSS: Jaeger, Zipkin - Instrumentation standard: OpenTracing Distributed tracing
  37. 73.

    - Use private network - Keep your applications close to

    each other - Limit the lengths of service call chains - Cache everything Network delay is evil