In this webinar slideshow, Typesafe Deputy CTO Viktor Klang looks into the world of microservices to see how these architectures emerge from the constraints of reality. We'll review the problems imposed by reality, and show how they can not only be solved, but how the constraints free us from misconceptions that are otherwise very easy to acquire.
We will also explore how distributed systems are at the heart of microservices-based architectures and how communication shapes the structure, behavior and development of the software.
9. Reality
• separation in space & time gives us
• communication for coordination
• variable delays
• partial failures
• partial/local/stale knowledge
9"
10. 10"
System
«a set of things working together as parts of a
mechanism or an interconnecting network;
a complex whole»
noun
11. 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"
13. 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
14. 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"
15. 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"
17. 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"
22. 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»
27. Discovery is EC
• Since knowledge is always local/partial/
stale
• Discovery of components must embrace
eventual consistency
• Conflict-FreeReplicatedDatatypes
(CRDTs) show great promise here
27"
29. Expectation management
• To humans, fast & slow is about perception
• Manageable
• The key is consistency—because reliability
• Not the same for machine-to-machine
29"
30. Burstiness
• Most communication is bursty
• Some is predictable
• Some is not
• requires flow control
• can leverage elasticity
• load shedding can cause burstiness
30"
31. 31"
Little’s Law
«L is mean length;
λ is effective arrival rate;
W is mean time spent»
L=λW
32. 32"
Little’s Law
«L is mean length;
λ is effective arrival rate;
W is mean time spent»
W=L / λ
34. 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.reac:veBstreams.org"
36. 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
39. • “push” when subscriber is faster
• “pull” when publisher is faster
• switches automatically between both
• batching demand allows batching ops
39"
Dynamic
Push–Pull
Reactive Streams
40. 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
#"
45. Responsibility
• Having multiple responsibilities
• creates conflict regarding priorities
• lowers reliability
• increases accidental damage
• decreases predictability
• hides the cause from the outside
45"
46. 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"
50. 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
52. 52"
An escalator can never break:
it can only become stairs.
You should never see an
Escalator Temporarily Out Of
Order sign,
just Escalator Temporarily Stairs.
Sorry for the convenience.
– Mitch Hedberg
“
”
53. 53"
E l a s t i c i t y
«Lagom is a Swedish word,
meaning "just the right amount"»
— Wikipedia
55. • 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
58. REACTIVE PLATFORM
Full Lifecycle Support for Play, Akka, Scala and Spark
Give your project a boost with Reactive Platform:
• Monitor Message-Driven Apps
• Resolve Network Partitions Decisively
• Integrate Easily with Legacy Systems
• Eliminate Incompatibility & Security Risks
• Protect Apps Against Abuse
• Expert Support from Dedicated Product Teams
Enjoy learning? See about the availability of
on-site training for Scala, Akka, Play and Spark!
Learn more about our offersCONTACT US
This means that software is -collaborating- in an increasing rate.
Collaboration is at the very heart of this growing world of software.
Communication is at the very heart of collaboration.
Programmers, my self included, all too often jump too quickly into code.
It is worth reminding oneself that programming is “merely” the encoding of a solution for a machine to execute.
The solution ALWAYS exists outside of the code itself.
The point being that it is helpful to ask oneself early—how would I solve this -without- writing any code?
Programmers, my self included, all too often jump too quickly into code.
It is worth reminding oneself that programming is “merely” the encoding of a solution for a machine to execute.
The solution ALWAYS exists outside of the code itself.
The point being that it is helpful to ask oneself early—how would I solve this -without- writing any code?
Programmers, my self included, all too often jump too quickly into code.
It is worth reminding oneself that programming is “merely” the encoding of a solution for a machine to execute.
The solution ALWAYS exists outside of the code itself.
The point being that it is helpful to ask oneself early—how would I solve this -without- writing any code?
Perhaps not a bold assertion, but let’s think about it like this:
No matter how wonderful the imaginary is, the constraints of reality cannot cease to exist.Being aware of the constraints of reality is -essential- to being able to reason about the viability of solutions. Not only from the initial outset of the project—but laid out over the projected lifetime of it.
Alright, so do we all agree that in what we call Reality, we have multiple dimensions?
What things do we get from that?
Comm for Coo:
So given that entities do not exist in the same place, it means that they need to communicate if they want to coordinate -anything-.
Delays:
Ever observed a race-condition that as you tried to fix it just became less likely?
That’s shortened delays—making the window of opportunity smaller but still possible.
Partial failures:
Since things do not exist in the same location, they especially if collaborating on something, will risk failing individually—where one succeeded and one failed, for example.
Knowledge:
Since communication is how we coordinate, it is also how we coordinate -information-, and since we have delays and partial failures, we will only ever have a subjective view of the world, one that is bound to be incomplete and stale.
System: noun, “a set of things working together as parts of a mechanism or an interconnecting network; a complex whole.”
What’s a system?We build systems, right? Computer systems?
Are you a system?
Are you a component within a system?
Is everything systems within systems within systems within…
A mechanical watch has a very simple purpose,
but a watch movement has complex inner workings,consists of a lot of small mechanical components that communicate via forceOr the Google Search bar — and whatever kind of beast that powers it :)
This means that software is -collaborating- in an increasing rate.
Collaboration is at the very heart of this growing world of software.
Communication is at the very heart of collaboration.
Why? Because, as we’ve discussed, communication is -essential- for collaboration, and organization is ALL about collaboration
Different media have different transport speedsDifferent media have different reception rates & delays
speed of light in vacuum in meters per second
speed of sound at sea level in meters per second
Recent
studies have shown that it can take up to almost 400 msec
before visual information is available for conscious report
(e.g., Scharnowski et al., 2009; Heinen, Jolij, & Lamme, 2005).
The 3 C’s:ConcurrencyContention
CoherencyBeta = 0 == Amdahl’s Law
Little's Law tells us that the average number of customers in the store L, is the effective arrival rate λ, times the average time that a customer spends in the store W, or simply:
If we observe an effective arrival rate and a mean length, we can calculate the mean time spent
the crucial addition is to make the exchange bidirectional, and explicitly so
message-passing between publisher and subscriber allows asynchronous non-blocking back pressure
. data items flow downstream
. demand flows upstream
. data items flow only when there is demand
. recipient is in control of incoming data rate
. data in flight is bounded by signaled demand
What I have described here for you today, is the essence of the Reactive Manifesto