Breaking Down the Monolith - Peter Marton, RisingStack

The story of how we broke our Node.js monolith into 15+ services in just a couple of weeks. The talk will focus on what we have learnt during the journey and what technologies we use. This is the tale of how we did this rather than what microservices are in general.

Transcript

2. Breaking down the monolith Peter Marton, Trace by RisingStack
3. whoami company: CTO, Co-founder of RisingStack work: Trace By RisingStack twitter: slashdotpeter blog: https://blog.risingstack.com
4. What is ? - Node.js performance monitoring tool - Microservice debugging tool - Built with Node.js - Built as a monolith in MVP phase
5. agenda 1. Monolith and Microservices 2. Why we moved to microservices? 3. Our experiences with microservices 4. Microservices challenges
6. 1. Monolith and microservices
7. monolith
8. monolith self-contained
9. monolith responsible for multiple tasks
10. microservice https://microserviceweekly.com
11. microservice smaller services each with separate DB https://microserviceweekly.com
12. microservice split code by feature not by functionality https://microserviceweekly.com
13. microservice complexity in network https://microserviceweekly.com
14. microservice NOT FOR MVP!
15. agenda 1. Monolith and Microservices 2. Why we moved to microservices? 3. Our experiences with microservices 4. Microservices challenges
16. 2. Why we moved to microservices?
17. Why microservices? growing engineering team
18. Why microservices? separated features -> more focused people
19. Why microservices? need for fault tolerance
20. agenda 1. Monolith and Microservices 2. Why we moved to microservices? 3. Our experiences with microservices 4. Microservices challenges
21. 3. Our experiences with microservices
22. Pros
23. Well focused independent teams (pro)
24. Faster innovation (pro)
25. Easier to scale a specific part (pro)
26. Features fail independently (pro)
27. Cons
28. Increasing architectural complexity (cons)
29. Increasing response times (cons)
30. Harder to test (cons)
31. Microservice experiences - Independent and focused teams (pro) - Faster innovation (pro) - Easier to scale (pro) - Features fail independently (pro) - Increasing architectural complexity (cons) - Increasing response times (cons) - Harder to test (cons)
32. agenda 1. Monolith and Microservices 2. Why we moved to microservices? 3. Our experiences with microservices 4. Microservices challenges
33. 4. Microservice challenges
34. Fault tolerance
35. If monitoring goes down... who knows that you are down?
36. Fault tolerance services fail separately
37. Fault tolerance critical resources should be cached
38. Our caching - service level caching - our service-lib handles it - via cache headers - Not an SDK
39. Fault tolerance temporary failures -> CQRS, reliable queue
40. ~CQRS
41. Persistent queue
42. Increasing complexity
43. Where we started (~8 months ago)
44. Where we are (today)
45. What if it breaks?
46. Logs everywhere
47. Distributed tracing
48. Distributed tracing
49. Distributed tracing - Transaction ID, Correlation ID - Google Dapper white paper - Trace by RisingStack (SaaS) - Zipkin
50. Response time
51. Even with very fast services
52. ...you can have a slow app :(
53. Because of network delays
54. Network delay is evil in microservices
55. Keep your services “close” to each other
56. Proxy approach
57. Proxy
58. Proxy - Evolutionary design (pro) - Authentication in proxy (pro) - Cookie handling at service (cons) - Service formats response for browser (cons)
59. Services interfaces are designed with browser in mind
60. API Gateway
61. API Gateway Img: http://bits.citrusbyte.com/microservices
62. API Gateway - Everything that’s client(s) specific: - Auth: Cookie headers, JWT token etc. - Protocol: http, WebSocket etc. - Response format: JSON, XML etc. - Combine resources: from multiple services
63. Security
64. Request signing - Trusted sources (services) on public channel - node-http-signature - Built-in in request and super-request npm libs https://github.com/joyent/node-http-signature
65. Service teams
66. Your services are products for your customers and co-workers!
67. Service principles
68. Service principles max. three depth call chains
69. Service principles always backward compatible endpoints
70. Service principles do not version services (only endpoints)
71. Service principles use feature toggles heavily (flippers)
72. Service principles good to start here: https://github.com/Yelp/service-principles
73. Documented API(s)
74. Documented API enforce documentation
75. Documented API update docs together with code
76. Documented API make it available for everyone
77. Challenges - Fault tolerance - Debugging with distributed tracing - Response times - Proxy / API Gateway - Service teams and principles - Documented API(s)
78. Thanks! https://trace.risingstack.com