Microservices 101: Exploiting Reality's Constraints with Technology

√Deputy CTO

@viktorklang

Microservices 101:Exploiting Reality's Constraints with Technology

2

Connectedness

«Software is becomingincreasingly interconnected»

4

Klang’s Conjecture

«If you cannot solve a problem without programming;you cannot solve a problem with programming.»

Reality Imaginary>

assert(nrOfDimensions > 0)

Reality• separation in space & time gives us

• communication for coordination

• variable delays

• partial failures

• partial/local/stale knowledge

9

10

System

«a set of things working together as parts of a mechanism or an interconnecting network;

a complex whole»

noun

Systems• Purpose is (typically) simple

• Complex inner workings

• Consist of collaborating components

• Components can be systems themselves

• Components are as simple as feasible,

but not simpler

11

12

Resilience

«Any sufficiently complex system is alwaysrunning in degraded mode»

— Richard I. Cook, MD “How complex systems fail” (paraphrased)

13

Conway’s Law

«Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations» —

Melvin Conway

Communication• The production and consumption of messages

• Messaging means that we need to be able to address recipients

• Addresses/Identities are important!

• They are knowledge that can be shared

• Messages can become lost, delayed or misunderstood

14

Think ‘Reliability’• Are we ever guaranteed delivery?

• at-most-once

• at-least-once

• exactly-once

• It’s not about guarantees,it’s about reliability

15

Two-faced Commit

16

Encoding & Medium• Embrace protocols

• Overcome the fear of using multiple media• Removes the single-point of failure

• No encoding is one-size-fits-all

• Allow protocols to evolve over time

17

Quiz!

299 792 458

340.29

~0.4

Scharnowski et al., 2009; Heinen, Jolij, & Lamme, 2005

22

Universal Scalability Law

«N is the number of users;or the number of CPUs, is the contention level,α the coherency latency.β

C is the relative capacity»

Perfect

23

Load

Throughp

ut

Imperfect

24

Load

Throughp

ut

Bounded

25

Load

Throughp

ut

Regressive

26

Load

Throughp

ut

Discovery is EC• Since knowledge is always

local/partial/stale

• Discovery of components must embraceeventual consistency

• Conflict-Free Replicated Datatypes(CRDTs) show great promise here

27

Latency is

the enemyof responsiveness

Expectation management

• To humans, fast & slow is about perception

• Manageable

• The key is consistency—because reliability

• Not the same for machine-to-machine

29

Burstiness• Most communication is bursty

• Some is predictable

• Some is not

• requires flow control

• can leverage elasticity

• load shedding can cause burstiness

30

31

Little’s Law

«L is mean length;λ is effective arrival rate;W is mean time spent»

L=λW

32

Little’s Law

«L is mean length;λ is effective arrival rate;W is mean time spent»

W=L / λ

Flow control / Back pressure

34

• Buffers are only grease between cogs

• They do not solve overload problems

• Load shedding does not inform sender

• When possible, use effectively bounded, asynchronous, non-blocking, demand-driven back pressure

www.reactive-streams.org

36

Requirements Push Pull

support potentially unbounded sequences 😃 😃

sender runs separately from receiver 😃 😃

rate of reception may vary from rate of sending 😃 😃

dropping elements should be a choice and not a necessity 💩 😃

minimal (if any) overhead in terms of latency and throughput 😃 💩

Comparing Push vs Pull

&37

Supply

Demand

38

Publisher Subscriber

data

demand

• “push” when subscriber is faster

• “pull” when publisher is faster

• switches automatically between both

• batching demand allows batching ops

39

DynamicPush–Pull

Reactive Streams

40

Requirements Push Pull Both

support potentially unbounded sequences 😃 😃 😃

sender runs separately from receiver 😃 😃 😃

rate of reception may vary from rate of sending 😃 😃 😃

dropping elements should be a choice and not a necessity 💩 😃 😃

minimal (if any) overhead in terms of latency and throughput 😃 💩 😃

Comparing Push vs Pull vs Both

🌟

Stream splitting

41

demand

data

splitting the data means merging the demand

Stream merging

42

merging the data means splitting the demand

Collaboration• Assume no malice

• Sanity check inputs & outputs

• Never wait forever or actively

• There’s always a Plan B

43

44

Circuit Breakers

Responsibility• Having multiple responsibilities

• creates conflict regarding priorities

• lowers reliability

• increases accidental damage

• decreases predictability

• hides the cause from the outside

45

Resilience• Never assume that other entities are immortal

• Treat expectation violations as failures

• Always have a Plan B

• Clients are not responsible to fix a faulty provider

• Fail fast & predictably

46

49

☠

Zombie Apocalypse

50

Supervision• Responsibility to deal with the failure/corruption of other

• Does not place the burden of fixing it on the collaborators

«Quis custodiet ipsos custodes?»— Decimus Iunius Iuvenalis

Harden up• Isolate

• Replicate

• Shard

• Control flow

• Predict changes in load

• React to changes in load

51

53

E l a s t i c i t y

«Lagom is a Swedish word, meaning "just the right amount"»

— Wikipedia

• Mind shift in going async

• Mind shift in dealing with failure

• Importance of appropriate configuration

• Integration using blocking APIs requires care

• Avoid the distributed monolith

• Deployment requires modern tooling

55

Transitioning

Summary• Isolate & Contain + Distribute & Replicate

• Single Purpose Components

• Communicate asynchronously

• Divide & Conquer

• Avoid coordination & minimize contention

• Embrace inconsistency

• Strive for lagom amount of utilisation

56

The Reactive Traits

www.reactivemanifesto.org

Perhaps you’d also like…

MADE FOR MICROSERVICES

WEBINAR: Introducing Typesafe ConductR

WATCH NOW

ACTIVATOR TEMPLATE

Try this Microservices Seed Project

CHECK IT OUT

HAVE QUESTIONS?

Get in touch with Typesafe today!

CONTACT US

©Typesafe 2015 – All Rights Reserved√