Breaking Down the Monolith - Peter Marton, RisingStack

1e2275ae49fccaa79d88fa6539492640?s=47 Peter Marton
September 15, 2016

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.

1e2275ae49fccaa79d88fa6539492640?s=128

Peter Marton

September 15, 2016
Tweet

Transcript

  1. None
  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