Microservices session for Data Science Retreat Berlin (Day 1, Part 1)

1. Microservices
@Steve_Upton

2. Who am I?
● Steve Upton
● English / Welsh / British / Irish(?)
● BSc. Computer Science (Cardiff University)
● Physics & Astronomy (Open University)
● IBM (6 years)
○ Messaging
○ OASIS MQTT TC member
○ Working with clients on Microservice systems
○ London μService user group
● HERE Berlin (9 months)
○ Microservices
○ Robots!

3. Who are you?

4. The (2) histories of Microservices
Why you shouldn’t do Microservices
What Microservices actually look like
The future of Microservices

5. The (2) histories of
Microservices

6. The standard Microservices creation story

8. Monolith
HTTP
Data
Access
Component
Component
Component
Component
...
HTTP

9. Monolith
HTTP
Data
Access
Component
Component
Component
Component
...
HTTP

10. Monolith
HTTP
Data
Access
Component
Component
Component
Component
...
HTTP

11. Monolith
HTTP
Data
Access
Component
Component
Component
Component
...
HTTP

12. Tightly coupled, slow to change

13. Tightly coupled, slow to change
Sharing hardware

14. Tightly coupled, slow to change
Sharing hardware
Needs knowledge of other components (interfaces)

15. Tightly coupled, slow to change
Sharing hardware
Needs knowledge of other components (interfaces)
Difficult to upgrade without affecting other services

16. Tightly coupled, slow to change
Sharing hardware
Needs knowledge of other components (interfaces)
Difficult to upgrade without affecting other services
Sharing libraries, platform, OS etc.

17. Tightly coupled, slow to change
Sharing hardware
Needs knowledge of other components (interfaces)
Difficult to upgrade without affecting other services
Sharing libraries, platform, OS etc.
Teams have little choice in setup

18. Hard to scale

19. Hard to scale
RDBMS is a bottleneck

20. Hard to scale
RDBMS is a bottleneck
Vertical scaling easy, but limited

21. Hard to scale
RDBMS is a bottleneck
Vertical scaling easy, but limited
Horizontal scaling helpful, but slow and expensive

22. Hard to scale
RDBMS is a bottleneck
Vertical scaling easy, but limited
Horizontal scaling helpful, but slow and expensive
Scaling the whole monolith can be wasteful

23. Scaling the monolith
HTTP
Data
Access
Service
Service
Service
Service
Service
HTTP
Data
Access
Service
Service
Service
Service
Service
HTTP
Data
Access
Component
Component
Component
Component
...
HTTP
Loadbalancer

24. “...the average server operates at no more than
12 to 18 percent of its capacity”
Natural Resources Defense Council

27. ?

28. Service
Moving to the cloud
HTTP
Data
Access
Component
Component
Component
...
HTTP

29. Service
Service
Service
Service
Microservices
HTTP
HTTP

30. Resilience to failure
Able to isolate failures

31. Resilience to failure
Able to isolate failures
Gracefully adapt to failures

32. Resilience to failure
Able to isolate failures
Gracefully adapt to failures

33. Resilience to failure
Able to isolate failures
Gracefully adapt to failures
Quick recovery

34. Loosely coupled, easy to change
Share contracts, not interfaces and internals
Little to no knowledge of other services needed

35. Loosely coupled, easy to change
Share contracts, not interfaces and internals
Little to no knowledge of other services needed
Teams free to choose OS, language, libraries etc.
Free to upgrade and experiment

36. Loosely coupled, easy to change
Share contracts, not interfaces and internals
Little to no knowledge of other services needed
Teams free to choose OS, language, libraries etc.
Free to upgrade and experiment
No shared state

37. Easy to scale
Vertical scaling easy and more effective

38. Easy to scale
Vertical scaling easy and more effective
Horizontal scaling also easy!

39. Easy to scale
Vertical scaling easy and more effective
Horizontal scaling also easy!
More efficient use of resources

40. Easy to scale
Vertical scaling easy and more effective
Horizontal scaling also easy!
More efficient use of resources
Auto scaling of individual services possible

41. Auto scaling

42. Service
Service
Service
Service
Service
Auto scaling
Service
Load

43. “Cattle not pets”
Gavin McCance, CERN

44. “In short, the microservice architectural style is an approach to developing
a single application as a suite of small services, each running in its
own process and communicating with lightweight mechanisms, often an
HTTP resource API. These services are built around business
capabilities and independently deployable by fully automated
deployment machinery. There is a bare minimum of centralized
management of these services, which may be written in different
programming languages and use different data storage technologies.”
James Lewis and Martin Fowler, ThoughtWorks

45. “Loosely coupled service oriented
architecture with bounded contexts”
Adrian Cockcroft, Architect @ Netflix

47. https://netflix.github.io/
http://techblog.netflix.com/

48. Atlas

51. The other story

52. The other story
credit to Fred George

53. Project delivery cycles
1980 1990 2000 2010
Projectduration(log)
1 week
1 month
1 year
5 years

54. Project delivery cycles
1980 1990 2000 2010
Projectduration(log)
1 week
1 month
1 year
5 years Waterfall

55. Project delivery cycles
1980 1990 2000 2010
Projectduration(log)
1 week
1 month
1 year
5 years Waterfall
Waterfall + OO

56. Project delivery cycles
1980 1990 2000 2010
Projectduration(log)
1 week
1 month
1 year
5 years Waterfall
Waterfall + OO
Agile

57. Project delivery cycles
1980 1990 2000 2010
Projectduration(log)
1 week
1 month
1 year
5 years Waterfall
Waterfall + OO
Agile
Agile + Lean

58. Hardware lead times
1990 2000 2010 2015
Orderleadtime(log(ish))
< 1 sec
1 hour
1 week
6 months
5 secs

59. Hardware lead times
1990 2000 2010 2015
Orderleadtime(log(ish))
< 1 sec
1 hour
1 week
6 months Data center
5 secs

60. Hardware lead times
1990 2000 2010 2015
Orderleadtime(log(ish))
< 1 sec
1 hour
1 week
6 months Data center
Virtual machines
5 secs

61. Hardware lead times
1990 2000 2010 2015
Orderleadtime(log(ish))
< 1 sec
1 hour
1 week
6 months Data center
Virtual machines
Commercial
cloud (AWS)
5 secs
PaaS

62. Hardware lead times
1990 2000 2010 2015
Orderleadtime(log(ish))
< 1 sec
1 hour
1 week
6 months Data center
Virtual machines
Commercial
cloud (AWS)
Docker
FaaS
5 secs
PaaS

63. Project size
1990 2000 2010 2015
Projectsize(linesofcode)
1,000
10,000
100,000
1,000,000

64. Project size
1990 2000 2010 2015
Projectsize(linesofcode)
1,000
10,000
100,000
1,000,000 Java

65. Project size
1990 2000 2010 2015
Projectsize(linesofcode)
1,000
10,000
100,000
1,000,000 Java
Ruby

66. Project size
1990 2000 2010 2015
Projectsize(linesofcode)
1,000
10,000
100,000
1,000,000 Java
Ruby
Python

67. Project size
1990 2000 2010 2015
Projectsize(linesofcode)
1,000
10,000
100,000
1,000,000 Java
Ruby
Python
Node.js

68. Onboarding the new dev...
credit: https://twitter.com/moonpolysoft/status/781868129269919744

69. Story time

70. Marx on Microservices

71. Marx on Microservices
Economic and Philosophic Manuscripts of 1844

72. Marx on Microservices
Economic and Philosophic Manuscripts of 1844
Gattungswesen (species-being)
Workers feeling a connection to their work

73. Marx on Microservices
Economic and Philosophic Manuscripts of 1844
Gattungswesen (species-being)
Workers feeling a connection to their work
Entfremdung (alienation)
Workers feel estranged from their work

74. Products not Projects

75. “Any piece of software reflects the organizational
structure that produced it”
Conway's Law

76. Inverse Conway Maneuver?

77. What sort of organisation do you want to work in?

78. The other, other story

79. SOA

80. Service Oriented Architecture

81. Service Oriented Architecture
Boundaries are explicit

82. Service Oriented Architecture
Boundaries are explicit
Services are autonomous

83. Service Oriented Architecture
Boundaries are explicit
Services are autonomous
Services share schema and contract, not class

84. Service Oriented Architecture
Boundaries are explicit
Services are autonomous
Services share schema and contract, not class
Service compatibility is based on policy

85. IBM SOA Foundation

86. IBM SOA Foundation Reference Architecture

87. IBM SOA Foundation Reference Architecture logical model

88. IBM SOA Foundation Reference Architecture solution

89. Oracle SOA Foundation Reference Architecture (Product Mapping)

90. Oracle SOA Foundation Reference Architecture

91. “The latest shiny new technology will not make
things better… If you want spectacular gains,
then you need to make a spectacular
commitment to change.”
Anne Thomas Manes, SOA is Dead; Long Live Services

92. “... and that’s where we need to concentrate from
this point forward: Services”
Anne Thomas Manes, SOA is Dead; Long Live Services

93. Why you shouldn’t do
Microservices

94. CAP Theorem
Dr. Eric Brewer (2000)

95. CAP Theorem
Consistency
Availability
Partition tolerance

96. CAP Theorem
Consistency
(all requests return the correct results)
Availability
Partition tolerance

97. CAP Theorem
Consistency
(all requests return the correct results)
Availability
(all requests complete)
Partition tolerance

98. CAP Theorem
Consistency
(all requests return the correct results)
Availability
(all requests complete)
Partition tolerance
(the network may fail)

99. CAP Theorem
Consistency
(all requests return the correct results)
Availability
(all requests complete)
Partition tolerance
(the network may fail)
Pick 2

100. CAP Theorem - Example 1
[x]
Data store
User 1 User 2

101. CAP Theorem - Example 1
[x]
Data store
User 1 User 2
put(40)

102. CAP Theorem - Example 1
[40]
Data store
User 1 User 2

103. CAP Theorem - Example 1
[40]
Data store
User 1 User 2
get

104. CAP Theorem - Example 1
[40]
Data store
User 1 User 2
40

105. CAP Theorem - Example 1
[40]
Data store
User 1 User 2
40
✔ Consistent (correct)
✔ Available (answered)
❌ Partition tolerant (no network partitions)

106. CAP Theorem - Example 1
[40]
Data store
User 1 User 2
40
✔ Consistent (correct)
✔ Available (answered)
❌ Partition tolerant (no network partitions)
[PROBLEM] No real world system looks like this

107. CAP Theorem - Example 2
[40]
Data store (US)
User 1 User 2
[40]
Data store (EU)

108. CAP Theorem - Example 2
[40]
Data store (US)
User 1 User 2
put(60)
[40]
Data store (EU)

109. CAP Theorem - Example 2
[60]
Data store (US)
User 1 User 2
[40]
Data store (EU)

110. CAP Theorem - Example 2
[60]
Data store (US)
User 1 User 2
[40]
Data store (EU)

111. CAP Theorem - Example 2
[60]
Data store (US)
User 1 User 2
[40]
Data store (EU)
get
What now?

112. CAP Theorem - Example 2
[60]
Data store (US)
User 1
User 2
[40]
Data store (EU)
get ⟶ 40

113. CAP Theorem - Example 2
[60]
Data store (US)
User 1
User 2
[40]
Data store (EU)
get ⟶ 40
❌ Consistent (incorrect)
✔ Available (answered)
✔ Partition tolerant

114. CAP Theorem - Example 2
[60]
Data store (US)
User 1
User 2
[40]
Data store (EU)
get ⟶ 40
❌ Consistent (incorrect)
✔ Available (answered)
✔ Partition tolerant
User 2
wait

115. CAP Theorem - Example 2
[60]
Data store (US)
User 1
User 2
[40]
Data store (EU)
get ⟶ 40
❌ Consistent (incorrect)
✔ Available (answered)
✔ Partition tolerant
User 2
wait
✔ Consistent (correct)
❌ Available (not answered)
✔ Partition tolerant

117. Profile picture?

118. Profile picture?
Bank balance?

119. Profile picture?
Bank balance?
ATM withdrawal?

120. Profile picture?
Bank balance?
ATM withdrawal?
Football scores?

121. Profile picture?
Bank balance?
ATM withdrawal?
Football scores?
Parcel tracker?

122. Pick 2

123. Pick 2

124. Pick 2
Understand the tradeoffs

125. All distributed systems have to deal with CAP

126. All distributed systems have to deal with CAP
Microservices add CAP where it wasn’t before

127. The fallacies of distributed computing
The network is reliable
Latency is zero
Bandwidth is infinite
The network is secure
Topology doesn't change
There is one administrator
Transport cost is zero
The network is homogeneous

128. The network is reliable

129. The network is reliable

130. Infrastructure is attacked
The network is reliable

131. Infrastructure is attacked
The network is reliable

132. Infrastructure is attacked
Networks are attacked
The network is reliable

133. Infrastructure is attacked
Networks are attacked
Machines fail
The network is reliable

134. Infrastructure is attacked
Networks are attacked
Machines fail
The network is reliable

135. The latency is zero

136. The latency is zero

137. The latency is zero
US East to west (+~65ms)

138. The latency is zero
US East to west (+~65ms)
Atlantic crossing (+~90ms)
London to Auckland (+~270ms)

139. The latency is zero
US East to west (+~65ms)
Atlantic crossing (+~90ms)
London to Auckland (+~270ms)

140. The latency is zero
US East to west (+~65ms)
Atlantic crossing (+~90ms)
London to Auckland (+~270ms)
The case of the 500-mile email

141. Bandwidth is infinite

142. Bandwidth is infinite

143. Bandwidth is infinite

144. Bandwidth is infinite
VOIP, streaming video/audio...

145. Bandwidth is infinite
VOIP, streaming video/audio...
1000s of services sharing a line?

146. Bandwidth is infinite
VOIP, streaming video/audio...
1000s of services sharing a line?
Even T-1 lines get saturated

147. Bandwidth is infinite
VOIP, streaming video/audio...
1000s of services sharing a line?
Even T-1 lines get saturated
Bottlenecks?

148. The network is secure

149. The network is secure

150. The network is secure
Heartbleed?

151. The network is secure
Heartbleed?
DynDNS?
“In a relatively short time we've taken a
system built to resist destruction by nuclear
weapons and made it vulnerable to toasters.”
Jeff Jarmoc

152. The network is secure
Heartbleed?
DynDNS?
Network border isn’t good enough
“In a relatively short time we've taken a
system built to resist destruction by nuclear
weapons and made it vulnerable to toasters.”
Jeff Jarmoc

153. The network is secure
Heartbleed?
DynDNS?
Network border isn’t good enough

154. Topology doesn't change

155. Topology doesn't change

156. Topology doesn't change
Topology is dynamic!

157. Topology doesn't change
Topology is dynamic! (Cattle not pets)

158. Topology doesn't change
Topology is dynamic! (Cattle not pets)
Can’t rely on specific endpoints...

159. Topology doesn't change
Topology is dynamic! (Cattle not pets)
Can’t rely on specific endpoints...
...or performance, routing etc.

160. Topology doesn't change
Topology is dynamic! (Cattle not pets)
Can’t rely on specific endpoints...
...or performance, routing etc.
Bits a network can be unreachable

161. There is one administrator

162. There is one administrator

163. There is one administrator
Who grants access to database?

164. There is one administrator
Who grants access to database?
...and to another service?

165. There is one administrator
Who grants access to database?
...and to another service?

166. There is one administrator
Who grants access to database?
...and to another service?
Who do you complain to?

167. There is one administrator
Who grants access to database?
...and to another service?
Who do you complain to?
Coordinated updates?

168. Transport cost is zero

169. Transport cost is zero

170. Transport cost is zero
Literally not free

171. Transport cost is zero
Literally not free
Who’s paying?

172. Transport cost is zero
Literally not free
Who’s paying?
Marshalling isn’t free either

173. The network is homogeneous

174. The network is homogeneous

175. My pockets aren’t homogeneous!
The network is homogeneous

176. The network is homogeneous
My pockets aren’t homogeneous!
Can’t assume you’re talking to UNIX etc.

177. The network is homogeneous
My pockets aren’t homogeneous!
Can’t assume you’re talking to UNIX etc.
Can’t assume character encodings

178. The network is homogeneous
My pockets aren’t homogeneous!
Can’t assume you’re talking to UNIX etc.
Can’t assume character encodings
Have to agree on exchange formats

179. The fallacies of distributed computing
The network is reliable
Latency is zero
Bandwidth is infinite
The network is secure
Topology doesn't change
There is one administrator
Transport cost is zero
The network is homogeneous

181. Aaron Cohen

182. Aaron Cohen
NASA