The document discusses various topics related to surviving in a microservices environment. It begins by outlining some benefits of microservices such as reduced coupling, continuous delivery, and efficient scaling. It then covers infrastructure topics like managing logs, metrics, deployments, builds, and environments. Architecture topics discussed include overall design, technologies, testing approaches, communication methods, and data persistence. The document also addresses team communication and processes. It concludes by providing some miscellaneous advice for working with microservices.

1. Surviving In A Microservices
Environment
Steve Pember
CTO, ThirdChannel
Greach, 2018
@svpember

2. @svpember
Microservice Blog Posts & Presentations
• Microservices: Yay!
• Microservices: Boo!
• Smashing The Monolith (and here’s how we did it)
• Microservices + Technology X
• Microservices + Methodology Y

3. Microservices have many lessons to offer

4. What even are Microservices?

6. @svpember
Why Choose Microservices?
• Reduce Coupling!
• Right Tool for the Job
• Continuous Delivery
• Smaller codebases are easier to reason about
• Easy to replace old services
• Efficient Scaling
• Can move quickly (once you’re up and running)

9. Help?

10. @svpember
Microservice Topics
• Infrastructure
• Architecture
• Team Communication
• Miscellaneous Advice

11. @svpember
Microservice Topics
• Infrastructure

12. @svpember
Infrastructure
• How do we manage the logs?

13. Centralized Logs are your
#1 Priority

14. @svpember

15. @svpember

16. @svpember

17. @svpember

18. @svpember

19. @svpember
Infrastructure
• How do we manage the logs?
• How about metrics / telemetry?

20. You’d best be monitoring your platform.

22. –Johnny Appleseed
“Type a quote here.”

24. @svpember
Infrastructure
• How do we manage the logs?
• How about metrics / telemetry?
• How do we deploy our code?

26. @svpember

27. @svpember
Infrastructure
• How do we manage the logs?
• How about metrics / telemetry?
• How do we deploy our code?
• How/where are our builds done?

28. @svpember

29. @svpember

30. @svpember

31. @svpember
Infrastructure
• How do we manage the logs?
• How about metrics / telemetry?
• How do we deploy our code?
• How/where are our builds done?
• Do we have any coding conventions?

32. Check Style? Coverage?

33. @svpember

34. @svpember

35. @svpember

36. @svpember

37. @svpember
Infrastructure
• How do we manage the logs?
• How about metrics / telemetry?
• How do we deploy our code?
• How/where are our builds done?
• Do we have any coding conventions?
• Can I generate a Service template?

38. wget https://github.com/thirdchannel/base-template/
archive/release.zip
(This is not a real url, but you get the idea)

39. @svpember
Infrastructure
• How do we manage the logs?
• How about metrics / telemetry?
• How do we deploy our code?
• How/where are our builds done?
• Do we have any coding conventions?
• Can I generate a Service template?
• How do we share code?

40. Whoops! Gotcha!

42. @svpember
Sharing Code
• It’s OK to reimplement functionality within each service
• Setup your own internal Artifactory!
• DO share infrastructure libraries (e.g. communications)
• NEVER share Domain or business logic libraries

43. @svpember
Infrastructure
• How do we manage the logs?
• How about metrics / telemetry?
• How do we deploy our code?
• How/where are our builds done?
• Do we have any coding conventions?
• Can I generate a Service template?
• How do we share code?
• How do we manage our (multiple) environments?

44. @svpember

45. Test & Develop in Isolation

46. @svpember
Infrastructure
• How do we manage the logs?
• How about metrics / telemetry?
• How do we deploy our code?
• How/where are our builds done?
• Do we have any coding conventions?
• Can I generate a Service template?
• How do we share code?
• How do we manage our (multiple) environments?
• Do our Devs get time to work on Infrastructure?

47. @svpember
Microservice Topics
• Infrastructure
• Architecture

48. @svpember
Architecture
• Do we have an overall design vision?

49. Does Anyone Know What We’re Doing?!

52. @svpember
Architecture
• Do we have an overall design vision?
• What technologies do we use?
• How much freedom do we have in choosing new technologies?

53. @svpember

54. @svpember

55. Be Careful When Choosing
New Tech

56. @svpember
Architecture
• Do we have an overall design vision?
• What technologies do we use?
• How much freedom do we have in choosing new technologies?
• How do we test an individual service?

57. Integration Tests are the Best Tests

59. @svpember
Architecture
• Do we have an overall design vision?
• What technologies do we use?
• How much freedom do we have in choosing new technologies?
• How do we test an individual service?
• How do we test the platform as a whole?

60. @svpember
Test Environment
• Run periodically (e.g. nightly)
• Each service generates fixture data
• Service data reset after EACH test

61. Consider NOT testing platform
Instead, monitor error rates

62. @svpember

63. @svpember
Architecture
• Do we have an overall design vision?
• What technologies do we use?
• How much freedom do we have in choosing new technologies?
• How do we test an individual service?
• How do we test the platform as a whole?
• How do our services communicate?

64. HTTP vs Async Events

65. @svpember
HTTP
• Well Established
• Built In libraries
• Existing structure for response codes (2**, 4**, 5**, etc)
• Synchronous
• Increases coupling
• Requires services to know which others require their data
• Has dependency on Service Discovery mechanism
• Susceptible to Data Loss

66. @svpember
Events
• Asynchronous
• Pub-sub / Fire and forget
• Loose Coupling
• Prevents Data Loss
• Allows for Reactive systems
• No existing structure for response error handling
• Dependency on Message Broker technology
• Can be difficult for Junior folks to understand

67. Ensure you have Circuit Breaker or a Dead
Letter Mechanism

68. @svpember

69. @svpember
<3 RabbitMq
• Intelligent broker; dumb consumers
• Highly nuanced & robust routing
• Backpressure
• Dead letters /retries
• Message Ordering
• Multiple deliveries
• Ack / Nack/ Reject … re-enqueue

70. @svpember
Architecture
• Do we have an overall design vision?
• What technologies do we use?
• How much freedom do we have in choosing new technologies?
• How do we test an individual service?
• How do we test the platform as a whole?
• How do our services communicate?
• How/where is our data persisted?

71. @svpember
Locality of Reference
• Spatial: “How close together is our data?”

72. @svpember
Locality of Reference
• Spatial: “How close together is our data?”
• Temporal: “How often is our data accessed?”

73. @svpember

74. @svpember

75. @svpember
Architecture
• Do we have an overall design vision?
• What technologies do we use?
• How much freedom do we have in choosing new technologies?
• How do we test an individual service?
• How do we test the platform as a whole?
• How do our services communicate?
• How/where is our data persisted?
• Do we follow an overall architectural style?

76. Make Sure Everyone Is Aware

77. Applies to Both Intra- and Inter-Service

78. It all
Started
With =>

79. @svpember
Domain Driven Design
• Ubiquitous Language
• Entities
• Aggregates
• Bounded Contexts
• No Direct communications across Boundaries

80. @svpember

81. @svpember

82. … And CQRS

83. Allows for interesting
Architectures

84. MVC

85. CQRS

86. CQRS

88. While we’re at it, go Reactive

89. @svpember
Architecture
• Do we have an overall design vision?
• What technologies do we use?
• How much freedom do we have in choosing new technologies?
• How do we test an individual service?
• How do we test the platform as a whole?
• How do our services communicate?
• How/where is our data persisted?
• Do we follow an overall architectural style?
• When do we create new services?

90. DDD to the rescue

92. @svpember
New Service?
• Initially: design platform around Bounded Contexts, create services from
inner Contexts
• Don’t create services ‘just because’
• Do make an effort to identify boundaries
• Ensure a service has/will have proper context boundaries before creating
• If two services need to communicate synchronously or frequently, good
candidates for MERGING

93. # of services < # of developers

94. @svpember
Microservice Topics
• Infrastructure
• Architecture
• Team Communication

95. @svpember
Team Communication
• How are our teams structured?

96. Conway’s Law is REAL

97. –Johnny Appleseed
“Type a quote here.”
DBA
Engineers
QA
UX

98. @svpember

99. @svpember
Team Communication
• How are our teams structured?
• Who owns which Service?

100. Teams should be Owners

101. @svpember
Team Communication
• How are our teams structured?
• Who owns which Service?
• What’s our process for merging code?

103. @svpember
Team Communication
• How are our teams structured?
• Who owns which Service?
• What’s our process for merging code?
• What’s our process for releasing code?

104. @svpember

105. @svpember
Team Communication
• How are our teams structured?
• Who owns which Service?
• What’s our process for merging code?
• What’s our process for releasing code?
• What’s our process for monitoring code in production? Dealing with bugs?

106. @svpember

107. –Johnny Appleseed
“Type a quote here.”

108. @svpember
Team Communication
• How are our teams structured?
• Who owns which Service?
• What’s our process for merging code?
• What’s our process for releasing code?
• What’s our process for monitoring code in production? Dealing with bugs?
• Do we add more process if something goes wrong?

109. Be Reluctant to Add
New Process

110. High Freedom / High Responsibility

111. @svpember
Microservice Topics
• Infrastructure
• Architecture
• Team Communication
• Miscellaneous Advice

112. @svpember
Miscellaneous Advice
• Don’t get cute with the naming of services

113. Any idea
what these
do?

114. @svpember
Miscellaneous Advice
• Don’t get cute with the naming of services
• New Feature -> walk backwards from what the user will see

115. @svpember
Miscellaneous Advice
• Don’t get cute with the naming of services
• New Feature -> walk backwards from what the user will see
• Release when a feature is ready

116. @svpember
Miscellaneous Advice
• Don’t get cute with the naming of services
• New Feature -> walk backwards from what the user will see
• Release when a feature is ready
• If a service A has another service B as a dependency => release B first

117. @svpember
Miscellaneous Advice
• Don’t get cute with the naming of services
• New Feature -> walk backwards from what the user will see
• Release when a feature is ready
• If a service A has another service B as a dependency => release B first
• How to bootstrap a new service?

118. @svpember
Miscellaneous Advice
• Don’t get cute with the naming of services
• New Feature -> walk backwards from what the user will see
• Release when a feature is ready
• If a service A has another service B as a dependency => release B first
• How to bootstrap a new service?
• Don’t release Friday afternoons

119. In Summary

120. Most of the Challenge is In infrastructure

121. <3
Microservices

122. Please share your survival tips!

123. Any Questions?
Anything I missed?

124. Thank you!
@svpember

125. @svpember
Images
• Bad Odds (Jon Snow): https://www.reddit.com/r/gameofthrones/comments/4owm95/s6e9_megathread_gifwallpaperscreenshot_requests/
• Say Anything / John Cusak: http://www.glamour.com/story/happy-birthday-john-cusack-and
• Wilderness Survival Guide: https://www.kobo.com/us/en/ebook/the-wilderness-survival-guide-1
• XKCD: Code Review: https://xkcd.com/1513/
• Monolithic vs Microservices: @alvaro_sanchez
• Picard FacePalm: https://www.flickr.com/photos/30418788@N03/8381426895
• Council of Ricks: https://www.reddit.com/r/rickandmorty/comments/3exy00/it_looks_like_there_might_some_sort_of_council_of/
• Drago (break you): https://giphy.com/gifs/GWD5nSpiHxs3K
• Wrecking Ball: https://www.flickr.com/photos/rhysasplundh/5202454842/in/photostream/
• Rocky Stairs: http://pixgood.com/rocky-stairs.html
• Technical Difficulties: https://www.youtube.com/watch?v=EC15BmzsdhM
• Grafana example: https://i.imgur.com/KOqcD6L.png
• Zipkin example: https://blog.buoyant.io/2016/05/17/distributed-tracing-for-polyglot-microservices/
• Assembly Line: http://www.solidsmack.com/culture/humans-need-apply-new-short-film-explores-future-robots-manufacturing-automation/

126. @svpember
Links
• Eric Evans: DDD and Microservices: https://www.youtube.com/watch?
v=yPvef9R3k-M