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

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!