Objects, Anomalies, and Actors: The Next Revolution Steve Vinoski - - PowerPoint PPT Presentation

▶
objects anomalies and actors the next revolution
SMART_READER_LITE
LIVE PREVIEW

Objects, Anomalies, and Actors: The Next Revolution Steve Vinoski - - PowerPoint PPT Presentation

Dec 17, 2023 227 likes •1.83k views

Objects, Anomalies, and Actors: The Next Revolution Steve Vinoski Architect, Basho Technologies QCon San Francisco 2011 18 Nov 2011 @stevevinoski http://steve.vinoski.net/ vinoski@ieee.org 1 This is actually Kresten Krab Thorups

slide-1
SLIDE 1

Objects, Anomalies, and Actors: The Next Revolution

Steve Vinoski

Architect, Basho Technologies

QCon San Francisco 2011 18 Nov 2011 @stevevinoski http://steve.vinoski.net/ vinoski@ieee.org

1
slide-2
SLIDE 2
  • This is actually Kresten Krab Thorup’s talk, but

he couldn’t attend the conference

  • he’s CTO of Trifork
  • and an important part of the team

behind the QCon and GOTO conferences

  • I’m covering for him here, giving my

interpretation of his material

  • These are (mostly) his slides, I’ve changed a few

and inserted some of my own

2
slide-3
SLIDE 3

’90s Object Revolution

3

3
slide-4
SLIDE 4

Increased Complexity

4

’90s Object Revolution

4
slide-5
SLIDE 5

Program Structure Increased Complexity

4

’90s Object Revolution

4
slide-6
SLIDE 6

Program Structure Component Reuse Increased Complexity

4

’90s Object Revolution

4
slide-7
SLIDE 7

Program Structure Component Reuse Domain Modeling Increased Complexity

4

’90s Object Revolution

4
slide-8
SLIDE 8

Simula Smalltalk Java Objective-C C# C++

Languages

Ruby

5

5
slide-9
SLIDE 9

Simula Smalltalk Java Objective-C C# C++ Ruby OOA&D UML

Thinking Tools

Patterns DDD

6

6
slide-10
SLIDE 10

Program Structure Component Reuse Domain Modeling Increased Complexity

7

Internet

7
slide-11
SLIDE 11

8

More Complexity Infrastructure made of Software

8
slide-12
SLIDE 12

Infrastructure made of Software More Complexity

9

9
slide-13
SLIDE 13

Infrastructure made of Software Fault Tolerance, Availability, QoS More Complexity

9

9
slide-14
SLIDE 14

Infrastructure made of Software Fault Tolerance, Availability, QoS Integration, Coordination More Complexity

9

9
slide-15
SLIDE 15

Infrastructure made of Software Fault Tolerance, Availability, QoS Integration, Coordination Cloud, Multi-Core More Complexity

9

9
slide-16
SLIDE 16

Infrastructure made of Software Fault Tolerance, Availability, QoS Integration, Coordination Cloud, Multi-Core More Complexity

W e ’ r e s t r u g g l i n g t

  • h

a n d l e t h e s e w i t h a n

  • b

j e c t m i n d s e t !

9

9
slide-17
SLIDE 17

Fault Tolerance, Availability, QoS Integration, Coordination Cloud, Multi-Core Time for a new revolution?

10

10
slide-18
SLIDE 18

What’s a Revolution?

Thomas Kuhn The Structure of Scientific Revolutions

11

11
slide-19
SLIDE 19

paradigm paradigm

12

12
slide-20
SLIDE 20

paradigm paradigm

12

12
slide-21
SLIDE 21

paradigm paradigm

normal science

12

12
slide-22
SLIDE 22

paradigm paradigm

normal science

  • bserve

anomalies

12

12
slide-23
SLIDE 23

paradigm paradigm

normal science CRISIS

  • bserve

anomalies

12

12
slide-24
SLIDE 24

paradigm paradigm

normal science CRISIS

  • bserve

anomalies

12

revolutionary science

12
slide-25
SLIDE 25

paradigm paradigm

normal science normal science CRISIS

  • bserve

anomalies

12

revolutionary science

12
slide-26
SLIDE 26

Fault Tolerance, Availability, QoS Integration, Coordination Cloud, Multi-Core What is the right paradigm to cope with these?

13

13
slide-27
SLIDE 27

Fault Tolerance, Availability, QoS Integration, Coordination Cloud, Multi-Core Functional, Data-Parallel Erlang, Actor Models Parallel Compilers What is the right paradigm to cope with these?

13

13
slide-28
SLIDE 28

Fault Tolerance, Availability, QoS Integration, Coordination Cloud, Multi-Core Functional, Data-Parallel Erlang, Actor Models Parallel Compilers What is the right paradigm to cope with these?

13

R a l p h J

  • h

n s

  • n

’ s b l

  • g

“ E r l a n g , t h e N e x t J a v a ” . . . E r l a n g i s g

  • i

n g t

  • b

e a v e r y i m p

  • r

t a n t l a n g u a g e . . . I t s m a i n a d v a n t a g e i s t h a t i t i s p e r f e c t l y s u i t e d f

  • r

t h e m u l t i

  • c
  • r

e , w e b s e r v i c e s f u t u r e . I n f a c t , i t i s t h e O N L Y m a t u r e , r

  • c

k

  • s
  • l

i d l a n g u a g e t h a t i s s u i t a b l e f

  • r

w r i t i n g h i g h l y s c a l a b l e s y s t e m s t

  • r

u n

  • n

m u l t i c

  • r

e m a c h i n e s .

13
slide-29
SLIDE 29

Objects Actors

14

14
slide-30
SLIDE 30

Objects Actors

14

14
slide-31
SLIDE 31

Objects anomalies Actors

14

14
slide-32
SLIDE 32

Objects anomalies Actors

14

If Actor-Programming is the new Paradigm, What are the anomalies we should see now?

14
slide-33
SLIDE 33

Anomalies in the object-oriented world view

15

15
slide-34
SLIDE 34
  • 9

10 1 1 8 7 6

implementation interface

  • Graphics from Object-Oriented Programming with Objective C, Apple, 2011

16

16
slide-35
SLIDE 35

m e t h

  • d

m e t h

  • d

m e t h

  • d

m e t h

  • d

data

  • 17

Encapsulation

17
slide-36
SLIDE 36

m e t h

  • d

m e t h

  • d

m e t h

  • d

m e t h

  • d

data

  • m

e t h

  • d

m e t h

  • d

m e t h

  • d

m e t h

  • d

data

  • m

e t h

  • d

m e t h

  • d

m e t h

  • d

m e t h

  • d

data

  • 18
18
slide-37
SLIDE 37

m e t h

  • d

m e t h

  • d

m e t h

  • d

m e t h

  • d

data

  • m

e t h

  • d

m e t h

  • d

m e t h

  • d

m e t h

  • d

data

  • m

e t h

  • d

m e t h

  • d

m e t h

  • d

m e t h

  • d

data

  • 18
18
slide-38
SLIDE 38

m e t h

  • d

m e t h

  • d

m e t h

  • d

m e t h

  • d

data

  • m

e t h

  • d

m e t h

  • d

m e t h

  • d

m e t h

  • d

data

  • m

e t h

  • d

m e t h

  • d

m e t h

  • d

m e t h

  • d

data

  • 18
18
slide-39
SLIDE 39

m e t h

  • d

m e t h

  • d

m e t h

  • d

m e t h

  • d

data

  • m

e t h

  • d

m e t h

  • d

m e t h

  • d

m e t h

  • d

data

  • m

e t h

  • d

m e t h

  • d

m e t h

  • d

m e t h

  • d

data

  • 18
18
slide-40
SLIDE 40

m e t h

  • d

m e t h

  • d

m e t h

  • d

m e t h

  • d

data

  • m

e t h

  • d

m e t h

  • d

m e t h

  • d

m e t h

  • d

data

  • m

e t h

  • d

m e t h

  • d

m e t h

  • d

m e t h

  • d

data

  • 18
18
slide-41
SLIDE 41

m e t h

  • d

m e t h

  • d

m e t h

  • d

m e t h

  • d

data

  • m

e t h

  • d

m e t h

  • d

m e t h

  • d

m e t h

  • d

data

  • m

e t h

  • d

m e t h

  • d

m e t h

  • d

m e t h

  • d

data

  • 18

Anomaly

18
slide-42
SLIDE 42

19

m e t h
  • d
m e t h
  • d
m e t h
  • d
m e t h
  • d
data
  • m
e t h
  • d
m e t h
  • d
m e t h
  • d
m e t h
  • d
data
  • m
e t h
  • d
m e t h
  • d
m e t h
  • d
m e t h
  • d
data
  • m
e t h
  • d
m e t h
  • d
m e t h
  • d
m e t h
  • d
data
  • m
e t h
  • d
m e t h
  • d
m e t h
  • d
m e t h
  • d
data
  • 19
slide-43
SLIDE 43

19

m e t h
  • d
m e t h
  • d
m e t h
  • d
m e t h
  • d
data
  • m
e t h
  • d
m e t h
  • d
m e t h
  • d
m e t h
  • d
data
  • m
e t h
  • d
m e t h
  • d
m e t h
  • d
m e t h
  • d
data
  • m
e t h
  • d
m e t h
  • d
m e t h
  • d
m e t h
  • d
data
  • m
e t h
  • d
m e t h
  • d
m e t h
  • d
m e t h
  • d
data
  • 19
slide-44
SLIDE 44

19

m e t h
  • d
m e t h
  • d
m e t h
  • d
m e t h
  • d
data
  • m
e t h
  • d
m e t h
  • d
m e t h
  • d
m e t h
  • d
data
  • m
e t h
  • d
m e t h
  • d
m e t h
  • d
m e t h
  • d
data
  • m
e t h
  • d
m e t h
  • d
m e t h
  • d
m e t h
  • d
data
  • m
e t h
  • d
m e t h
  • d
m e t h
  • d
m e t h
  • d
data
  • m
e t h
  • d
m e t h
  • d
m e t h
  • d
m e t h
  • d
data
  • 19
slide-45
SLIDE 45

m e t h

  • d

m e t h

  • d

m e t h

  • d

m e t h

  • d

data

  • mailbox

Active Object + State Machine

20

20
slide-46
SLIDE 46

m e t h

  • d

m e t h

  • d

m e t h

  • d

m e t h

  • d

data

  • mailbox

Active Object + State Machine

20

20
slide-47
SLIDE 47

m e t h

  • d

m e t h

  • d

m e t h

  • d

m e t h

  • d

data

  • mailbox

21

Active Object + State Machine

21
slide-48
SLIDE 48

m e t h

  • d

m e t h

  • d

m e t h

  • d

m e t h

  • d

data

  • mailbox

21

Active Object + State Machine

21
slide-49
SLIDE 49

empty full(X) box

22

22
slide-50
SLIDE 50

empty full(X) {‘put’,X} box

22

22
slide-51
SLIDE 51

empty full(X) {‘put’,X} {‘take’,From} / send(From, X) box

22

22
slide-52
SLIDE 52

empty full(X) {‘put’,X} {‘take’,From} / send(From, X) box

box() ➞ empty(). empty() ➞ receive {‘put’, X} ➞ full(X) end. full(X) ➞ receive {‘take’, From} ➞ From ! X, empty() end.

23

23
slide-53
SLIDE 53

box() ➞ empty(). empty() ➞ receive {‘put’, X} ➞ full(X) end. full(X) ➞ receive {‘take’, From} ➞ From ! X, empty() end.

empty full(X) {‘put’,X} {‘take’,From} / send(From, X) box {‘peek’,From} / send(From,{‘ok’, X})

24

24
slide-54
SLIDE 54

box() ➞ empty(). empty() ➞ receive {‘put’, X} ➞ full(X) end. full(X) ➞ receive {‘take’, From} ➞ From ! X, empty(); {‘peek’, From} ➞ From ! {‘ok’, X}, full(X) end.

25

empty full(X) {‘put’,X} {‘take’,From} / send(From, X) box {‘peek’,From} / send(From,{‘ok’, X})

25
slide-55
SLIDE 55

box() ➞ empty(). empty() ➞ receive {‘put’, X} ➞ full(X) end. full(X) ➞ receive {‘take’, From} ➞ From ! X, empty(); {‘peek’, From} ➞ From ! {‘ok’, X}, full(X) end.

25

empty full(X) {‘put’,X} {‘take’,From} / send(From, X) box {‘peek’,From} / send(From,{‘ok’, X})

25
slide-56
SLIDE 56

26

box() ➞ empty(). empty() ➞ receive {‘put’, X} ➞ full(X) end. full(X) ➞ receive {‘take’, From} ➞ From ! X, empty(); {‘peek’, From} ➞ From ! {‘ok’, X}, full(X) end.

26
slide-57
SLIDE 57

Box = spawn(fun box/0),

26

box() ➞ empty(). empty() ➞ receive {‘put’, X} ➞ full(X) end. full(X) ➞ receive {‘take’, From} ➞ From ! X, empty(); {‘peek’, From} ➞ From ! {‘ok’, X}, full(X) end.

26
slide-58
SLIDE 58

Box = spawn(fun box/0), Box ! {‘put’, 27},

26

box() ➞ empty(). empty() ➞ receive {‘put’, X} ➞ full(X) end. full(X) ➞ receive {‘take’, From} ➞ From ! X, empty(); {‘peek’, From} ➞ From ! {‘ok’, X}, full(X) end.

26
slide-59
SLIDE 59

Box = spawn(fun box/0), Box ! {‘put’, 27}, Box ! {‘take’, self()}, receive Value ➞ print(Value) end

26

box() ➞ empty(). empty() ➞ receive {‘put’, X} ➞ full(X) end. full(X) ➞ receive {‘take’, From} ➞ From ! X, empty(); {‘peek’, From} ➞ From ! {‘ok’, X}, full(X) end.

26
slide-60
SLIDE 60

Objects Interface Fixed API Actors Protocol API changes with internal state

27

27
slide-61
SLIDE 61

Objects Interface Fixed API Actors Protocol API changes with internal state

27

Anomaly

27
slide-62
SLIDE 62

28

28
slide-63
SLIDE 63

28

... each Smalltalk object is a recursion on the entire possibilities of the computer. Thus its semantics are a bit like having thousands and thousands of computers all hooked together by a very fast network. Alan Kay, Early History of Smalltalk

28
slide-64
SLIDE 64

28

Just a gentle reminder ... Smalltalk is NOT only its syntax or the class library, it is not even about classes. I'm sorry that I long ago coined the term "objects" for this topic because it gets many people to focus on the lesser idea. The big idea is "messaging" -- that is what the kernel of Smalltalk/Squeak is all about... Alan Kay, October 1998

28
slide-65
SLIDE 65

But isn’t this expensive?

29

29
slide-66
SLIDE 66

But isn’t this expensive?

29

Use Objects!

... heard in the ‘90s

29
slide-67
SLIDE 67

But isn’t this expensive?

29

Use Objects! 100.000’s of objects, are you crazy?

... heard in the ‘90s

29
slide-68
SLIDE 68

But isn’t this expensive?

29

Use Actors! 100.000’s of processes, silly you!

... heard yesterday

29
slide-69
SLIDE 69

“What if the OOP parts of other languages (Java, C++, Ruby, etc.) had the same behavior as their concurrency support? What if you were limited to only creating 500 objects total for an application because any more would make the app unstable and almost certainly crash it in hard-to-debug ways? What if these objects behaved differently on different platforms?”

Joe Armstrong, creator of Erlang

as quoted in http://weblog.hypotheticalabs.com/?p=217

30
slide-70
SLIDE 70

Effect Containment

■ Functional languages disallow effects ■ Many object-oriented styles encourage side effects. ■ Actors confine effects

31

m e t h

  • d

m e t h

  • d

m e t h

  • d

m e t h

  • d

data

  • 31
slide-71
SLIDE 71

From C++ to Java Garbage Collection From Java to Erlang State Containment

32

32
slide-72
SLIDE 72

Threads and Locks don’t compose well

■ Threaded programs are error prone (we already knew that). ■ Good thread design requires global knowledge.

33

33
slide-73
SLIDE 73

Threads and Locks don’t compose well

■ Threaded programs are error prone (we already knew that). ■ Good thread design requires global knowledge.

Anomaly

33

33
slide-74
SLIDE 74

Activity Composition

spawn

34

m e t h
  • d
m e t h
  • d
m e t h
  • d
m e t h
  • d
data
  • m
e t h
  • d
m e t h
  • d
m e t h
  • d
m e t h
  • d
data
  • 34
slide-75
SLIDE 75

Activity Composition

link

35

m e t h
  • d
m e t h
  • d
m e t h
  • d
m e t h
  • d
data
  • m
e t h
  • d
m e t h
  • d
m e t h
  • d
m e t h
  • d
data
  • 35
slide-76
SLIDE 76

Activity Composition

link

35

host host

m e t h
  • d
m e t h
  • d
m e t h
  • d
m e t h
  • d
data
  • m
e t h
  • d
m e t h
  • d
m e t h
  • d
m e t h
  • d
data
  • 35
slide-77
SLIDE 77

“Let it Fail” philosophy

36

m e t h

  • d

m e t h

  • d

m e t h

  • d

m e t h

  • d

data

36
slide-78
SLIDE 78

“Let it Fail” philosophy

■ Write code with lots of assertions

36

m e t h

  • d

m e t h

  • d

m e t h

  • d

m e t h

  • d

data

36
slide-79
SLIDE 79

“Let it Fail” philosophy

■ Write code with lots of assertions ■ Let a meta-level do fault handling

36

m e t h

  • d

m e t h

  • d

m e t h

  • d

m e t h

  • d

data

36
slide-80
SLIDE 80

“Let it Fail” philosophy

■ Write code with lots of assertions ■ Let a meta-level do fault handling ■ Defensive code is a symptom of a weak platform (segfaults, memory leaks, ...)

36

m e t h

  • d

m e t h

  • d

m e t h

  • d

m e t h

  • d

data

36
slide-81
SLIDE 81

“Let it Fail” philosophy

■ Write code with lots of assertions ■ Let a meta-level do fault handling ■ Defensive code is a symptom of a weak platform (segfaults, memory leaks, ...)

Anomaly

36

m e t h

  • d

m e t h

  • d

m e t h

  • d

m e t h

  • d

data

36
slide-82
SLIDE 82

Martin Fowler’s First Law of Distributed Objects Design

Steve Vinoski: RPC and its Offspring: Convenient, Yet Fundamentally Flawed rpc

37

Starbucks doesn’t use transactions

37
slide-83
SLIDE 83

Martin Fowler’s First Law of Distributed Objects Design

Steve Vinoski: RPC and its Offspring: Convenient, Yet Fundamentally Flawed rpc

Anomaly

37

Starbucks doesn’t use transactions

37
slide-84
SLIDE 84

Abstractions

38

38
slide-85
SLIDE 85

Abstractions

■ Any abstraction (hiding code) is problematic to distribute, persist, etc.

38

38
slide-86
SLIDE 86

Abstractions

■ Any abstraction (hiding code) is problematic to distribute, persist, etc. ■ You want to distribute/persist simple data (as in sql databases, document stores)

38

38
slide-87
SLIDE 87

Abstractions

■ Any abstraction (hiding code) is problematic to distribute, persist, etc. ■ You want to distribute/persist simple data (as in sql databases, document stores) ■ JSON’s popularity is a testament to this anomaly.

38

38
slide-88
SLIDE 88

Abstractions

■ Any abstraction (hiding code) is problematic to distribute, persist, etc. ■ You want to distribute/persist simple data (as in sql databases, document stores) ■ JSON’s popularity is a testament to this anomaly.

Anomaly

38

38
slide-89
SLIDE 89

Simple Values

39

39
slide-90
SLIDE 90

Simple Values

■ Tuple, List, Record, Number, String, Binary

39

39
slide-91
SLIDE 91

Simple Values

■ Tuple, List, Record, Number, String, Binary ■ Pattern matching is polymorphism for values

39

39
slide-92
SLIDE 92

Simple Values

■ Tuple, List, Record, Number, String, Binary ■ Pattern matching is polymorphism for values ■ Erlang data stores (like Mnesia) just store values, not bytes or objects.

39

39
slide-93
SLIDE 93

Simple Values

■ Tuple, List, Record, Number, String, Binary ■ Pattern matching is polymorphism for values ■ Erlang data stores (like Mnesia) just store values, not bytes or objects. ■ Too much of my Java programs are boilerplate code.

39

39
slide-94
SLIDE 94

“Object” Model Anomalies

■ Thread & Locks ■ Interfaces with Fixed API ■ Defensive Code ■ RPC/RMI ■ Boilerplate code for persistence

40

40
slide-95
SLIDE 95

Actor “Solutions”

■ Processes w/ state containment ■ Protocols ■ Let it Fail ■ Async Messaging ■ Send & store simple Data

41

41
slide-96
SLIDE 96

42

42
slide-97
SLIDE 97

43

Making reliable distributed control systems in the presence of errors

43
slide-98
SLIDE 98

43

Making reliable distributed control systems in the presence of errors

43
slide-99
SLIDE 99

43

Making reliable distributed control systems in the presence of errors

■ The “secret weapon” for Ericsson’s market leading, real-time telephony systems.

43
slide-100
SLIDE 100

43

Making reliable distributed control systems in the presence of errors

■ The “secret weapon” for Ericsson’s market leading, real-time telephony systems. ■ 20+ years of experience to learn from.

43
slide-101
SLIDE 101

44

Erlang/OTP

Open Telecommunications Platform ■ Embedded Distributed Systems ■ High Availability ■ In-Production Upgrades

44
slide-102
SLIDE 102

How to Learn Erlang

45

45
slide-103
SLIDE 103

How to Learn Erlang

Don’ t dissect a frog, Build One!

Nicolas Negroponte

45

45
slide-104
SLIDE 104

Your favorite OS BEAM Emulator Your Erlang Program Platform Framework

BEAM

BIFs

46

46
slide-105
SLIDE 105

Your favorite OS BEAM Emulator Your Erlang Program Platform Framework

BEAM

BIFs

46

46
slide-106
SLIDE 106

Java Virtual Machine Your favorite OS ERJANG

JVM

BIFs

47

Your Erlang Program Platform Framework

BEAM

47
slide-107
SLIDE 107

Kresten Krab Thorup Erlang Person of the Year, 2010

48
slide-108
SLIDE 108

OTP Actor Behaviors

■ Servers ■ Event Handlers ■ Finite State Machine ■ Supervisors ■ Networking: TCP , HTTP

49

49
slide-109
SLIDE 109

Tail Recursion

  • Tail recursion is critical to

programming Erlang processes

  • process enters a function
  • function acts on an incoming

message

  • as last action in the function, it calls

itself to handle the next message

50

50
slide-110
SLIDE 110

Essence of OTP Behaviors

loop(State) -> NewState = receive % handle messages here, % messages may affect State end, loop(NewState).

51

51
slide-111
SLIDE 111

loop(State) -> receive % handle messages here, % messages may affect State end, loop(NewState).

52

Essence of OTP Behaviors

52
slide-112
SLIDE 112

loop(State) -> receive % handle messages here, % messages may affect State end, loop(NewState).

53

Essence of OTP Behaviors

53
slide-113
SLIDE 113

loop(State) -> NState = receive % handle messages here, % messages may affect State end, loop(NewState).

54

Essence of OTP Behaviors

54
slide-114
SLIDE 114

loop(State) -> NState = receive % handle messages here, % messages may affect State end, loop(NState).

55

Essence of OTP Behaviors

55
slide-115
SLIDE 115

loop(State) -> NState = receive % handle messages here, % messages may affect State end, loop(NState).

56

Essence of OTP Behaviors

56
slide-116
SLIDE 116

loop(Callbacks, State) -> NState = receive Msg -> Callbacks:handle(Msg, State) end, loop(Callbacks, NState).

57

Essence of OTP Behaviors

57
slide-117
SLIDE 117

loop(Callbacks, State) -> NState = receive M1 -> Callbacks:handle1(M1,State); M2 -> Callbacks:handle2(M2,State); M3 -> Callbacks:handle3(M3,State) end, loop(Callbacks, NState).

58

Essence of OTP Behaviors

58
slide-118
SLIDE 118

loop(Callbacks, State) -> {Next, NState} = receive M1 -> Callbacks:handle_m1(M1,State); M2 -> Callbacks:handle_m2(M2,State); M3 -> Callbacks:handle_m3(M3,State) end, case Next of stop -> ok; _ -> loop(Callbacks, NState) end.

59

Essence of OTP Behaviors

59
slide-119
SLIDE 119

Behavior Loops

  • These are the basics
  • Actual OTP behavior loops are much

more sophisticated

  • gen_server, gen_fsm, supervisor, etc. all

assume specific callback functions, checked by the compiler

60

60
slide-120
SLIDE 120

Erlang Systems

61

61
slide-121
SLIDE 121

62

real problems that need to be solved to realize the potential of cloud computing

62
slide-122
SLIDE 122

62

real problems that need to be solved to realize the potential of cloud computing

62
slide-123
SLIDE 123

62

real problems that need to be solved to realize the potential of cloud computing

62
slide-124
SLIDE 124

62

real problems that need to be solved to realize the potential of cloud computing

62
slide-125
SLIDE 125

62

real problems that need to be solved to realize the potential of cloud computing

62
slide-126
SLIDE 126

62

real problems that need to be solved to realize the potential of cloud computing

62
slide-127
SLIDE 127

63

63
slide-128
SLIDE 128

63

63
slide-129
SLIDE 129

64

64
slide-130
SLIDE 130

64

Async Messaging

64
slide-131
SLIDE 131

64

Async Messaging State [Fault] Containment

64
slide-132
SLIDE 132

64

Async Messaging State [Fault] Containment Fault Monitoring

64
slide-133
SLIDE 133

65

65
slide-134
SLIDE 134

Common Medicine Card

66

66
slide-135
SLIDE 135

Common Medicine Card

66

66
slide-136
SLIDE 136

Common Medicine Card

67

67
slide-137
SLIDE 137

68

Who Else Uses Erlang?

68
slide-138
SLIDE 138

Advice for New Erlang Users

69

69
slide-139
SLIDE 139

Integration Using Erlang

70

70
slide-140
SLIDE 140

Integration Using Erlang

  • Integration often involves distribution

70

70
slide-141
SLIDE 141

Integration Using Erlang

  • Integration often involves distribution
  • Dealing with data: bit syntax, built-in

packet decoders (HTTP, FCGI, CDR)

70

70
slide-142
SLIDE 142

Integration Using Erlang

  • Integration often involves distribution
  • Dealing with data: bit syntax, built-in

packet decoders (HTTP, FCGI, CDR)

  • Trivial access to TCP, UDP

70

70
slide-143
SLIDE 143

Integration Using Erlang

  • Integration often involves distribution
  • Dealing with data: bit syntax, built-in

packet decoders (HTTP, FCGI, CDR)

  • Trivial access to TCP, UDP
  • Sync or async, easy event handling

70

70
slide-144
SLIDE 144

Integration Using Erlang

  • Integration often involves distribution
  • Dealing with data: bit syntax, built-in

packet decoders (HTTP, FCGI, CDR)

  • Trivial access to TCP, UDP
  • Sync or async, easy event handling
  • Application protocol handlers built

using gen_server or gen_fsm

70

70
slide-145
SLIDE 145

Integration Using Erlang

  • Often write little networked clients and

servers directly in the erl shell

  • Packet decoding and bit syntax sets

Erlang apart from netcat, perl, etc. in this regard

  • It’s like a middleware/coordination DSL

71

71
slide-146
SLIDE 146

dbg and Tracing

  • Erlang’s tracing is one of its most

amazing features

  • Learn the dbg module, you’ll use it

every day

  • I have needed the Erlang debugger
  • nly once, I always use dbg instead

72

72
slide-147
SLIDE 147

Advice for New Users

  • All that great stuff you’ve

heard about Erlang? It’s true

  • Simple concurrency and

coordination

  • Hot code loading
  • Always-available code

tracing

  • Sound, practical reliability
  • Easy integration
  • Enables “production

prototypes”

  • Open source at

github.com

  • Language and docs

available at erlang.org

73

73
slide-148
SLIDE 148

Warning: “Let It Crash”

  • This philosophy can be hard for non-

Erlangers to buy into

  • QA sees a crash in the log, they treat it as

something bad. Always.

  • explaining it was designed that way

doesn’t always fly

  • Programmers new to Erlang (or sometimes

not so new) always want to try to handle the errors instead

74

74
slide-149
SLIDE 149

But “Let It Crash” Works

  • Crash and recovery is invaluable for

early adopter customers

  • They keep using the system even if

something goes wrong

  • Most of the time, they’re unaware of

the crash/recovery

  • With dbg and hot code loading, you

can debug and repair live systems

75

75
slide-150
SLIDE 150

But Wait! There’s More

  • extensive library of useful modules
  • details of OTP applications, supervision,

code upgrade, hot code loading

  • ets and dets: Erlang Term Storage (in

memory) and Disk ets (persistent)

  • mnesia: distributed transactional database
  • rebar: open source build and dependency

management system

76

76
slide-151
SLIDE 151

Revolution?

Smalltalk

77

77
slide-152
SLIDE 152

Revolution?

Smalltalk

77

Java, Internet

77
slide-153
SLIDE 153

78

Java

78
slide-154
SLIDE 154

78

Multicore, Cloud Java

78
slide-155
SLIDE 155

78

Multicore, Cloud Java

■ Thread & Locks ■ Interfaces with Fixed API ■ Defensive Code ■ RPC/RMI ■ Boilerplate code for persistence

78
slide-156
SLIDE 156

78

Multicore, Cloud Java

■ Thread & Locks ■ Interfaces with Fixed API ■ Defensive Code ■ RPC/RMI ■ Boilerplate code for persistence

Anomalies

78
slide-157
SLIDE 157

78

Multicore, Cloud Java

■ Processes w/ state containment ■ Protocols ■ Let it Fail ■ Async Messaging ■ Send & store simple Data

Multicore, Cloud, Actors

  • Erlang
  • Erjang
  • Akka
78
slide-158
SLIDE 158

Read These

Also: http://learnyousomeerlang.com/

79

79
slide-159
SLIDE 159

Thanks

80