DSR Microservices (Day 1, Part 1)

192
Microservices @Steve_Upton

Transcript of DSR Microservices (Day 1, Part 1)

Page 1: DSR Microservices (Day 1, Part 1)

Microservices@Steve_Upton

Page 2: DSR Microservices (Day 1, Part 1)

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!

Page 3: DSR Microservices (Day 1, Part 1)

Who are you?

Page 4: DSR Microservices (Day 1, Part 1)

The (2) histories of Microservices

Why you shouldn’t do Microservices

What Microservices actually look like

The future of Microservices

Page 5: DSR Microservices (Day 1, Part 1)

The (2) histories of Microservices

Page 6: DSR Microservices (Day 1, Part 1)

The standard Microservices creation story

Page 7: DSR Microservices (Day 1, Part 1)
Page 8: DSR Microservices (Day 1, Part 1)

Monolith

HTTP DataAccess

Component

Component

Component

Component

...

HTTP

Page 9: DSR Microservices (Day 1, Part 1)

Monolith

HTTP DataAccess

Component

Component

Component

Component

...

HTTP

Page 10: DSR Microservices (Day 1, Part 1)

Monolith

HTTP DataAccess

Component

Component

Component

Component

...

HTTP

Page 11: DSR Microservices (Day 1, Part 1)

Monolith

HTTP DataAccess

Component

Component

Component

Component

...

HTTP

Page 12: DSR Microservices (Day 1, Part 1)

Tightly coupled, slow to change

Page 13: DSR Microservices (Day 1, Part 1)

Tightly coupled, slow to change

Sharing hardware

Page 14: DSR Microservices (Day 1, Part 1)

Tightly coupled, slow to change

Sharing hardware

Needs knowledge of other components (interfaces)

Page 15: DSR Microservices (Day 1, Part 1)

Tightly coupled, slow to change

Sharing hardware

Needs knowledge of other components (interfaces)

Difficult to upgrade without affecting other services

Page 16: DSR Microservices (Day 1, Part 1)

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.

Page 17: DSR Microservices (Day 1, Part 1)

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

Page 18: DSR Microservices (Day 1, Part 1)

Hard to scale

Page 19: DSR Microservices (Day 1, Part 1)

Hard to scale

RDBMS is a bottleneck

Page 20: DSR Microservices (Day 1, Part 1)

Hard to scale

RDBMS is a bottleneck

Vertical scaling easy, but limited

Page 21: DSR Microservices (Day 1, Part 1)

Hard to scale

RDBMS is a bottleneck

Vertical scaling easy, but limited

Horizontal scaling helpful, but slow and expensive

Page 22: DSR Microservices (Day 1, Part 1)

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

Page 23: DSR Microservices (Day 1, Part 1)

Scaling the monolith

HTTP DataAccess

Service

Service

Service

Service

Service

HTTP DataAccess

Service

Service

Service

Service

Service

HTTP DataAccess

Component

Component

Component

Component

...

HTTP

Load

bal

ance

r

Page 24: DSR Microservices (Day 1, Part 1)

“...the average server operates at no more than 12 to 18 percent of its capacity”

Natural Resources Defense Council

Page 25: DSR Microservices (Day 1, Part 1)
Page 26: DSR Microservices (Day 1, Part 1)
Page 27: DSR Microservices (Day 1, Part 1)

?

Page 28: DSR Microservices (Day 1, Part 1)

Service

Moving to the cloud

HTTP DataAccess

Component

Component

Component

...

HTTP

Page 29: DSR Microservices (Day 1, Part 1)

Service

Service

Service

Service

Microservices

HTTP

HTTP

Page 30: DSR Microservices (Day 1, Part 1)

Resilience to failure

Able to isolate failures

Page 31: DSR Microservices (Day 1, Part 1)

Resilience to failure

Able to isolate failures

Gracefully adapt to failures

Page 32: DSR Microservices (Day 1, Part 1)

Resilience to failure

Able to isolate failures

Gracefully adapt to failures

Page 33: DSR Microservices (Day 1, Part 1)

Resilience to failure

Able to isolate failures

Gracefully adapt to failures

Quick recovery

Page 34: DSR Microservices (Day 1, Part 1)

Loosely coupled, easy to change

Share contracts, not interfaces and internals

Little to no knowledge of other services needed

Page 35: DSR Microservices (Day 1, Part 1)

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

Page 36: DSR Microservices (Day 1, Part 1)

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

Page 37: DSR Microservices (Day 1, Part 1)

Easy to scale

Vertical scaling easy and more effective

Page 38: DSR Microservices (Day 1, Part 1)

Easy to scale

Vertical scaling easy and more effective

Horizontal scaling also easy!

Page 39: DSR Microservices (Day 1, Part 1)

Easy to scale

Vertical scaling easy and more effective

Horizontal scaling also easy!

More efficient use of resources

Page 40: DSR Microservices (Day 1, Part 1)

Easy to scale

Vertical scaling easy and more effective

Horizontal scaling also easy!

More efficient use of resources

Auto scaling of individual services possible

Page 41: DSR Microservices (Day 1, Part 1)

Auto scaling

Page 42: DSR Microservices (Day 1, Part 1)

ServiceService

ServiceService

Service

Auto scaling

Service

Load

Page 43: DSR Microservices (Day 1, Part 1)

“Cattle not pets”Gavin McCance, CERN

Page 44: DSR Microservices (Day 1, Part 1)

“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

Page 45: DSR Microservices (Day 1, Part 1)

“Loosely coupled service oriented architecture with bounded contexts”

Adrian Cockcroft, Architect @ Netflix

Page 46: DSR Microservices (Day 1, Part 1)
Page 48: DSR Microservices (Day 1, Part 1)

Atlas

Page 49: DSR Microservices (Day 1, Part 1)
Page 50: DSR Microservices (Day 1, Part 1)
Page 51: DSR Microservices (Day 1, Part 1)

The other story

Page 52: DSR Microservices (Day 1, Part 1)

The other storycredit to Fred George

Page 53: DSR Microservices (Day 1, Part 1)

Project delivery cycles

1980 1990 2000 2010

Pro

ject

dur

atio

n (lo

g)

1 week

1 month

1 year

5 years

Page 54: DSR Microservices (Day 1, Part 1)

Project delivery cycles

1980 1990 2000 2010

Pro

ject

dur

atio

n (lo

g)

1 week

1 month

1 year

5 years Waterfall

Page 55: DSR Microservices (Day 1, Part 1)

Project delivery cycles

1980 1990 2000 2010

Pro

ject

dur

atio

n (lo

g)

1 week

1 month

1 year

5 years Waterfall

Waterfall + OO

Page 56: DSR Microservices (Day 1, Part 1)

Project delivery cycles

1980 1990 2000 2010

Pro

ject

dur

atio

n (lo

g)

1 week

1 month

1 year

5 years Waterfall

Waterfall + OO

Agile

Page 57: DSR Microservices (Day 1, Part 1)

Project delivery cycles

1980 1990 2000 2010

Pro

ject

dur

atio

n (lo

g)

1 week

1 month

1 year

5 years Waterfall

Waterfall + OO

Agile

Agile + Lean

Page 58: DSR Microservices (Day 1, Part 1)

Hardware lead times

1990 2000 2010 2015

Ord

er le

ad ti

me

(log(

ish)

)

< 1 sec

1 hour

1 week

6 months

5 secs

Page 59: DSR Microservices (Day 1, Part 1)

Hardware lead times

1990 2000 2010 2015

Ord

er le

ad ti

me

(log(

ish)

)

< 1 sec

1 hour

1 week

6 months Data center

5 secs

Page 60: DSR Microservices (Day 1, Part 1)

Hardware lead times

1990 2000 2010 2015

Ord

er le

ad ti

me

(log(

ish)

)

< 1 sec

1 hour

1 week

6 months Data center

Virtual machines

5 secs

Page 61: DSR Microservices (Day 1, Part 1)

Hardware lead times

1990 2000 2010 2015

Ord

er le

ad ti

me

(log(

ish)

)

< 1 sec

1 hour

1 week

6 months Data center

Virtual machines

Commercial cloud (AWS)

5 secs

PaaS

Page 62: DSR Microservices (Day 1, Part 1)

Hardware lead times

1990 2000 2010 2015

Ord

er le

ad ti

me

(log(

ish)

)

< 1 sec

1 hour

1 week

6 months Data center

Virtual machines

Commercial cloud (AWS)

Docker

FaaS

5 secs

PaaS

Page 63: DSR Microservices (Day 1, Part 1)

Project size

1990 2000 2010 2015

Pro

ject

siz

e (li

nes

of c

ode)

1,000

10,000

100,000

1,000,000

Page 64: DSR Microservices (Day 1, Part 1)

Project size

1990 2000 2010 2015

Pro

ject

siz

e (li

nes

of c

ode)

1,000

10,000

100,000

1,000,000 Java

Page 65: DSR Microservices (Day 1, Part 1)

Project size

1990 2000 2010 2015

Pro

ject

siz

e (li

nes

of c

ode)

1,000

10,000

100,000

1,000,000 Java

Ruby

Page 66: DSR Microservices (Day 1, Part 1)

Project size

1990 2000 2010 2015

Pro

ject

siz

e (li

nes

of c

ode)

1,000

10,000

100,000

1,000,000 Java

Ruby

Python

Page 67: DSR Microservices (Day 1, Part 1)

Project size

1990 2000 2010 2015

Pro

ject

siz

e (li

nes

of c

ode)

1,000

10,000

100,000

1,000,000 Java

Ruby

Python

Node.js

Page 68: DSR Microservices (Day 1, Part 1)

Onboarding the new dev...

credit: https://twitter.com/moonpolysoft/status/781868129269919744

Page 69: DSR Microservices (Day 1, Part 1)

Story time

Page 70: DSR Microservices (Day 1, Part 1)

Marx on Microservices

Page 71: DSR Microservices (Day 1, Part 1)

Marx on MicroservicesEconomic and Philosophic Manuscripts of 1844

Page 72: DSR Microservices (Day 1, Part 1)

Marx on MicroservicesEconomic and Philosophic Manuscripts of 1844

Gattungswesen (species-being)

Workers feeling a connection to their work

Page 73: DSR Microservices (Day 1, Part 1)

Marx on MicroservicesEconomic and Philosophic Manuscripts of 1844

Gattungswesen (species-being)

Workers feeling a connection to their work

Entfremdung (alienation)

Workers feel estranged from their work

Page 74: DSR Microservices (Day 1, Part 1)

Products not Projects

Page 75: DSR Microservices (Day 1, Part 1)

“Any piece of software reflects the organizational structure that produced it”

Conway's Law

Page 76: DSR Microservices (Day 1, Part 1)

Inverse Conway Maneuver?

Page 77: DSR Microservices (Day 1, Part 1)

What sort of organisation do you want to work in?

Page 78: DSR Microservices (Day 1, Part 1)

The other, other story

Page 79: DSR Microservices (Day 1, Part 1)

SOA

Page 80: DSR Microservices (Day 1, Part 1)

Service Oriented Architecture

Page 81: DSR Microservices (Day 1, Part 1)

Service Oriented Architecture

Boundaries are explicit

Page 82: DSR Microservices (Day 1, Part 1)

Service Oriented Architecture

Boundaries are explicit

Services are autonomous

Page 83: DSR Microservices (Day 1, Part 1)

Service Oriented Architecture

Boundaries are explicit

Services are autonomous

Services share schema and contract, not class

Page 84: DSR Microservices (Day 1, Part 1)

Service Oriented Architecture

Boundaries are explicit

Services are autonomous

Services share schema and contract, not class

Service compatibility is based on policy

Page 85: DSR Microservices (Day 1, Part 1)

IBM SOA Foundation

Page 86: DSR Microservices (Day 1, Part 1)

IBM SOA Foundation Reference Architecture

Page 87: DSR Microservices (Day 1, Part 1)

IBM SOA Foundation Reference Architecture logical model

Page 88: DSR Microservices (Day 1, Part 1)

IBM SOA Foundation Reference Architecture solution

Page 89: DSR Microservices (Day 1, Part 1)

Oracle SOA Foundation Reference Architecture (Product Mapping)

Page 90: DSR Microservices (Day 1, Part 1)

Oracle SOA Foundation Reference Architecture

Page 91: DSR Microservices (Day 1, Part 1)

“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

Page 92: DSR Microservices (Day 1, Part 1)

“... and that’s where we need to concentrate from this point forward: Services”

Anne Thomas Manes, SOA is Dead; Long Live Services

Page 93: DSR Microservices (Day 1, Part 1)

Why you shouldn’t do Microservices

Page 94: DSR Microservices (Day 1, Part 1)

CAP TheoremDr. Eric Brewer (2000)

Page 95: DSR Microservices (Day 1, Part 1)

CAP Theorem

Consistency

Availability

Partition tolerance

Page 96: DSR Microservices (Day 1, Part 1)

CAP Theorem

Consistency(all requests return the correct results)

Availability

Partition tolerance

Page 97: DSR Microservices (Day 1, Part 1)

CAP Theorem

Consistency(all requests return the correct results)

Availability(all requests complete)

Partition tolerance

Page 98: DSR Microservices (Day 1, Part 1)

CAP Theorem

Consistency(all requests return the correct results)

Availability(all requests complete)

Partition tolerance(the network may fail)

Page 99: DSR Microservices (Day 1, Part 1)

CAP Theorem

Consistency(all requests return the correct results)

Availability(all requests complete)

Partition tolerance(the network may fail)

Pick 2

Page 100: DSR Microservices (Day 1, Part 1)

CAP Theorem - Example 1

[x]

Data storeUser 1 User 2

Page 101: DSR Microservices (Day 1, Part 1)

CAP Theorem - Example 1

[x]

Data storeUser 1 User 2

put(40)

Page 102: DSR Microservices (Day 1, Part 1)

CAP Theorem - Example 1

[40]

Data storeUser 1 User 2

Page 103: DSR Microservices (Day 1, Part 1)

CAP Theorem - Example 1

[40]

Data storeUser 1 User 2

get

Page 104: DSR Microservices (Day 1, Part 1)

CAP Theorem - Example 1

[40]

Data storeUser 1 User 2

40

Page 105: DSR Microservices (Day 1, Part 1)

CAP Theorem - Example 1

[40]

Data storeUser 1 User 2

40

✔ Consistent (correct)✔ Available (answered)❌ Partition tolerant (no network partitions)

Page 106: DSR Microservices (Day 1, Part 1)

CAP Theorem - Example 1

[40]

Data storeUser 1 User 2

40

✔ Consistent (correct)✔ Available (answered)❌ Partition tolerant (no network partitions)

[PROBLEM] No real world system looks like this

Page 107: DSR Microservices (Day 1, Part 1)

CAP Theorem - Example 2

[40]

Data store (US)User 1 User 2

[40]

Data store (EU)

Page 108: DSR Microservices (Day 1, Part 1)

CAP Theorem - Example 2

[40]

Data store (US)User 1 User 2

put(60) [40]

Data store (EU)

Page 109: DSR Microservices (Day 1, Part 1)

CAP Theorem - Example 2

[60]

Data store (US)User 1 User 2

[40]

Data store (EU)

Page 110: DSR Microservices (Day 1, Part 1)

CAP Theorem - Example 2

[60]

Data store (US)User 1 User 2

[40]

Data store (EU)

Page 111: DSR Microservices (Day 1, Part 1)

CAP Theorem - Example 2

[60]

Data store (US)User 1 User 2

[40]

Data store (EU)

get

What now?

Page 112: DSR Microservices (Day 1, Part 1)

CAP Theorem - Example 2

[60]

Data store (US)User 1

User 2

[40]

Data store (EU)

get ⟶ 40

Page 113: DSR Microservices (Day 1, Part 1)

CAP Theorem - Example 2

[60]

Data store (US)User 1

User 2

[40]

Data store (EU)

get ⟶ 40

❌ Consistent (incorrect)✔ Available (answered)✔ Partition tolerant

Page 114: DSR Microservices (Day 1, Part 1)

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

Page 115: DSR Microservices (Day 1, Part 1)

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

Page 116: DSR Microservices (Day 1, Part 1)
Page 117: DSR Microservices (Day 1, Part 1)

Profile picture?

Page 118: DSR Microservices (Day 1, Part 1)

Profile picture?

Bank balance?

Page 119: DSR Microservices (Day 1, Part 1)

Profile picture?

Bank balance?

ATM withdrawal?

Page 120: DSR Microservices (Day 1, Part 1)

Profile picture?

Bank balance?

ATM withdrawal?

Football scores?

Page 121: DSR Microservices (Day 1, Part 1)

Profile picture?

Bank balance?

ATM withdrawal?

Football scores?

Parcel tracker?

Page 122: DSR Microservices (Day 1, Part 1)

Pick 2

Page 123: DSR Microservices (Day 1, Part 1)

Pick 2

Page 124: DSR Microservices (Day 1, Part 1)

Pick 2

Understand the tradeoffs

Page 125: DSR Microservices (Day 1, Part 1)

All distributed systems have to deal with CAP

Page 126: DSR Microservices (Day 1, Part 1)

All distributed systems have to deal with CAP

Microservices add CAP where it wasn’t before

Page 127: DSR Microservices (Day 1, Part 1)

The fallacies of distributed computingThe 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

Page 128: DSR Microservices (Day 1, Part 1)

The network is reliable

Page 129: DSR Microservices (Day 1, Part 1)

The network is reliable

Page 130: DSR Microservices (Day 1, Part 1)

Infrastructure is attacked

The network is reliable

Page 131: DSR Microservices (Day 1, Part 1)

Infrastructure is attacked

The network is reliable

Page 132: DSR Microservices (Day 1, Part 1)

Infrastructure is attacked

Networks are attacked

The network is reliable

Page 133: DSR Microservices (Day 1, Part 1)

Infrastructure is attacked

Networks are attacked

Machines fail

The network is reliable

Page 134: DSR Microservices (Day 1, Part 1)

Infrastructure is attacked

Networks are attacked

Machines fail

The network is reliable

Page 135: DSR Microservices (Day 1, Part 1)

The latency is zero

Page 136: DSR Microservices (Day 1, Part 1)

The latency is zero

Page 137: DSR Microservices (Day 1, Part 1)

The latency is zero

US East to west (+~65ms)

Page 138: DSR Microservices (Day 1, Part 1)

The latency is zero

US East to west (+~65ms)

Atlantic crossing (+~90ms)

London to Auckland (+~270ms)

Page 139: DSR Microservices (Day 1, Part 1)

The latency is zero

US East to west (+~65ms)

Atlantic crossing (+~90ms)

London to Auckland (+~270ms)

Page 140: DSR Microservices (Day 1, Part 1)

The latency is zero

US East to west (+~65ms)

Atlantic crossing (+~90ms)

London to Auckland (+~270ms)

The case of the 500-mile email

Page 141: DSR Microservices (Day 1, Part 1)

Bandwidth is infinite

Page 142: DSR Microservices (Day 1, Part 1)

Bandwidth is infinite

Page 143: DSR Microservices (Day 1, Part 1)

Bandwidth is infinite

Page 144: DSR Microservices (Day 1, Part 1)

Bandwidth is infinite

VOIP, streaming video/audio...

Page 145: DSR Microservices (Day 1, Part 1)

Bandwidth is infinite

VOIP, streaming video/audio...

1000s of services sharing a line?

Page 146: DSR Microservices (Day 1, Part 1)

Bandwidth is infinite

VOIP, streaming video/audio...

1000s of services sharing a line?

Even T-1 lines get saturated

Page 147: DSR Microservices (Day 1, Part 1)

Bandwidth is infinite

VOIP, streaming video/audio...

1000s of services sharing a line?

Even T-1 lines get saturated

Bottlenecks?

Page 148: DSR Microservices (Day 1, Part 1)

The network is secure

Page 149: DSR Microservices (Day 1, Part 1)

The network is secure

Page 150: DSR Microservices (Day 1, Part 1)

The network is secure

Heartbleed?

Page 151: DSR Microservices (Day 1, Part 1)

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

Page 152: DSR Microservices (Day 1, Part 1)

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

Page 153: DSR Microservices (Day 1, Part 1)

The network is secure

Heartbleed?

DynDNS?

Network border isn’t good enough

Page 154: DSR Microservices (Day 1, Part 1)

Topology doesn't change

Page 155: DSR Microservices (Day 1, Part 1)

Topology doesn't change

Page 156: DSR Microservices (Day 1, Part 1)

Topology doesn't change

Topology is dynamic!

Page 157: DSR Microservices (Day 1, Part 1)

Topology doesn't change

Topology is dynamic! (Cattle not pets)

Page 158: DSR Microservices (Day 1, Part 1)

Topology doesn't change

Topology is dynamic! (Cattle not pets)

Can’t rely on specific endpoints...

Page 159: DSR Microservices (Day 1, Part 1)

Topology doesn't change

Topology is dynamic! (Cattle not pets)

Can’t rely on specific endpoints...

...or performance, routing etc.

Page 160: DSR Microservices (Day 1, Part 1)

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

Page 161: DSR Microservices (Day 1, Part 1)

There is one administrator

Page 162: DSR Microservices (Day 1, Part 1)

There is one administrator

Page 163: DSR Microservices (Day 1, Part 1)

There is one administrator

Who grants access to database?

Page 164: DSR Microservices (Day 1, Part 1)

There is one administrator

Who grants access to database?

...and to another service?

Page 165: DSR Microservices (Day 1, Part 1)

There is one administrator

Who grants access to database?

...and to another service?

Page 166: DSR Microservices (Day 1, Part 1)

There is one administrator

Who grants access to database?

...and to another service?

Who do you complain to?

Page 167: DSR Microservices (Day 1, Part 1)

There is one administrator

Who grants access to database?

...and to another service?

Who do you complain to?

Coordinated updates?

Page 168: DSR Microservices (Day 1, Part 1)

Transport cost is zero

Page 169: DSR Microservices (Day 1, Part 1)

Transport cost is zero

Page 170: DSR Microservices (Day 1, Part 1)

Transport cost is zero

Literally not free

Page 171: DSR Microservices (Day 1, Part 1)

Transport cost is zero

Literally not free

Who’s paying?

Page 172: DSR Microservices (Day 1, Part 1)

Transport cost is zero

Literally not free

Who’s paying?

Marshalling isn’t free either

Page 173: DSR Microservices (Day 1, Part 1)

The network is homogeneous

Page 174: DSR Microservices (Day 1, Part 1)

The network is homogeneous

Page 175: DSR Microservices (Day 1, Part 1)

My pockets aren’t homogeneous!

The network is homogeneous

Page 176: DSR Microservices (Day 1, Part 1)

The network is homogeneous

My pockets aren’t homogeneous!

Can’t assume you’re talking to UNIX etc.

Page 177: DSR Microservices (Day 1, Part 1)

The network is homogeneous

My pockets aren’t homogeneous!

Can’t assume you’re talking to UNIX etc.

Can’t assume character encodings

Page 178: DSR Microservices (Day 1, Part 1)

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

Page 179: DSR Microservices (Day 1, Part 1)

The fallacies of distributed computingThe 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

Page 180: DSR Microservices (Day 1, Part 1)
Page 181: DSR Microservices (Day 1, Part 1)

Aaron Cohen

Page 182: DSR Microservices (Day 1, Part 1)

Aaron CohenNASA

Page 183: DSR Microservices (Day 1, Part 1)
Page 184: DSR Microservices (Day 1, Part 1)
Page 185: DSR Microservices (Day 1, Part 1)
Page 186: DSR Microservices (Day 1, Part 1)
Page 187: DSR Microservices (Day 1, Part 1)
Page 188: DSR Microservices (Day 1, Part 1)
Page 189: DSR Microservices (Day 1, Part 1)
Page 190: DSR Microservices (Day 1, Part 1)
Page 191: DSR Microservices (Day 1, Part 1)
Page 192: DSR Microservices (Day 1, Part 1)