Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Microservices
@Steve_Upton
Who am I?
● Steve Upton
● English / Welsh / British / Irish(?)
● BSc. Computer Science (Cardiff University)
● Physics & As...
Who are you?
The (2) histories of Microservices
Why you shouldn’t do Microservices
What Microservices actually look like
The future of ...
The (2) histories of
Microservices
The standard Microservices creation story
Monolith
HTTP
Data
Access
Component
Component
Component
Component
...
HTTP
Monolith
HTTP
Data
Access
Component
Component
Component
Component
...
HTTP
Monolith
HTTP
Data
Access
Component
Component
Component
Component
...
HTTP
Monolith
HTTP
Data
Access
Component
Component
Component
Component
...
HTTP
Tightly coupled, slow to change
Tightly coupled, slow to change
Sharing hardware
Tightly coupled, slow to change
Sharing hardware
Needs knowledge of other components (interfaces)
Tightly coupled, slow to change
Sharing hardware
Needs knowledge of other components (interfaces)
Difficult to upgrade wit...
Tightly coupled, slow to change
Sharing hardware
Needs knowledge of other components (interfaces)
Difficult to upgrade wit...
Tightly coupled, slow to change
Sharing hardware
Needs knowledge of other components (interfaces)
Difficult to upgrade wit...
Hard to scale
Hard to scale
RDBMS is a bottleneck
Hard to scale
RDBMS is a bottleneck
Vertical scaling easy, but limited
Hard to scale
RDBMS is a bottleneck
Vertical scaling easy, but limited
Horizontal scaling helpful, but slow and expensive
Hard to scale
RDBMS is a bottleneck
Vertical scaling easy, but limited
Horizontal scaling helpful, but slow and expensive
...
Scaling the monolith
HTTP
Data
Access
Service
Service
Service
Service
Service
HTTP
Data
Access
Service
Service
Service
Ser...
“...the average server operates at no more than
12 to 18 percent of its capacity”
Natural Resources Defense Council
?
Service
Moving to the cloud
HTTP
Data
Access
Component
Component
Component
...
HTTP
Service
Service
Service
Service
Microservices
HTTP
HTTP
Resilience to failure
Able to isolate failures
Resilience to failure
Able to isolate failures
Gracefully adapt to failures
Resilience to failure
Able to isolate failures
Gracefully adapt to failures
Resilience to failure
Able to isolate failures
Gracefully adapt to failures
Quick recovery
Loosely coupled, easy to change
Share contracts, not interfaces and internals
Little to no knowledge of other services nee...
Loosely coupled, easy to change
Share contracts, not interfaces and internals
Little to no knowledge of other services nee...
Loosely coupled, easy to change
Share contracts, not interfaces and internals
Little to no knowledge of other services nee...
Easy to scale
Vertical scaling easy and more effective
Easy to scale
Vertical scaling easy and more effective
Horizontal scaling also easy!
Easy to scale
Vertical scaling easy and more effective
Horizontal scaling also easy!
More efficient use of resources
Easy to scale
Vertical scaling easy and more effective
Horizontal scaling also easy!
More efficient use of resources
Auto ...
Auto scaling
Service
Service
Service
Service
Service
Auto scaling
Service
Load
“Cattle not pets”
Gavin McCance, CERN
“In short, the microservice architectural style is an approach to developing
a single application as a suite of small serv...
“Loosely coupled service oriented
architecture with bounded contexts”
Adrian Cockcroft, Architect @ Netflix
https://netflix.github.io/
http://techblog.netflix.com/
Atlas
The other story
The other story
credit to Fred George
Project delivery cycles
1980 1990 2000 2010
Projectduration(log)
1 week
1 month
1 year
5 years
Project delivery cycles
1980 1990 2000 2010
Projectduration(log)
1 week
1 month
1 year
5 years Waterfall
Project delivery cycles
1980 1990 2000 2010
Projectduration(log)
1 week
1 month
1 year
5 years Waterfall
Waterfall + OO
Project delivery cycles
1980 1990 2000 2010
Projectduration(log)
1 week
1 month
1 year
5 years Waterfall
Waterfall + OO
Ag...
Project delivery cycles
1980 1990 2000 2010
Projectduration(log)
1 week
1 month
1 year
5 years Waterfall
Waterfall + OO
Ag...
Hardware lead times
1990 2000 2010 2015
Orderleadtime(log(ish))
< 1 sec
1 hour
1 week
6 months
5 secs
Hardware lead times
1990 2000 2010 2015
Orderleadtime(log(ish))
< 1 sec
1 hour
1 week
6 months Data center
5 secs
Hardware lead times
1990 2000 2010 2015
Orderleadtime(log(ish))
< 1 sec
1 hour
1 week
6 months Data center
Virtual machine...
Hardware lead times
1990 2000 2010 2015
Orderleadtime(log(ish))
< 1 sec
1 hour
1 week
6 months Data center
Virtual machine...
Hardware lead times
1990 2000 2010 2015
Orderleadtime(log(ish))
< 1 sec
1 hour
1 week
6 months Data center
Virtual machine...
Project size
1990 2000 2010 2015
Projectsize(linesofcode)
1,000
10,000
100,000
1,000,000
Project size
1990 2000 2010 2015
Projectsize(linesofcode)
1,000
10,000
100,000
1,000,000 Java
Project size
1990 2000 2010 2015
Projectsize(linesofcode)
1,000
10,000
100,000
1,000,000 Java
Ruby
Project size
1990 2000 2010 2015
Projectsize(linesofcode)
1,000
10,000
100,000
1,000,000 Java
Ruby
Python
Project size
1990 2000 2010 2015
Projectsize(linesofcode)
1,000
10,000
100,000
1,000,000 Java
Ruby
Python
Node.js
Onboarding the new dev...
credit: https://twitter.com/moonpolysoft/status/781868129269919744
Story time
Marx on Microservices
Marx on Microservices
Economic and Philosophic Manuscripts of 1844
Marx on Microservices
Economic and Philosophic Manuscripts of 1844
Gattungswesen (species-being)
Workers feeling a connect...
Marx on Microservices
Economic and Philosophic Manuscripts of 1844
Gattungswesen (species-being)
Workers feeling a connect...
Products not Projects
“Any piece of software reflects the organizational
structure that produced it”
Conway's Law
Inverse Conway Maneuver?
What sort of organisation do you want to work in?
The other, other story
SOA
Service Oriented Architecture
Service Oriented Architecture
Boundaries are explicit
Service Oriented Architecture
Boundaries are explicit
Services are autonomous
Service Oriented Architecture
Boundaries are explicit
Services are autonomous
Services share schema and contract, not class
Service Oriented Architecture
Boundaries are explicit
Services are autonomous
Services share schema and contract, not clas...
IBM SOA Foundation
IBM SOA Foundation Reference Architecture
IBM SOA Foundation Reference Architecture logical model
IBM SOA Foundation Reference Architecture solution
Oracle SOA Foundation Reference Architecture (Product Mapping)
Oracle SOA Foundation Reference Architecture
“The latest shiny new technology will not make
things better… If you want spectacular gains,
then you need to make a spect...
“... and that’s where we need to concentrate from
this point forward: Services”
Anne Thomas Manes, SOA is Dead; Long Live ...
Why you shouldn’t do
Microservices
CAP Theorem
Dr. Eric Brewer (2000)
CAP Theorem
Consistency
Availability
Partition tolerance
CAP Theorem
Consistency
(all requests return the correct results)
Availability
Partition tolerance
CAP Theorem
Consistency
(all requests return the correct results)
Availability
(all requests complete)
Partition tolerance
CAP Theorem
Consistency
(all requests return the correct results)
Availability
(all requests complete)
Partition tolerance...
CAP Theorem
Consistency
(all requests return the correct results)
Availability
(all requests complete)
Partition tolerance...
CAP Theorem - Example 1
[x]
Data store
User 1 User 2
CAP Theorem - Example 1
[x]
Data store
User 1 User 2
put(40)
CAP Theorem - Example 1
[40]
Data store
User 1 User 2
CAP Theorem - Example 1
[40]
Data store
User 1 User 2
get
CAP Theorem - Example 1
[40]
Data store
User 1 User 2
40
CAP Theorem - Example 1
[40]
Data store
User 1 User 2
40
✔ Consistent (correct)
✔ Available (answered)
❌ Partition toleran...
CAP Theorem - Example 1
[40]
Data store
User 1 User 2
40
✔ Consistent (correct)
✔ Available (answered)
❌ Partition toleran...
CAP Theorem - Example 2
[40]
Data store (US)
User 1 User 2
[40]
Data store (EU)
CAP Theorem - Example 2
[40]
Data store (US)
User 1 User 2
put(60)
[40]
Data store (EU)
CAP Theorem - Example 2
[60]
Data store (US)
User 1 User 2
[40]
Data store (EU)
CAP Theorem - Example 2
[60]
Data store (US)
User 1 User 2
[40]
Data store (EU)
CAP Theorem - Example 2
[60]
Data store (US)
User 1 User 2
[40]
Data store (EU)
get
What now?
CAP Theorem - Example 2
[60]
Data store (US)
User 1
User 2
[40]
Data store (EU)
get ⟶ 40
CAP Theorem - Example 2
[60]
Data store (US)
User 1
User 2
[40]
Data store (EU)
get ⟶ 40
❌ Consistent (incorrect)
✔ Availa...
CAP Theorem - Example 2
[60]
Data store (US)
User 1
User 2
[40]
Data store (EU)
get ⟶ 40
❌ Consistent (incorrect)
✔ Availa...
CAP Theorem - Example 2
[60]
Data store (US)
User 1
User 2
[40]
Data store (EU)
get ⟶ 40
❌ Consistent (incorrect)
✔ Availa...
Profile picture?
Profile picture?
Bank balance?
Profile picture?
Bank balance?
ATM withdrawal?
Profile picture?
Bank balance?
ATM withdrawal?
Football scores?
Profile picture?
Bank balance?
ATM withdrawal?
Football scores?
Parcel tracker?
Pick 2
Pick 2
Pick 2
Understand the tradeoffs
All distributed systems have to deal with CAP
All distributed systems have to deal with CAP
Microservices add CAP where it wasn’t before
The fallacies of distributed computing
The network is reliable
Latency is zero
Bandwidth is infinite
The network is secure...
The network is reliable
The network is reliable
Infrastructure is attacked
The network is reliable
Infrastructure is attacked
The network is reliable
Infrastructure is attacked
Networks are attacked
The network is reliable
Infrastructure is attacked
Networks are attacked
Machines fail
The network is reliable
Infrastructure is attacked
Networks are attacked
Machines fail
The network is reliable
The latency is zero
The latency is zero
The latency is zero
US East to west (+~65ms)
The latency is zero
US East to west (+~65ms)
Atlantic crossing (+~90ms)
London to Auckland (+~270ms)
The latency is zero
US East to west (+~65ms)
Atlantic crossing (+~90ms)
London to Auckland (+~270ms)
The latency is zero
US East to west (+~65ms)
Atlantic crossing (+~90ms)
London to Auckland (+~270ms)
The case of the 500-m...
Bandwidth is infinite
Bandwidth is infinite
Bandwidth is infinite
Bandwidth is infinite
VOIP, streaming video/audio...
Bandwidth is infinite
VOIP, streaming video/audio...
1000s of services sharing a line?
Bandwidth is infinite
VOIP, streaming video/audio...
1000s of services sharing a line?
Even T-1 lines get saturated
Bandwidth is infinite
VOIP, streaming video/audio...
1000s of services sharing a line?
Even T-1 lines get saturated
Bottle...
The network is secure
The network is secure
The network is secure
Heartbleed?
The network is secure
Heartbleed?
DynDNS?
“In a relatively short time we've taken a
system built to resist destruction by ...
The network is secure
Heartbleed?
DynDNS?
Network border isn’t good enough
“In a relatively short time we've taken a
syste...
The network is secure
Heartbleed?
DynDNS?
Network border isn’t good enough
Topology doesn't change
Topology doesn't change
Topology doesn't change
Topology is dynamic!
Topology doesn't change
Topology is dynamic! (Cattle not pets)
Topology doesn't change
Topology is dynamic! (Cattle not pets)
Can’t rely on specific endpoints...
Topology doesn't change
Topology is dynamic! (Cattle not pets)
Can’t rely on specific endpoints...
...or performance, rout...
Topology doesn't change
Topology is dynamic! (Cattle not pets)
Can’t rely on specific endpoints...
...or performance, rout...
There is one administrator
There is one administrator
There is one administrator
Who grants access to database?
There is one administrator
Who grants access to database?
...and to another service?
There is one administrator
Who grants access to database?
...and to another service?
There is one administrator
Who grants access to database?
...and to another service?
Who do you complain to?
There is one administrator
Who grants access to database?
...and to another service?
Who do you complain to?
Coordinated u...
Transport cost is zero
Transport cost is zero
Transport cost is zero
Literally not free
Transport cost is zero
Literally not free
Who’s paying?
Transport cost is zero
Literally not free
Who’s paying?
Marshalling isn’t free either
The network is homogeneous
The network is homogeneous
My pockets aren’t homogeneous!
The network is homogeneous
The network is homogeneous
My pockets aren’t homogeneous!
Can’t assume you’re talking to UNIX etc.
The network is homogeneous
My pockets aren’t homogeneous!
Can’t assume you’re talking to UNIX etc.
Can’t assume character ...
The network is homogeneous
My pockets aren’t homogeneous!
Can’t assume you’re talking to UNIX etc.
Can’t assume character ...
The fallacies of distributed computing
The network is reliable
Latency is zero
Bandwidth is infinite
The network is secure...
Aaron Cohen
Aaron Cohen
NASA
DSR Microservices (Day 1, Part 1)
DSR Microservices (Day 1, Part 1)
DSR Microservices (Day 1, Part 1)
DSR Microservices (Day 1, Part 1)
DSR Microservices (Day 1, Part 1)
DSR Microservices (Day 1, Part 1)
DSR Microservices (Day 1, Part 1)
DSR Microservices (Day 1, Part 1)
DSR Microservices (Day 1, Part 1)
DSR Microservices (Day 1, Part 1)
DSR Microservices (Day 1, Part 1)
DSR Microservices (Day 1, Part 1)
DSR Microservices (Day 1, Part 1)
DSR Microservices (Day 1, Part 1)
DSR Microservices (Day 1, Part 1)
DSR Microservices (Day 1, Part 1)
DSR Microservices (Day 1, Part 1)
DSR Microservices (Day 1, Part 1)
Upcoming SlideShare
Loading in …5
×

DSR Microservices (Day 1, Part 1)

427 views

Published on

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

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

DSR Microservices (Day 1, Part 1)

  1. 1. Microservices @Steve_Upton
  2. 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. 3. Who are you?
  4. 4. The (2) histories of Microservices Why you shouldn’t do Microservices What Microservices actually look like The future of Microservices
  5. 5. The (2) histories of Microservices
  6. 6. The standard Microservices creation story
  7. 7. Monolith HTTP Data Access Component Component Component Component ... HTTP
  8. 8. Monolith HTTP Data Access Component Component Component Component ... HTTP
  9. 9. Monolith HTTP Data Access Component Component Component Component ... HTTP
  10. 10. Monolith HTTP Data Access Component Component Component Component ... HTTP
  11. 11. Tightly coupled, slow to change
  12. 12. Tightly coupled, slow to change Sharing hardware
  13. 13. Tightly coupled, slow to change Sharing hardware Needs knowledge of other components (interfaces)
  14. 14. Tightly coupled, slow to change Sharing hardware Needs knowledge of other components (interfaces) Difficult to upgrade without affecting other services
  15. 15. 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.
  16. 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. Teams have little choice in setup
  17. 17. Hard to scale
  18. 18. Hard to scale RDBMS is a bottleneck
  19. 19. Hard to scale RDBMS is a bottleneck Vertical scaling easy, but limited
  20. 20. Hard to scale RDBMS is a bottleneck Vertical scaling easy, but limited Horizontal scaling helpful, but slow and expensive
  21. 21. 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
  22. 22. 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
  23. 23. “...the average server operates at no more than 12 to 18 percent of its capacity” Natural Resources Defense Council
  24. 24. ?
  25. 25. Service Moving to the cloud HTTP Data Access Component Component Component ... HTTP
  26. 26. Service Service Service Service Microservices HTTP HTTP
  27. 27. Resilience to failure Able to isolate failures
  28. 28. Resilience to failure Able to isolate failures Gracefully adapt to failures
  29. 29. Resilience to failure Able to isolate failures Gracefully adapt to failures
  30. 30. Resilience to failure Able to isolate failures Gracefully adapt to failures Quick recovery
  31. 31. Loosely coupled, easy to change Share contracts, not interfaces and internals Little to no knowledge of other services needed
  32. 32. 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
  33. 33. 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
  34. 34. Easy to scale Vertical scaling easy and more effective
  35. 35. Easy to scale Vertical scaling easy and more effective Horizontal scaling also easy!
  36. 36. Easy to scale Vertical scaling easy and more effective Horizontal scaling also easy! More efficient use of resources
  37. 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. 38. Auto scaling
  39. 39. Service Service Service Service Service Auto scaling Service Load
  40. 40. “Cattle not pets” Gavin McCance, CERN
  41. 41. “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
  42. 42. “Loosely coupled service oriented architecture with bounded contexts” Adrian Cockcroft, Architect @ Netflix
  43. 43. https://netflix.github.io/ http://techblog.netflix.com/
  44. 44. Atlas
  45. 45. The other story
  46. 46. The other story credit to Fred George
  47. 47. Project delivery cycles 1980 1990 2000 2010 Projectduration(log) 1 week 1 month 1 year 5 years
  48. 48. Project delivery cycles 1980 1990 2000 2010 Projectduration(log) 1 week 1 month 1 year 5 years Waterfall
  49. 49. Project delivery cycles 1980 1990 2000 2010 Projectduration(log) 1 week 1 month 1 year 5 years Waterfall Waterfall + OO
  50. 50. Project delivery cycles 1980 1990 2000 2010 Projectduration(log) 1 week 1 month 1 year 5 years Waterfall Waterfall + OO Agile
  51. 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. 52. Hardware lead times 1990 2000 2010 2015 Orderleadtime(log(ish)) < 1 sec 1 hour 1 week 6 months 5 secs
  53. 53. Hardware lead times 1990 2000 2010 2015 Orderleadtime(log(ish)) < 1 sec 1 hour 1 week 6 months Data center 5 secs
  54. 54. Hardware lead times 1990 2000 2010 2015 Orderleadtime(log(ish)) < 1 sec 1 hour 1 week 6 months Data center Virtual machines 5 secs
  55. 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) 5 secs PaaS
  56. 56. 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
  57. 57. Project size 1990 2000 2010 2015 Projectsize(linesofcode) 1,000 10,000 100,000 1,000,000
  58. 58. Project size 1990 2000 2010 2015 Projectsize(linesofcode) 1,000 10,000 100,000 1,000,000 Java
  59. 59. Project size 1990 2000 2010 2015 Projectsize(linesofcode) 1,000 10,000 100,000 1,000,000 Java Ruby
  60. 60. Project size 1990 2000 2010 2015 Projectsize(linesofcode) 1,000 10,000 100,000 1,000,000 Java Ruby Python
  61. 61. Project size 1990 2000 2010 2015 Projectsize(linesofcode) 1,000 10,000 100,000 1,000,000 Java Ruby Python Node.js
  62. 62. Onboarding the new dev... credit: https://twitter.com/moonpolysoft/status/781868129269919744
  63. 63. Story time
  64. 64. Marx on Microservices
  65. 65. Marx on Microservices Economic and Philosophic Manuscripts of 1844
  66. 66. Marx on Microservices Economic and Philosophic Manuscripts of 1844 Gattungswesen (species-being) Workers feeling a connection to their work
  67. 67. 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
  68. 68. Products not Projects
  69. 69. “Any piece of software reflects the organizational structure that produced it” Conway's Law
  70. 70. Inverse Conway Maneuver?
  71. 71. What sort of organisation do you want to work in?
  72. 72. The other, other story
  73. 73. SOA
  74. 74. Service Oriented Architecture
  75. 75. Service Oriented Architecture Boundaries are explicit
  76. 76. Service Oriented Architecture Boundaries are explicit Services are autonomous
  77. 77. Service Oriented Architecture Boundaries are explicit Services are autonomous Services share schema and contract, not class
  78. 78. Service Oriented Architecture Boundaries are explicit Services are autonomous Services share schema and contract, not class Service compatibility is based on policy
  79. 79. IBM SOA Foundation
  80. 80. IBM SOA Foundation Reference Architecture
  81. 81. IBM SOA Foundation Reference Architecture logical model
  82. 82. IBM SOA Foundation Reference Architecture solution
  83. 83. Oracle SOA Foundation Reference Architecture (Product Mapping)
  84. 84. Oracle SOA Foundation Reference Architecture
  85. 85. “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
  86. 86. “... and that’s where we need to concentrate from this point forward: Services” Anne Thomas Manes, SOA is Dead; Long Live Services
  87. 87. Why you shouldn’t do Microservices
  88. 88. CAP Theorem Dr. Eric Brewer (2000)
  89. 89. CAP Theorem Consistency Availability Partition tolerance
  90. 90. CAP Theorem Consistency (all requests return the correct results) Availability Partition tolerance
  91. 91. CAP Theorem Consistency (all requests return the correct results) Availability (all requests complete) Partition tolerance
  92. 92. CAP Theorem Consistency (all requests return the correct results) Availability (all requests complete) Partition tolerance (the network may fail)
  93. 93. CAP Theorem Consistency (all requests return the correct results) Availability (all requests complete) Partition tolerance (the network may fail) Pick 2
  94. 94. CAP Theorem - Example 1 [x] Data store User 1 User 2
  95. 95. CAP Theorem - Example 1 [x] Data store User 1 User 2 put(40)
  96. 96. CAP Theorem - Example 1 [40] Data store User 1 User 2
  97. 97. CAP Theorem - Example 1 [40] Data store User 1 User 2 get
  98. 98. CAP Theorem - Example 1 [40] Data store User 1 User 2 40
  99. 99. CAP Theorem - Example 1 [40] Data store User 1 User 2 40 ✔ Consistent (correct) ✔ Available (answered) ❌ Partition tolerant (no network partitions)
  100. 100. 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
  101. 101. CAP Theorem - Example 2 [40] Data store (US) User 1 User 2 [40] Data store (EU)
  102. 102. CAP Theorem - Example 2 [40] Data store (US) User 1 User 2 put(60) [40] Data store (EU)
  103. 103. CAP Theorem - Example 2 [60] Data store (US) User 1 User 2 [40] Data store (EU)
  104. 104. CAP Theorem - Example 2 [60] Data store (US) User 1 User 2 [40] Data store (EU)
  105. 105. CAP Theorem - Example 2 [60] Data store (US) User 1 User 2 [40] Data store (EU) get What now?
  106. 106. CAP Theorem - Example 2 [60] Data store (US) User 1 User 2 [40] Data store (EU) get ⟶ 40
  107. 107. CAP Theorem - Example 2 [60] Data store (US) User 1 User 2 [40] Data store (EU) get ⟶ 40 ❌ Consistent (incorrect) ✔ Available (answered) ✔ Partition tolerant
  108. 108. 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
  109. 109. 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
  110. 110. Profile picture?
  111. 111. Profile picture? Bank balance?
  112. 112. Profile picture? Bank balance? ATM withdrawal?
  113. 113. Profile picture? Bank balance? ATM withdrawal? Football scores?
  114. 114. Profile picture? Bank balance? ATM withdrawal? Football scores? Parcel tracker?
  115. 115. Pick 2
  116. 116. Pick 2
  117. 117. Pick 2 Understand the tradeoffs
  118. 118. All distributed systems have to deal with CAP
  119. 119. All distributed systems have to deal with CAP Microservices add CAP where it wasn’t before
  120. 120. 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
  121. 121. The network is reliable
  122. 122. The network is reliable
  123. 123. Infrastructure is attacked The network is reliable
  124. 124. Infrastructure is attacked The network is reliable
  125. 125. Infrastructure is attacked Networks are attacked The network is reliable
  126. 126. Infrastructure is attacked Networks are attacked Machines fail The network is reliable
  127. 127. Infrastructure is attacked Networks are attacked Machines fail The network is reliable
  128. 128. The latency is zero
  129. 129. The latency is zero
  130. 130. The latency is zero US East to west (+~65ms)
  131. 131. The latency is zero US East to west (+~65ms) Atlantic crossing (+~90ms) London to Auckland (+~270ms)
  132. 132. The latency is zero US East to west (+~65ms) Atlantic crossing (+~90ms) London to Auckland (+~270ms)
  133. 133. The latency is zero US East to west (+~65ms) Atlantic crossing (+~90ms) London to Auckland (+~270ms) The case of the 500-mile email
  134. 134. Bandwidth is infinite
  135. 135. Bandwidth is infinite
  136. 136. Bandwidth is infinite
  137. 137. Bandwidth is infinite VOIP, streaming video/audio...
  138. 138. Bandwidth is infinite VOIP, streaming video/audio... 1000s of services sharing a line?
  139. 139. Bandwidth is infinite VOIP, streaming video/audio... 1000s of services sharing a line? Even T-1 lines get saturated
  140. 140. Bandwidth is infinite VOIP, streaming video/audio... 1000s of services sharing a line? Even T-1 lines get saturated Bottlenecks?
  141. 141. The network is secure
  142. 142. The network is secure
  143. 143. The network is secure Heartbleed?
  144. 144. 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
  145. 145. 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
  146. 146. The network is secure Heartbleed? DynDNS? Network border isn’t good enough
  147. 147. Topology doesn't change
  148. 148. Topology doesn't change
  149. 149. Topology doesn't change Topology is dynamic!
  150. 150. Topology doesn't change Topology is dynamic! (Cattle not pets)
  151. 151. Topology doesn't change Topology is dynamic! (Cattle not pets) Can’t rely on specific endpoints...
  152. 152. Topology doesn't change Topology is dynamic! (Cattle not pets) Can’t rely on specific endpoints... ...or performance, routing etc.
  153. 153. 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
  154. 154. There is one administrator
  155. 155. There is one administrator
  156. 156. There is one administrator Who grants access to database?
  157. 157. There is one administrator Who grants access to database? ...and to another service?
  158. 158. There is one administrator Who grants access to database? ...and to another service?
  159. 159. There is one administrator Who grants access to database? ...and to another service? Who do you complain to?
  160. 160. There is one administrator Who grants access to database? ...and to another service? Who do you complain to? Coordinated updates?
  161. 161. Transport cost is zero
  162. 162. Transport cost is zero
  163. 163. Transport cost is zero Literally not free
  164. 164. Transport cost is zero Literally not free Who’s paying?
  165. 165. Transport cost is zero Literally not free Who’s paying? Marshalling isn’t free either
  166. 166. The network is homogeneous
  167. 167. The network is homogeneous
  168. 168. My pockets aren’t homogeneous! The network is homogeneous
  169. 169. The network is homogeneous My pockets aren’t homogeneous! Can’t assume you’re talking to UNIX etc.
  170. 170. The network is homogeneous My pockets aren’t homogeneous! Can’t assume you’re talking to UNIX etc. Can’t assume character encodings
  171. 171. 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
  172. 172. 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
  173. 173. Aaron Cohen
  174. 174. Aaron Cohen NASA

×