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.

1. √
Deputy CTO
@viktorklang
Microservices 101:
Exploiting Reality's Constraints with Technology

2. 2"
Connectedness
«Software is becoming
increasingly interconnected»

3. 3"
Klang’s Conjecture
«If you cannot solve a problem without programming;
you cannot solve a problem with programming.»

4. 4"
Klang’s Conjecture
«If you cannot solve a problem without programming;
you cannot solve a problem with programming.»

5. 5"
Klang’s Conjecture
«If you cannot solve a problem without programming;
you cannot solve a problem with programming.»

6. Reality Imaginary
>

8. assert(nrOfDimensions > 0)

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"

12. 12"
Resilience
«Any sufficiently complex system is always
running in degraded mode»
— Richard I. Cook, MD “How complex systems fail” (paraphrased)

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"

16. Two-faced Commit
16"

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"

18. Quiz!

19. 299 792 458

20. 340.29

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

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»

23. Perfect
23"
Throughput"
Load"

24. Imperfect
24"
Throughput"
Load"

25. Bounded
25"
Throughput"
Load"

26. Regressive
26"
Throughput"
Load"

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"

28. Latency is
the enemy
of responsiveness

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 / λ

33. Hockey!
33"
Response":me"
Queue"length"

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"

35. No flow control, you say?

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

37. & 37"
Supply
Demand

38. 38"
Publisher" Subscriber"
data"
demand"

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
#"

41. Stream splitting
41"
demand
data
splitting the data means merging the demand

42. Stream merging
42"
merging the data means splitting the demand

43. Collaboration
• Assume no malice
• Sanity check inputs & outputs
• Never wait forever or actively
• There’s always a Plan B
43"

44. 44"
Circuit Breakers

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"

47. 47"
Postel’s Law
«Be conservative in what you do, be liberal in what you
accept from others.» — Jon Postel

48. Reduces chatter == lowers latency

49. 49"
"
Zombie Apocalypse

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

51. Harden up
• Isolate
• Replicate
• Shard
• Control flow
• Predict changes in load
• React to changes in load
51"

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

54. 54"
Adoption

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

56. 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"

57. The Reactive Traits
www.reac:vemanifesto.org"

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

59. ©Typesafe 2015 – All Rights Reserved
√