Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×

Breaking Down the Monolith - Peter Marton, RisingStack

Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige

Hier ansehen

1 von 78 Anzeige

Breaking Down the Monolith - Peter Marton, RisingStack

Herunterladen, um offline zu lesen

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.

Agenda:

1. monolith and microservices in nutshell
2. advantages of microservices from our view
- well focused service teams, happy customers
- fault tolerance
- distributed responsibility
- improving quality
3. disadvantages of microservices-based our experience
-growing complexity
-errors in transactions
-response time issue
4. how we did it
-service team principles
-co-operation between teams
-company architecture changes
-breaking down via proxy
-request signing
-circuit breaker
-event sourcing

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.

Agenda:

1. monolith and microservices in nutshell
2. advantages of microservices from our view
- well focused service teams, happy customers
- fault tolerance
- distributed responsibility
- improving quality
3. disadvantages of microservices-based our experience
-growing complexity
-errors in transactions
-response time issue
4. how we did it
-service team principles
-co-operation between teams
-company architecture changes
-breaking down via proxy
-request signing
-circuit breaker
-event sourcing

Anzeige
Anzeige

Weitere Verwandte Inhalte

Diashows für Sie (20)

Andere mochten auch (20)

Anzeige

Ähnlich wie Breaking Down the Monolith - Peter Marton, RisingStack (20)

Weitere von NodejsFoundation (20)

Anzeige

Aktuellste (20)

Breaking Down the Monolith - Peter Marton, RisingStack

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

×