The document provides an overview of microservices from Steve Upton. It discusses two histories of microservices - the standard creation story involving moving from a monolithic architecture to independent microservices, and an alternative story noting how microservices evolved from trends in agile development, cloud computing, and reducing hardware costs. The document also addresses criticisms of microservices regarding the CAP theorem and tradeoffs around consistency, availability and partition tolerance. It describes what microservices architectures typically look like with practices like continuous delivery and containerization. Finally, it considers the future of microservices.

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 (6 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
DBHTTP
Data
Access
Component
Component
Component
Component
...
HTTP

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

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

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

12. Tightly coupled, slow to change
Sharing hardware

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

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

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

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

17. Hard to scale
Vertical scaling easy, but ineffective

18. Hard to scale
Vertical scaling easy, but ineffective
Horizontal scaling helpful, but slow and expensive

19. Hard to scale
Vertical scaling easy, but ineffective
Horizontal scaling helpful, but slow and expensive
Scaling the whole monolith can be wasteful

20. Scaling the monolith
DBHTTP
Data
Access
Service
Service
Service
Service
Service
HTTP
Data
Access
Service
Service
Service
Service
Service
HTTP
Data
Access
Component
Component
Component
Component
...
HTTP
Loadbalancer

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

24. ?

25. Moving to the cloud
DBHTTP
Data
Access
Component
Component
Component
...
HTTP
Service DB

26. Microservices
HTTP
HTTP
Service DB
Service DB
Service DB
Service DB

27. Resilience to failure
Able to isolate failures

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

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

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

31. Loosely coupled, easy to change
Teams free to choose OS, language, libraries etc.

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

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

34. Easy to scale
Vertical scaling easy and more effective

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

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

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

38. Auto scaling

39. Service
Service
Service
Service
Service
Auto scaling
Service
Load

40. “Cattle not pets”
Gavin McCance, CERN

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

42. “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

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

45. Atlas

46. The other story

47. The other story
credit to Fred George

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

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

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

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

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

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

54. 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

55. 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

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

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

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

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

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

61. Story time

62. Marx on Microservices

63. Marx on Microservices
Economic and Philosophic Manuscripts of 1844

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

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

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

67. Inverse Conway Maneuver?

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

69. Why you shouldn’t do
Microservices

70. CAP Theorem
Dr. Eric Brewer (2000)

71. CAP Theorem
Consistency
Availability
Partition tolerance

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

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

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

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

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

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

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

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

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

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

82. 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

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

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

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

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

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

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

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

90. 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

91. 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

93. Profile picture?

94. Profile picture?
Bank balance?

95. Profile picture?
Bank balance?
Real time chat?

96. Profile picture?
Bank balance?
Real time chat?
Football scores?

97. Profile picture?
Bank balance?
Real time chat?
Football scores?
Parcel tracker?

98. Pick 2

99. Pick 2

100. Pick 2
Understand the tradeoffs

101. All distributed systems have to deal with CAP

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

103. What Microservices
actually look like

104. Continuous Delivery

105. “If you have more meetings than releases, you’re
an enterprise company”
Clifton Cunningham, CTO @ TES Global

106. Containers

107. Containers
credit to Anne Currie

108. Bare Metal

109. Bare Metal
✔ Powerful
✔ Simple

110. Bare Metal
✔ Powerful
✔ Simple
❌ Brittle
❌ Inflexible

111. Bare Metal
✔ Powerful
✔ Simple
❌ Brittle
❌ Inflexible

112. Virtual Machines

113. Virtual Machines
✔ Flexible
✔ Networking
✔ Security

114. Virtual Machines
✔ Flexible
✔ Networking
✔ Security
❌ Overweight

115. Virtual Machines
✔ Flexible
✔ Networking
✔ Security
❌ Overweight

116. Virtual Machines
✔ Flexible
✔ Networking
✔ Security
❌ Overweight

117. Containers

118. Containers
✔ Lightweight
✔ Agile

119. Containers
✔ Lightweight
✔ Agile
❌ Untested
❌ Networking
❌ Security

120. Containers
✔ Lightweight
✔ Agile
❌ Untested
❌ Networking
❌ Security

121. Containers
✔ Lightweight
✔ Agile
❌ Untested
❌ Networking
❌ Security

123. Exercise

124. Configuration Management

128. Inter-service communication

129. Build Test
HTTP

130. Build Test
Email

131. Build Test
Email
Slack

132. Build Test
Email
Slack
Fireworks

133. Build Test
Email
Slack
Fireworks

134. Build Test
Email
Slack
Fireworks

136. “Service Discovery
is an anti-pattern”

137. “Service Discovery
is an anti-pattern”
Richard Rodger, CTO @ nearForm

138. MQ Light
Messaging!

139. Build Test
Email
Slack
Fireworks
RabbitMQ

140. Build Test
publish
Email
Slack
Fireworks
RabbitMQ

141. Build Test
publish
Email
Slack
Fireworks
RabbitMQ
subscribe

142. “Publish everything!”
Tim Livesey, Droplet

144. Exercise

146. Lots of data sources

147. Lots of data sources
Lots of data consumers

148. Lots of data sources
Lots of data consumers
Lots of integrations

149. LinkedIn before

150. LinkedIn after

151. Up close

152. The log
Append only
Time ordered

153. Distributed logging

155. add(20)
add(5)
subtract(10)
add(15)

156. add(20)
add(5)
subtract(10)
add(15)

157. add(20)
add(5)
subtract(10)
add(15)

158. ?
add(20)
add(5)
subtract(10)
add(15)

159. “If two identical, deterministic processes begin in
the same state and get the same inputs in the
same order, they will produce the same output and
end in the same state.”
State Machine Replication Principle, Jay Kreps, LinkedIn

160. 30
add(20)
add(5)
subtract(10)
add(15)
?

161. Log as source of Truth

162. Event Sourcing

163. “We don’t care if our production system crashes.”
Valerii Vasylkov, William Hill

164. Testing Microservices

168. Chaos Gorilla

169. Security Monkey

170. Janitor Monkey

171. Latency Monkey

172. Monitoring = Testing

174. “How big should my Microservice be?”
Everyone

175. “The first draft of anything is shit”
Ernest Hemingway

176. Monolith first?

177. The future of
Microservices

179. 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

180. 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

181. Amazon Lambda
Serverless
‘Serverless’ (not really)
Function as a Service (FaaS)
No persistence, no upkeep costs
200 ms startup time (Node.js)

182. What is the role of a manager?

183. Managers
Provide guidance
Keep things ‘safe’
Organise the team

184. Managers Microservices
Provide guidance
Keep things ‘safe’
Organise the team
Explore new tech
Experiment
Enables self-organisation

186. “Microservices are hard. Some things you get for
free, but you have to work for the good stuff. If
you won’t put in the work, you shouldn’t be doing
Microservices. (You should be doing that stuff
anyway!)”
Steve Upton

187. “Microservices are hard. Some things you get for
free, but you have to work for the good stuff. If
you won’t put in the work, you shouldn’t be doing
Microservices. (You should be doing that stuff
anyway!)”
Steve Upton

188. “Microservices are hard. Some things you get for
free, but you have to work for the good stuff. If
you won’t put in the work, you shouldn’t be doing
Microservices. (You should be doing that stuff
anyway!)”
Steve Upton

189. “Microservices are hard. Some things you get for
free, but you have to work for the good stuff. If
you won’t put in the work, you shouldn’t be doing
Microservices. (You should be doing that stuff
anyway!)”
Steve Upton

190. “Microservices are hard. Some things you get for
free, but you have to work for the good stuff. If
you won’t put in the work, you shouldn’t be doing
Microservices. (You should be doing that stuff
anyway!)”
Steve Upton

191. “Microservices are hard. Some things you get for
free, but you have to work for the good stuff. If
you won’t put in the work, you shouldn’t be doing
Microservices. (You should be doing that stuff
anyway!)”
Steve Upton

192. Questions?
@Steve_Upton
steveupton.io

193. Essential reading
https://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed
https://plus.google.com/+RipRowan/posts/eVeouesvaVX
https://engineering.linkedin.com/distributed-systems/log-what-every-software-engi
neer-should-know-about-real-time-datas-unifying
http://martinfowler.com/articles/microservices.html
http://jonasboner.com/bla-bla-microservices-bla-bla/

194. References
http://www.slideshare.net/BruceWong3/the-case-for-chaos
http://www.slideshare.net/fredgeorge
http://www.slideshare.net/dataloop/anne-currie-force12io-game-of-hosts-containers-vs-vms
https://www.nrdc.org/sites/default/files/data-center-efficiency-assessment-IB.pdf
https://martinjeeblog.com/2012/11/20/what-is-programmer-anarchy-and-does-it-have-a-future/

195. Image credits
http://fontawesome.io/
https://github.com/thepracticaldev/orly-full-res
http://dimaip.github.io/slides/docker101.html
http://www.clipartlord.com/category/military-clip-art/bomb-clip-art/explosion-clip-art/

196. Extra material

197. Blue-Green deployment

198. User
Router
V1.0
V1.0

199. User
Router
V1.0
V1.1

200. User
Router
V1.0
V1.1

201. User
Router
V1.0
V1.1

202. User
Router
V1.0
V1.1

203. Possible with monoliths, just much harder!