Microservices 101: Exploiting Reality's Constraints with Technology
•
21 likes•9,893 views
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.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (17)
More from Legacy Typesafe (now Lightbend)
More from Legacy Typesafe (now Lightbend) (13)
Recently uploaded
Recently uploaded (20)
Microservices 101: Exploiting Reality's Constraints with Technology
- 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.»
- 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"
- 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»
- 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 / λ
- 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
- 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"
- 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
- 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"
- 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 √
Editor's Notes
- 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 force Or 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 speeds Different 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: Concurrency Contention Coherency Beta = 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