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

Peter Marton

January 20, 2017
Tweet

More Decks by Peter Marton

Other Decks in Programming

Transcript

  1. - 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
  2. - Improved fault isolation - Independent development - Independent deployment

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

    and debugging are much harder - Handling eventual Consistency Technology drawbacks
  4. - Microservice monitoring tool - Node.js focused - Built in

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

    have very different challenges - Fault tolerance is a key in our business Why we moved?
  6. - Separate DB per service - Maximize the depth of

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

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

    together Good to start here: https://github.com/Yelp/service-principles Service principles
  9. - 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
  10. - 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
  11. - Services fail separately (in theory) - Critical resources should

    be cached - Messaging queues can help (HTTP request is not recoverable) Fault tolerance
  12. - 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
  13. - Trusted sources (services) on public channel - Request signing

    between services - Significant CPU overhead Request signing
  14. - Started with PaaS - We moved to Kubernetes -

    Zero downtime deployment Infrastructure
  15. Microservices producing lot’s of data - Logs, Errors - Metrics

    per service - Transactions - Logical connections - Side effects
  16. 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
  17. - Transaction ID, Correlation ID - Google Dapper white paper

    - Trace by RisingStack - Zipkin - OpenTracing Distributed tracing