Originally delivered at the Microservices Exchange in Berlin. “Circuit Breakers, Stranglers, Metrics, Stressors, Simian Armies, small (but not too small) services, integration styles, composite UIs, API design, API documentation, API evolution, Reactive Streams, Events, Event Sourcing, Logging, Automated deployment, blue/green switchover, flexible infrastructure, bulkheads, PaaS, Cloud, DevOps Culture, Antifragility …” the list really does go on! Whoever said adopting microservices was easy never saw the sheer list of things to be considered! But the benefits are worth it… Microservices offer an architectural style that is flexible enough to become the de-facto approach for future enterprise software systems, but the individual journeys, and pitfalls vary dramatically from context to context. This slide-set shares several real-world technical journeys, the tradeoffs that have been made, the tools that had to be invented and, finally, how to adopt your own effective “Microservices UX”, the best and most effective user experience for those having to plan, architect, develop, deploy and maintain microservices within their own systems.

1. The Technical Journey
to Microservices
@russmiles

3. Biker me… TBD

7. Reactive…
Say “Microservices” one more time…

8. TBD

10. A Definition…

11. The kingdom of heaven is like a mustard seed, which
a man took and planted in his field.Though it is the
smallest of all seeds, yet when it grows, it is the largest
of garden plants and becomes a tree, so that the birds
come and perch in its branches (Matthew 13:31-32).
- Of Mustard Seeds and Microservices (Micah
Blalock) -- https://www.credera.com/blog/technology-
insights/java/mustard-seeds-microservices/

12. “Loosely coupled service oriented
architecture with bounded contexts”

13. Loosely Coupled
Services that
can change

14. A Story

17. “The Elephant in the
Standup”

18. The term isWRONG

19. Size
doesn’t matter

20. SLOC doesn’t matter

21. Cognitive Overhead
DOES

22. What can your System
DO?

23. Single Biggest Limiting
Factor on Change?

24. You.

25. Comprehension

26. Not the things…

27. … the things that
happen

28. Systemic Properties

29. Not what you have

30. What you can
do
with it

31. The Big Challenge

32. Some value Stability

33. Some value Speed

34. Some value Agility

35. Some value Adaptability

36. Some value Volatility

37. Some value Antifragility

38. Microservices (can) =
Speed
Adaptability
Antifragility

39. How?

40. How?

41. Life Preservation

42. Events.

43. How?

44. How?

46. Volume
Variety
Velocity

47. Volume
Variety
Velocity
Veracity

48. Aggregates

49. Views

54. Downside?

55. One more story…

56. Build an app…

57. The Todo list,
for a Todo App

58. “Create a beautiful
looking app & web ui
for interacting with
todo lists”

59. “Write a back-end
service that stores todo
lists so that they can be
made available across
devices and the web.”

60. “Write your todo-list
tests to ensure things
function as you expect"

62. But…

63. According to slide-
theorists…

64. But that’s waaaay
too easy…

65. 40 slides in 2 minutes…

66. Ready…?

67. Set up source code
control and an issue
tracker

68. Manage user accounts,
sign-up, sign-in, and
password management

69. Collect analytics from
your app and web ui
about how people use
your app

70. Build and test your app
across multiple devices
and OS versions

71. Gather information on
app crashes and bugs
and feed this back into
an issue backlog

72. Test your web ui across
multiple browsers and
versions

73. Document the API that
the native apps and web
app depend on

74. Push client-side assets to
CDNs and keep them up
to date

75. Version your API so that
you can evolve client
apps and the backing
service independently

76. Implement rate limiting
for requests

77. Set up a CI service that
monitors your repository
for changes builds and
tests your software

78. Set up a CD service that
deploys new version of
your software to your
chosen deployment
platform

79. Set up networking rules
so that the components
of your backend can see
each other and are
protected from other
traffic

80. Enable the components
of your backend service
(e.g. the API
implementation and
database) to find each
other

81. Ensure the service can
survive failure of an AZ

82. Monitor request latency

83. Create new instances if
existing ones fail, and
transparently reconnect
service components

84. Provide mechanisms to
scale up and down
service capacity

85. Trace requests all the way
through the system

86. Provide audit logs of all
changes made to
production systems

87. Set up an alerting
mechanism for problems
in production

88. Put in place a DR
solution and test it

89. Back up and recovery
processes for data

90. Create operational play
books and test your plays

91. Put in place automated
failure testing
(e.g. simians)

92. Ensure service has no
security weaknesses
(e.g. XSS)

93. Monitor CVE reports for
all components in your
stack and replace as
soon as a vulnerability is
found

94. Devise deployment
schemes for e.g. blue/
green, phased rollout, and
rollback

95. Collect logs from all
components for analysis

96. Enable marketing to run
A/B and feature tests

97. Monitor and visualise all
of the above and ensure
that things continue to
flow smoothly through the
pipeline

98. Package all of your
application components
in a form suitable for
deployment

99. Manage stand up and
tear down of dev and test
environments

100. …

101. …breathe…

102. …

103. And that’s before we get
to…

104. Service Configuration

105. Service Discovery

106. Bulkheads

107. Circuit Breakers

108. Event Stores

109. Messaging

110. CQRS

111. Language Selection

112. APIs

113. API Gateways

114. Lakes

115. Routing

116. Security

117. …

118. BREATHE!!!

119. …

120. And this is JUST the
Technical Journey!

121. WT*?!

124. The real problem?

125. The general problem…

127. d

128. do

129. bdo

130. S

131. Complexity
of
Microservices

133. We can do better

134. We can do much better

135. We have done this
before…

138. Simplify Enterprise Java

139. Simplify Microservices

140. What can you do?

141. www.leanpub.com/antifragilesoftware

142. Get Involved!

143. Thanks for your time!
@russmiles
russmiles.com