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

1. Breaking down the monolith
Peter Marton, Trace by RisingStack

2. whoami
work: CTO, Co-founder of RisingStack
twitter: slashdotpeter
email: peter@risingstack.com
blog: https://blog.risingstack.com

3. agenda
1. Monolith and Microservices
2. Our experiences
3. Microservices challenges

4. 1. Monolith and
microservices

5. monolith

6. monolith
self-contained

7. monolith
responsible for
multiple tasks

8. monolith
independent from
other services

9. microservice
https://microserviceweekly.com

10. microservice
smaller services
each with separate DB
https://microserviceweekly.com

11. microservice
split code by feature
not by functionality
https://microserviceweekly.com

12. microservice
complexity in
network
https://microserviceweekly.com

13. microservice
NOT FOR MVP!

14. agenda
1. Monolith and Microservices
2. Our experiences
3. Microservices challenges

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

17. Why we moved to
microservices?

18. Why we moved?
growing engineering
team

19. Why we moved?
separated features ->
focused people

20. Why we moved?
need for
fault tolerance

21. 2. Our experiences

22. Pros

23. Well focused
independent teams (pro)

24. Easier to scale a
specific part (pro)

25. Easier to develop a
feature (pro)

26. Features fails
independently (pro)

27. Cons

28. Increasing architectural
complexity (cons)

29. Increasing
response times (cons)

30. Harder to
test and deploy (cons)

31. agenda
1. Monolith and Microservices
2. Our experiences
3. Microservices challenges

32. 3. Microservice
challenges

33. Fault tolerance

34. If monitoring goes down...
who knows that you are down?

35. Fault tolerance
services
fail separately

36. Fault tolerance
critical resources
should be cached

37. Our service caching
- service level caching
- our service-lib handles it
- via cache headers

38. Fault tolerance
temporary failures ->
persistent queues

39. Fault tolerance
event sourcing
(not just microservices)

40. ~Event sourcing with queue

41. Increasing complexity

42. Where we started (~8 months ago)

43. Where we are (today)

44. What if it breaks?

45. Logs everywhere

46. Where is the issue?

47. there...

48. Distributed tracing
- Trace by RisingStack
- Zipkin
- Google Dapper white paper
- Transaction ID, Correlation ID

49. Response time

50. Even with very fast services

51. ...you can have a slow app
:(

52. Because of network delays

53. Network delay is evil
in microservices

54. Keep your services
“close” to each other

55. Proxy approach

56. Proxy

57. Proxy
- Re-route requests to services
- Authorize requests via access-service
- Decorate flippers (feature flag)
- Rewrite urls

58. Proxy
- Evolutionary design (pro)
- Authentication in proxy (pro)
- Cookie handling at service (cons)
- Service format 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.
- 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
modules
https://github.com/joyent/node-http-signature

65. Request signing

66. Service teams

67. Your services are products
for your customers and co-workers!

68. Service principles

69. Service principles
max. three depth
call chains

70. Service principles
always backward
compatible endpoints

71. Service principles
do not version
services (only endpoints)

72. Service principles
use feature toggles
heavily (flippers)

73. Service principles
good to start here:
https://github.com/Yelp/service-principles

74. Documented API(s)

75. Documented API
enforce
documentation

76. Documented API
update docs
together with code

77. Documented API
make it available
for everyone

78. Thanks!
https://trace.risingstack.com