Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Breaking Down The Monolith - NodeConfBP

Breaking Down The Monolith - NodeConfBP

RisingStack's journey about breaking down a monolith application into microservices.
Presented at https://nodeconf.risingstack.com in 2017 January.

Contact speaker here: https://twitter.com/slashdotpeter

Included topics:

- Business and technology benefits and drawbacks of microservices
- Why we moved
- Service principles: versioning and documenting
- Automation
- Proxy and API Gateway approaches
- Fault tolerance: Caching, CQRS
- Request Signing
- Zero downtime deployment: Kubernetes, Graceful shutdown, Rolling deployment, Self-healing
- Microservices monitoring and debugging challenges
- Distributed Tracing
- Network Delay use-case

What's next?

https://blog.risingstack.com/tag/node-js-at-scale
https://www.martinfowler.com/microservices
https://microserviceweekly.com/
https://trace.risingstack.com

1e2275ae49fccaa79d88fa6539492640?s=128

Peter Marton

January 20, 2017
Tweet

Transcript

  1. Breaking Down The Monolith

  2. - CTO, Co-founder of RisingStack - @slashdotpeter on Twitter -

    https://blog.risingstack.com $ whoami
  3. Microservices Img: http://ryanjbaxter.com

  4. Moving to microservices

  5. Moving to microservices

  6. - Co-located teams can work more efficiently - different space

    / time zone - Smaller teams are usually more efficient - More focused people - Faster onboarding for new developers Possible business reasons to move
  7. - Improved fault isolation - Independent development - Independent deployment

    - Allows technology diversity Technology benefits
  8. - Increasing architectural complexity - Increasing operational complexity - Monitoring

    and debugging are much harder - Handling eventual Consistency Technology drawbacks
  9. microservice architecture is not a silver bullet

  10. Why we moved?

  11. - Microservice monitoring tool - Node.js focused - Built in

    Node.js - We migrated to microservices architecture Trace by RisingStack
  12. - We wanted to have more focused teams - We

    have very different challenges - Fault tolerance is a key in our business Why we moved?
  13. Before we moved

  14. Today

  15. How we moved?

  16. Services and teams

  17. - Separate DB per service - Maximize the depth of

    service call chains Service principles
  18. - We create backward compatible endpoints - We don’t version

    services (only endpoints) - Use feature flippers/toggles (dark launches) Service principles
  19. - Good and available documentation - Update docs and code

    together Good to start here: https://github.com/Yelp/service-principles Service principles
  20. Automation

  21. - Automation is a key in building and operating microservices

    - Easy and fast to deploy - Easy and fast to rollback - Testing, Service bootstrap, DB migration etc. Automation
  22. Proxy / API Gateway

  23. Proxy / API Gateway

  24. - 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
  25. API Gateway Img: http://bits.citrusbyte.com/microservices

  26. Fault tolerance

  27. - Services fail separately (in theory) - Critical resources should

    be cached - Messaging queues can help (HTTP request is not recoverable) Fault tolerance
  28. Fault tolerant data collection - CQRS read write

  29. Fault tolerant data collecting Queue size increasing during issue Queue

    size decreasing after issue resolved
  30. Caching

  31. - On service level - Automatically via response headers -

    Via our communication package - Multi store caching (in memory, Redis): https://www.npmjs.com/package/cache-manager Caching
  32. Security

  33. - Trusted sources (services) on public channel - Request signing

    between services - Significant CPU overhead Request signing
  34. Request signing

  35. Infrastructure

  36. - Started with PaaS - We moved to Kubernetes -

    Zero downtime deployment Infrastructure
  37. Zero downtime deployment Deploy

  38. - Graceful shutdown - Rolling deployment - Self healing applications

    - Horizontal autoscaling Infrastructure
  39. Monitoring and debugging

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

    per service - Transactions - Logical connections - Side effects
  41. microservice monitoring is impossible for humans

  42. How to find an issue? Alerting, Dashboard Topology Metrics, Errors

    Traces Profiler Investigate a service Locate on code level Understand connections Identify participating services Always know about it
  43. Distributed tracing

  44. - Transaction ID, Correlation ID - Google Dapper white paper

    - Trace by RisingStack - Zipkin - OpenTracing Distributed tracing
  45. Case study: Network delay

  46. Case study: Network delay 3.8ms 564.8ms 95th response time: Call

    depth: 1 service 2 services
  47. Case study: Network delay network delay

  48. network delay is evil in microservices

  49. - https://blog.risingstack.com/tag/node-js-at-scale - https://www.martinfowler.com/microservices - https://microserviceweekly.com/ - https://trace.risingstack.com What’s next?

  50. Thanks!

  51. None