Aleksey Izmailov Jan 2019
§ Reactive Programming is a distinct subset of Reactive Systems at the implementation level. § Reactive Programming offers productivity for Developers—through performance and resource efficiency—at the component level for internal logic and dataflow management. § Reactive Systems offers productivity for Architects and DevOps—through resilience and elasticity—at the system level, for building “Cloud Native” or other large-scale distributed systems.
https://www.reactivemanifesto.org
Reactive Systems are … Responsive Responsive: The system responds in a timely manner if at all possible. Responsiveness is the cornerstone of usability and utility, but more than that, responsiveness means that problems may be detected quickly and dealt with effectively. Responsive systems focus on providing rapid and consistent response times, establishing reliable upper bounds so they deliver a consistent quality of service. This consistent behaviour in turn simplifies error handling, builds end user confidence, and encourages further interaction.
Reactive Systems are: … Resilient Resilient: The system stays responsive in the face of failure. This applies not only to highly- available, mission-critical systems — any system that is not resilient will be unresponsive after a failure. Resilience is achieved by replication, containment, isolation and delegation. Failures are contained within each component, isolating components from each other and thereby ensuring that parts of the system can fail and recover without compromising the system as a whole. Recovery of each component is delegated to another (external) component and high-availability is ensured by replication where necessary. The client of a component is not burdened with handling its failures.
Reactive Systems are … Elastic Elastic: The system stays responsive under varying workload. Reactive Systems can react to changes in the input rate by increasing or decreasing the resources allocated to service these inputs. This implies designs that have no contention points or central bottlenecks, resulting in the ability to shard or replicate components and distribute inputs among them. Reactive Systems support predictive, as well as Reactive, scaling algorithms by providing relevant live performance measures. They achieve elasticity in a cost-effective way on commodity hardware and software platforms.
Reactive Systems are … Message Driven Message Driven: Reactive Systems rely on asynchronous message- passing to establish a boundary between components that ensures loose coupling, isolation and location transparency. This boundary also provides the means to delegate failures as messages. Employing explicit message-passing enables load management, elasticity, and flow control by shaping and monitoring the message queues in the system and applying back-pressure when necessary. Location transparent messaging as a means of communication makes it possible for the management of failure to work with the same constructs and semantics across a cluster or within a single host. Non- blocking communication allows recipients to only consume resources while active, leading to less system overhead.
Idea?! It is time to apply these design principles consciously from the start instead of rediscovering them each time.
Asynchrony, in computer programming, refers to the occurrence of events independent of the main program flow and ways to deal with such events. These may be "outside" events such as the arrival of signals, or actions instigated by a program that take place concurrently with program execution, without the program blocking to wait for results.
import requests r = requests.get('https://api.github.com’) f = open(“workfile”,”r”) predict( x, batch_size=None, verbose=0, steps=None, max_queue_size=10, workers=1, use_multiprocessing=False ) def create_connection(db_file): try: conn = sqlite3.connect(db_file) return conn except Error as e: print(e) return None def select_all_tasks(conn): cur = conn.cursor() cur.execute("SELECT * FROM tasks") rows = cur.fetchall() for row in rows: print(row)
The Application Program Interface (API) for Reactive Programming libraries are generally either: § Callback-based—where anonymous, side-effecting callbacks are attached to event sources, and are being invoked when events pass through the dataflow chain. § Declarative—through functional composition, usually using well established combinators like map, filter, fold etc.
§ Futures/Promises—containers of a single value, many-read/single-write semantics where asynchronous transformations of the value can be added even if it is not yet available. § Streams—as in Reactive Streams: unbounded flows of data processing, enabling asynchronous, non-blocking, back-pressured transformation pipelines between a multitude of sources and destinations. § Dataflow Variables—single assignment variables (memory-cells) which can depend on input, procedures and other cells, so that changes are automatically updated. A practical example is spreadsheets—where the change of the value in a cell ripples through all dependent functions, producing new values “downstream.”
Messages have a clear, single, destination; while Events are facts for others to observe. Event-driven system focuses on addressable event sources while a message- driven system concentrates on addressable recipients. In a Reactive System, especially one which uses Reactive Programming, both events and messages will be present—as one is a great tool for communication (messages), and another is a great way of representing facts (events).
The foundation for a Reactive System is Message-Passing, which creates a temporal boundary between components which allows them to be decoupled in: § time—this allows for concurrency § space—which allows for distribution and mobility. This decoupling is a requirement for full isolation between components, and forms the basis for both Resilience and Elasticity.
Reactive Programming is a great technique for managing internal logic and dataflow transformation, locally within the components, as a way of optimizing code clarity, performance and resource efficiency. Reactive Systems, being a set of architectural principles, puts the emphasis on distributed communication and gives us tools to tackle resilience and elasticity in distributed systems.
§ Reactive Programming is used within a single Microservice to implement the service-internal logic and dataflow management. § Reactive Systems design is used in between the Microservices, allowing the creation of systems of Microservices that play by the rules of distributed systems—Responsiveness through Resilience and Elasticity made possible by being Message-Driven.
§ Reactive Programming versus Reactive Systems. Landing on a set of simple Reactive design principles in a sea of constant confusion and overloaded expectations By Jonas Bonér and Viktor Klang, Lightbend Inc. – Most of the text and pictures are copied from this resource. § Concurrency: The Good, The Bad and The Ugly. By Viktor Klang and Roland Kuhn (https://www.youtube.com/watch?v=OJfS7K-Vkgk). § Wikipedia. § Scala and Akka documentation. § Some images are taken from public Internet.

Reactive: Programming -> Systems -> Architecture

  • 1.
  • 2.
    § Reactive Programmingis a distinct subset of Reactive Systems at the implementation level. § Reactive Programming offers productivity for Developers—through performance and resource efficiency—at the component level for internal logic and dataflow management. § Reactive Systems offers productivity for Architects and DevOps—through resilience and elasticity—at the system level, for building “Cloud Native” or other large-scale distributed systems.
  • 3.
  • 4.
    Reactive Systems are … Responsive Responsive: The systemresponds in a timely manner if at all possible. Responsiveness is the cornerstone of usability and utility, but more than that, responsiveness means that problems may be detected quickly and dealt with effectively. Responsive systems focus on providing rapid and consistent response times, establishing reliable upper bounds so they deliver a consistent quality of service. This consistent behaviour in turn simplifies error handling, builds end user confidence, and encourages further interaction.
  • 5.
    Reactive Systems are: … Resilient Resilient: The systemstays responsive in the face of failure. This applies not only to highly- available, mission-critical systems — any system that is not resilient will be unresponsive after a failure. Resilience is achieved by replication, containment, isolation and delegation. Failures are contained within each component, isolating components from each other and thereby ensuring that parts of the system can fail and recover without compromising the system as a whole. Recovery of each component is delegated to another (external) component and high-availability is ensured by replication where necessary. The client of a component is not burdened with handling its failures.
  • 6.
    Reactive Systems are … Elastic Elastic: The systemstays responsive under varying workload. Reactive Systems can react to changes in the input rate by increasing or decreasing the resources allocated to service these inputs. This implies designs that have no contention points or central bottlenecks, resulting in the ability to shard or replicate components and distribute inputs among them. Reactive Systems support predictive, as well as Reactive, scaling algorithms by providing relevant live performance measures. They achieve elasticity in a cost-effective way on commodity hardware and software platforms.
  • 7.
    Reactive Systems are … Message Driven Message Driven: ReactiveSystems rely on asynchronous message- passing to establish a boundary between components that ensures loose coupling, isolation and location transparency. This boundary also provides the means to delegate failures as messages. Employing explicit message-passing enables load management, elasticity, and flow control by shaping and monitoring the message queues in the system and applying back-pressure when necessary. Location transparent messaging as a means of communication makes it possible for the management of failure to work with the same constructs and semantics across a cluster or within a single host. Non- blocking communication allows recipients to only consume resources while active, leading to less system overhead.
  • 8.
    Idea?! It istime to apply these design principles consciously from the start instead of rediscovering them each time.
  • 9.
    Asynchrony, in computerprogramming, refers to the occurrence of events independent of the main program flow and ways to deal with such events. These may be "outside" events such as the arrival of signals, or actions instigated by a program that take place concurrently with program execution, without the program blocking to wait for results.
  • 11.
    import requests r =requests.get('https://api.github.com’) f = open(“workfile”,”r”) predict( x, batch_size=None, verbose=0, steps=None, max_queue_size=10, workers=1, use_multiprocessing=False ) def create_connection(db_file): try: conn = sqlite3.connect(db_file) return conn except Error as e: print(e) return None def select_all_tasks(conn): cur = conn.cursor() cur.execute("SELECT * FROM tasks") rows = cur.fetchall() for row in rows: print(row)
  • 12.
    The Application ProgramInterface (API) for Reactive Programming libraries are generally either: § Callback-based—where anonymous, side-effecting callbacks are attached to event sources, and are being invoked when events pass through the dataflow chain. § Declarative—through functional composition, usually using well established combinators like map, filter, fold etc.
  • 13.
    § Futures/Promises—containers ofa single value, many-read/single-write semantics where asynchronous transformations of the value can be added even if it is not yet available. § Streams—as in Reactive Streams: unbounded flows of data processing, enabling asynchronous, non-blocking, back-pressured transformation pipelines between a multitude of sources and destinations. § Dataflow Variables—single assignment variables (memory-cells) which can depend on input, procedures and other cells, so that changes are automatically updated. A practical example is spreadsheets—where the change of the value in a cell ripples through all dependent functions, producing new values “downstream.”
  • 23.
    Messages have aclear, single, destination; while Events are facts for others to observe. Event-driven system focuses on addressable event sources while a message- driven system concentrates on addressable recipients. In a Reactive System, especially one which uses Reactive Programming, both events and messages will be present—as one is a great tool for communication (messages), and another is a great way of representing facts (events).
  • 24.
    The foundation fora Reactive System is Message-Passing, which creates a temporal boundary between components which allows them to be decoupled in: § time—this allows for concurrency § space—which allows for distribution and mobility. This decoupling is a requirement for full isolation between components, and forms the basis for both Resilience and Elasticity.
  • 25.
    Reactive Programming isa great technique for managing internal logic and dataflow transformation, locally within the components, as a way of optimizing code clarity, performance and resource efficiency. Reactive Systems, being a set of architectural principles, puts the emphasis on distributed communication and gives us tools to tackle resilience and elasticity in distributed systems.
  • 26.
    § Reactive Programmingis used within a single Microservice to implement the service-internal logic and dataflow management. § Reactive Systems design is used in between the Microservices, allowing the creation of systems of Microservices that play by the rules of distributed systems—Responsiveness through Resilience and Elasticity made possible by being Message-Driven.
  • 28.
    § Reactive Programmingversus Reactive Systems. Landing on a set of simple Reactive design principles in a sea of constant confusion and overloaded expectations By Jonas Bonér and Viktor Klang, Lightbend Inc. – Most of the text and pictures are copied from this resource. § Concurrency: The Good, The Bad and The Ugly. By Viktor Klang and Roland Kuhn (https://www.youtube.com/watch?v=OJfS7K-Vkgk). § Wikipedia. § Scala and Akka documentation. § Some images are taken from public Internet.