Beyond Fault Tolerance with Actor Programming
0 likes234 views
The document outlines a presentation by Fabio Tiriticco on reactive programming and actor programming, focusing on their roles in creating resilient systems. It discusses the principles of reactive systems and contrasts reactive programming with reactive systems, emphasizing benefits such as improved productivity and the management of complexity. Actor programming is highlighted as a method for achieving resilience, employing patterns like 'let it crash' for effective error handling.
Beyond Fault Tolerance with Actor Programming
- 1. HOW REACTIVE CAN YOU BE? AMSTERDAM 16-17th MAY 2017 Beyond Fault Tolerance: Achieve Resilience with Actor Programming
- 2. A little info about myself - Fabio Tiriticco Tech Lead / Software Architect @ticofab
- 5. 1. Reactive Programming 2. Reactive Systems 3. Reactive Programming vs Reactive Systems 4. Actor programming 5. Resilience through Actor Programming Outline
- 7. Reactive Programming & its benefits 1. Stream-like processing 2. Easy management of back pressure 3. Conciseness 4. Simplification of parallel / threaded work “A paradigm where the logic is driven forward by the availability of new information” “As soon as there is new input, react to it”
- 8. The World is a Streaming Place Many processes can be modelled as a stream.
- 9. The World is a Streaming Place Many processes can be modelled as a stream.
- 10. The World is a Streaming Place Many processes can be modelled as a stream.
- 11. The World is a Streaming Place
- 12. One challenge: different speed of producer and consumer 100 op/sec 10 op/sec Backpressure == “Dear sender, please slow down!”
- 13. Observable.from(myCats) Reactive Programming example (RxJava on Android) List<Cat> myCats; .subscribeOn(Schedulers.newThread()) .observeOn(AndroidSchedulers.mainThread()) .filter(cat -> cat.isWhite()) .map(cat -> cat.fetchPicture()) .map(picture -> Filter.applyFilter(picture)) .subscribe(filteredPicture -> display(filteredPicture)); .onBackpressureBuffer(16) 1. Stream-like processing 2. Conciseness 3. Simplification of threaded work 4. Easy management of back pressure
- 15. Goal “Reactive Systems strive to increase productivity and make sure that development and maintenance of components reduce the accidental complexity to a minimum.” the ability to react quickly and appropriately to change agility əˈdʒɪlɪti/ Software Architect increase productivity facilitate development facilitate maintenance reduce accidental complexity Company as whole
- 16. The Reactive Principles Define a way of thinking about system architectures in a modern and distributed environment. In a Reactive System, the interaction between the parts makes the difference.
- 17. The Reactive Manifesto, 2013 A reactive computer system must Trait React to its users Responsive React to failure and stay available Resilient React to varying load conditions Elastic Its components must react to inputs Message-driven
- 18. Reactive System traits (the Reactive Manifesto) J. Boner, R. Kuhn, D. Farley, M. Thompson - The Reactive Manifesto
- 19. 3. Reactive Programming vs Reactive Systems
- 20. Reactive Programming vs Reactive Systems What is Good for Applicability Productive for Reactive Programming Implementation technique Asynchronous dataflow management Single node or service Developers Reactive Systems Set of design principles Orchestration of complex systems The whole system (from single node to the total sum) Architects J. Boner, V. Klang - Reactive Programming vs Reactive Systems
- 21. From Principles to implementation Reactive Principles Reactive Patterns Reactive Tools R. Roestemburg, R. Bakker, R. Williams - Akka in action R. Kuhn, J. Allen, B. Hanafee - Reactive Design Patterns
- 22. Trait Business value Runs on the JVM Very mature runtime + compatibility with everything written in Java Higher level of abstraction Lifting the level of abstraction has proven to be the most effective measure in increasing the productivity of programmers. Functional programming Fosters reusability, composability, and it makes it easier to work in distributed, scalable systems. Separation between side effects and business logic. Encourages immutability Mutations are the most difficult thing to get right in distributed environments Concise Less code means less bugs, faster understanding and faster innovation Statically typed Compiler checks enable better performance, more testability and less bugs. The best ecosystem for data processing No need to cobble together tooling of various kinds Fun! Developers enjoy their work! Why Scala?
- 23. Why Scala? Scala: class Person(val name: String, val surname: String) Java: public class Person { private final String name; private final String surname; public Person(String name, String surname) { this.name = name; this.surname = surname; } public String getName() { return this.name; } public String getSurname() { return this.surname; } } • less code • thus simpler to understand • thus less bugs • thus less expensive • and enables faster innovation
- 24. Why Scala? D. Ghosh - Functional and Reactive Domain Modeling
- 26. Simple Component Pattern “One component should do only one thing but do it in full. The aim is to maximise cohesion and minimise coupling between components.”
- 27. Actor 1 Actor 3 Actor 2 • contains state & behaviour logic Actor model Supervisor Simple Component Pattern • has a mailbox to receive and send messages • has a supervisor myActor3.getCounter() 2 2
- 28. The benefits of Asynchronous Messaging • Separation between components • Sender - receiver interaction • Error containment - avoid chain failures • Domain mapping closer to reality Asynchronous messaging enables:Actor 1 Actor 3 Actor 2 Supervisor 2 2
- 29. Ping Pong Actor example Pong Actor Ping Actor Ping Pong(n)
- 30. 5. Achieve Resilience with Actor Programming
- 31. Let it Crash Pattern "Prefer a full component restart to complex internal failure handling". • failure conditions WILL occur • they might be rare and hard to reproduce • easier to start clean than to try to recover
- 32. Actor supervision example Actor 1 Actor 2 Supervisor WhateverException! X Restart (doing something else…)(yay!) Let it Crash Pattern
- 33. Scenario: The machine is out of coffee beans Failure! ( not an error ) Let it Crash Pattern
- 34. Let it Crash Pattern
- 35. The CoffeeMachine, implemented User Coffee Machine Supervisor Give Me Caffeine Here is your coffee
- 36. 1. Reactive Programming 2. Reactive Systems 3. Reactive Programming vs Reactive Systems 4. Actor programming 5. Resilience through Actor Programming Recap https://github.com/ticofab/ActorDemo
- 37. Thanks! @ticofab http://weeronline.nl All pictures belong to their respective authors