Microservices 101: Exploiting Reality's Constraints with Technology
-
Upload
typesafeinc -
Category
Software
-
view
3.800 -
download
0
Transcript of 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√