Hooking Stuff Together - Programming the Cloud

8/14/2019 Hooking Stuff Together - Programming the Cloud

1/31

Hooking Stuff Together

Gregor Hohpe

www.eaipatterns.com

www.conversationpatterns.com


2/31

Yesterdays Software Environment

Todays

Collaborating services instead ofmonolithic applications

The cloud as middleware platform

Services are all about interaction

1

Connected, but loosely coupled


3/31

Less is More?

NO Call StackNO Transactions

NO Certainty

NO Ordering ConstraintsNO Assumptions

2

Scary? Yes!

Cool? Yes!

Way to go? Yes!


4/31

System A System B

A Simple Interaction

3


5/31

Communication Problems

System A System B

Lost Request?

4

Lost Response?System B Crashed?

Retry?


6/31

Delayed Response

System A System B

5

Executed Twice?


7/31

Inherent State Uncertainty

System A is never 100% sure what stateSystem B is in

This roblem does not occur in a monolithic

system

Compare Byzantine Generals Problem

Unreliable Messaging

Army 1 Army 2

6

Attack? Attack?

Enemy


8/31

Still An Issue With HTTP

Hardware failureNetwork failure

Total: $219.73

Partial response

7

uy


9/31

What About Distributed Transactions?

Require coordinatorEven 2 Phase Commit has windows of

uncertaint

Not practical for long running interactions

Locks not practical / economical

Isolation not possible / practical

Usually not supported

8

on sca eLife Beyond Distributed Translations

an Apostates Opinion

--Pat Helland


10/31

Now What?

Live with uncertaintySimplicity is King

Interaction

Asynchrony

New programming models

9

-

Patterns Renaissance


11/31

Living With Uncertainty

ACID (before) ACID (today)

Consistent

IsolatedDurable

Commutative

IdempotentDistributed

10

Predictive

Accurate

Flexible

Redundant


12/31

Starbucks Does not Use 2-Phase Commit Either

Start making coffee before customer paysReduces latency

Customer rejects drink

Remake drink

Retry

11

Customer cannot pay

Discard beverage

Write-off

Compensation

Si li i i Ki


13/31

Simplicity is King

Even simple things become complicated in adistributed environment

If it looks com licated on a er its likel to be

impossible in practice

If you cant understand it, other developers likely

wont eitherA well understood failure scenario can be better

12

an an ncompre ens e an unproven a sa e

system

F I i


14/31

Focus on Interaction

In the OO world interaction is essentially freePowerful structural mechanisms: inheritance,

com osition, a re ation

In the cloud, more focus shifts to interaction.

Structural composition mechanisms are limited.

13

C ti


15/31

Conversations

Series of related messages between partiesNot handled at lower layer

Protocol design

Order

Invoice

Internal State:Waiting forPayment

Internal State:ProcessingPayment

Conversation State

14

Payment

DrinksInternal State:Making Drinks

A h


16/31

Asynchrony

Exchange through messages, not RPCWaiting for the results of an HTTP request is not a

smart use of a 3 GHz rocessor

Request and response message typically handled

by different parts of your program, even if the

same TCP connectionReduced assumptions about timing and state

15

P i Ab t ti M R d


17/31

Programming Abstraction: MapReduce

Represent computing problems as Map and Reduce stepInspired by functional programming

True framework: dont call us, well call you

map(in_key, data) list(key, value)

16

reduce(key, list(values)) list(out_data)

http://research.google.com/archive/mapreduce.html

MapReduce: Word Frequency


18/31

MapReduce: Word Frequency

map(String key, String value):// key: document name// value: document contents

To be or not to be

to not1 1

map

for each word w in value:EmitIntermediate(w, "1");

reduce(String key, Iterator values):

beor

tobe

11

11

Shuffle

be or1 11

17

ey: a wor

// values: a list of countsint result = 0;for each v in values:result += ParseInt(v);

Emit(key + : + result);

reduce

be: 2

not: 1

or: 1

to: 2

MapReduce Run time


19/31

MapReduce Run-time

Distribute data among many machines, executesame computation at each machine on its dataset

MapTask 1

MapTask 2

MapTask 3

I n p u t D a t aSharding

18

Sort &Group

Sort &Group

ReduceTask 1

ReduceTask 2

key

D i S ifi L S ll


20/31

Domain Specific Language: Sawzall

Commutative and associative operations allow parallelexecution and aggregation

count: table sum of int;

19

x: float = input;

emit count


21/31

Behold the Run-time

Some programming abstractions are great, e.g.MapReduce

In a sin le-threaded call-stack machine,

programming model and execution model match

fairly closely

In a highly distributed dynamic system, they arevery different!

20

on or ng, run- me ana ys s, an v sua za on

critically important

Behold the Run time


22/31

Behold the Run-time

Call Stack MapReducevoid a() {b();

}

map(in_key, data) list(key, value)

Void b() {c();d();

}

A B C D

, list(out_data)

21

My Work


23/31

My Work

Messaging Patterns (65) Messaging Systems

Messaging Channels

Messa e Construction

www.eaipatterns.com

Message Routing Message Transformation

Messaging Endpoints

System Management

Conversation Patterns

Discovery

www.conversationpatterns.com

22

s a s ng a onversa on

Multi-party Conversations

Reaching agreement

Resource Management

Error Handling

Patterns 10 Years After GoF


24/31

Patterns 10 Years After GoF

New programming models bring new patterns.Mind sized chunks of information

Ward Cunnin ham

Human-to-human communication

Expresses intent (the why vs. the how)

Makes assumptions explicit

Observed from actual ex erience

23

Multiple Service Providers


25/31


Consumer

Provider 1

Provider 2Request Channel

Request message can be consumed by more than one

service provider

Reply Channel

24

Point-to-Point Channelsupports Competing Consumers,only one service receives each request message

Channel queues up pending requests



26/31


Reply messages get out ofsequence

How to match request and

Service 1(slow)

Service 2(fast)

Consumer

Reply 1

reply messages? Only send one request at a

time very inefficient

Rely on natural order bad assumption

Request 2

Reply 2

25

Pattern: Correlation Identifier


27/31

Pattern: Correlation Identifier

MessageIdentifier 1

2

Provider 1

Request Channel

1 21 2

Consumer

Equip each message with a unique identifier

Message ID (simple, but has limitations)

Response Channel

12 12

12

Correlation

Identifier

CorrelateRequest &Reply

26

Business key (e.g. Order ID)

Provider copies the ID to the reply message

Consumer can match request and response

Conversation Pattern: Dynamic Discovery


28/31

Conversation Pattern: Dynamic Discovery

Provider1

Provider

Pub-Sub

Request

1

2

Consider

Choose

1. Broadcast request

2. Provider(s) consider whether to respond (load, suitability)

Provider3

3 Respond4

5 Interact

27

3. Interested providers send responses

4. Requestor chooses best provider from responses

5. Requestor initiates interaction with chosen provider

Examples: DHCP, TIBCO Repository discovery

Conversation Pattern: Renewing Interest


29/31

Lease

(Renew Interval)

Conversation Pattern: Renewing Interest

Lease model

Heartbeat / keep-alive

RegisterAutomatic Expiration

u scr er as to renewactively

Example: Jini

Magazine Model

Renew Interest

Register

Renewal Request

Subscriber Provider

t

28

Renewal Confirm

Provider has to manage statefor each subscriber

Renewal Request

ProviderSubscriber

Keep These in Mind


30/31

Keep These in Mind

Live with uncertainty

Simplicity is King

Interaction

Asynchrony

New programming models

29

Patterns Renaissance


31/31

Fin

Hooking Stuff Together - Programming the Cloud

Documents

Transcript of Hooking Stuff Together - Programming the Cloud