Microservices 101: Exploiting Reality's Constraints with Technology
21 likes9,898 views
The document discusses the complexities and challenges of modern software systems, emphasizing the importance of connectivity, communication, and reliability in microservices. Key concepts include Conway's Law, resilience in system design, and the dynamics of push-pull communication models. It advocates for adopting reactive principles and asynchronous communication to enhance system effectiveness and manage failure more adeptly.
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
- #3: 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.
- #4: 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?
- #5: 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?
- #6: 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?
- #7: 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.
- #10: 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.
- #11: 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âŠ
- #12: 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 :)
- #13: 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.
- #14: Why? Because, as weâve discussed, communication is -essential- for collaboration, and organization is ALL about collaboration
- #19: Different media have different transport speeds Different media have different reception rates & delays
- #20: speed of light in vacuum in meters per second
- #21: speed of sound at sea level in meters per second
- #22: 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).
- #23: The 3 Câs: Concurrency Contention Coherency Beta = 0 == Amdahlâs Law
- #32: 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:
- #33: If we observe an effective arrival rate and a mean length, we can calculate the mean time spent
- #38: 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
- #58: What I have described here for you today, is the essence of the Reactive Manifesto