Modern applications are required to do many tasks at the same time, in the optimal way, and be very quick to respond to consumers\u2019 input and expectations.<\/p>\n
Moreover, software<\/span> needs to adapt<\/b> to changing scenarios, in a consistent and resilient fashion.<\/p>\n Thanks to Charles Darwin, we all know that the ability to adapt is the key to evolution for the species of the animal realm. But what about software development?<\/p>\n What is the key to survive in the code jungle?<\/p>\n While there is not a single answer to this big question, you may find some inspiration at Codemotion Milan 2019<\/strong><\/a>, attending to Grace Jansen\u2019s talk Reacting to the future of application architecture<\/i><\/b> on what we can learn from s<\/i>uccessful biological models that are naturally occurring in our world (more info in the agenda<\/a>). Last tickets are still available: get yours here<\/a>!<\/p>\n In the meantime, we could ask ourselves: why are reactive systems<\/strong> so fashionable these days? The reactive paradigm looks like the key to manage the complexity<\/span> of modern software architecture, so it may be worth to have at least an overall understanding of its basic features<\/span>.<\/p>\n The reactive manifesto<\/a> describes what a reactive architecture looks like: responsive, resilient, elastic and message-driven. According to these principles, a reactive application should be conceived to work to its best, even under adverse conditions.<\/p>\n The manifesto really sounds like \u201ccounteracting to Murphy\u2019s law\u201d was a functional requirement<\/span> and the main cross-cutting concern of your application.<\/p>\n Kidding aside, there are indeed a lot of practical hints on how to pack all these good intentions into your design and the good news is that none of that is really brand-new. Being reactive, actually, is a matter of mindset, rather than technology.<\/p>\n We start analyzing these principles from the last one, because the message-driven concept is, under many aspects, the cornerstone of the whole reactive way of thinking.<\/p>\n A message-driven system is by definition, made up of parts or components that are exchanging information to carry out their work. In order to ensure responsiveness<\/span><\/i>, components must rely on asynchronous<\/b> message delivery.<\/p>\n With reference to the way messages propagates through the system, you can think of reactive design as a good match for microservices architectures<\/a>. Indeed, microservices provide a model for modular applications conceived as a set of distinct services inter-operating by means of lightweight communication protocols.<\/p>\n Most of the times, these protocols are based on RESTful APIs since they are stateless (i.e. lightweight on server side) and travel over HTTP requests that are by nature, asynchronous.<\/p>\n However, microservices architectures are not reactive by default, since there is no resilient<\/i> management<\/span> of messages. In this aspect, a reactive system typically adds to the microservices paradigm persistent or durable<\/b> message queues to implement fail recovery strategies.<\/p>\n Reactive systems embrace failure<\/span> as a fact, rather than a possibility. Hence the message system is also responsible to propagate errors in order to enable counteracting policies based on the feedback sent by each component.<\/p>\n In reactive jargon the so called back-pressure, is applied to manage varying workloads in a graceful fashion. That practically means that reactive systems need to be elastic<\/i>, hence scalable and distributed across a net of homogeneous nodes with no bottlenecks or central point of failures<\/span>.<\/p>\n In the latest years, containers<\/b> have proven to be a solid and cost-effective technology to deploy services and manage the effects of their eventual failures<\/span> in an automated fashion.<\/p>\n Therefore, many times, you will find that reactive systems are built on top of container cloud infrastructures.<\/p>\n So far, nothing is new and you can safely say that at architectural level, reactive design combines already existing technologies to fulfill its promises. You could indeed ask yourself which came first, reactive principles or reactive-enabling technologies?<\/p>\n Like the chicken and the egg, there is no definitive answer, but we can say for sure that all these abstract concepts must go down to actual code at some point, and that\u2019s where the term reactive <\/i>reaches the highest value in innovation.<\/p>\n The reactive manifesto qualifies the behavior that a system should exhibit to be reactive, but there is no specific description of how it is implemented.<\/p>\n As an example, reactive systems can be built on top of event-driven applications, using the well known Observer design pattern. Such implementations are commonly found in many frameworks based on Object Oriented Programming<\/span> languages, and they could theoretically fit in a reactive scenario too.<\/p>\n However, in the recent years we assisted to the rise of reactive programming<\/span> <\/b>as the new frontier in the implementation of distributed systems.<\/p>\n Reactive programming<\/span> provides an alternative data model foundation based on an abstraction called stream<\/b>. In other words, a stream<\/i> is to reactive programming what an object<\/i> is to OOP.<\/p>\n Streams are defined as sequences of values that evolve through time. Instead of interfacing to them with getter and setter methods in an imperative fashion like we are used to with objects in OOP, streams actively notify changes by means of subscriptions<\/b>.<\/p>\n With reference to the classic producer\/consumer scheme, when streams play the role of the producer they push<\/i> the information to their consumers as soon as it is available, instead of waiting for the consumer to pull<\/i> an update request.<\/p>\n Consumers can be in turn, other streams that transform the information received in some way and forward the results to other destinations.<\/p>\n But subscription in reactive programming<\/span> is not just a method to notify state changes. It is indeed a way to build effective data binding<\/b> between different entities addressing two of the major concerns of DDD (domain driven design) like isolation<\/i> and encapsulation<\/i> of data<\/span> at the same time.<\/p>\n Instead of relying on state propagation through the copy<\/b> of updated values after pull requests, subscription is implemented with the execution of asynchronous callbacks<\/b> every time a new value is pushed by a stream to its subscribers.<\/p>\n Callbacks execution, therefore, prevents the need to store a copy of data values just for the sake of encapsulation, making state propagation automatic and safe<\/b> as long as they do not have side effects<\/i> on the data<\/span> they receive.<\/p>\n In this sense, reactive state management is easily implemented according to the principles of referential transparency<\/i> of functional programming<\/span><\/a>. That practically means that callbacks are guaranteed to never change the values back in the source stream, thus ensuring isolation between subscribers and providing an improvement in the resiliency of the overall system without additional effort.<\/p>\n Beside that, streams are also called observables<\/b> since the subscription mechanism provides an effective way to link state changes to actions. Observability in turn, implies the ability not only to monitor<\/b> each part of the system but also to understand the reasons of eventual failures<\/span> just looking at its history. Aside resiliency, this also affects the elasticity<\/i> of the system, opening the way to the implementation of adaptive workload policies.<\/p>\n Streams provide a very high level of abstraction that makes them suitable to model every data source into a reactive system: variables, user input, data caches, sensor events or messages <\/b>that travel between components of the reactive system itself.<\/p>\n Hence reactive programming<\/span> is the founding paradigm of many frameworks that are conceived to support the development of reactive architectures with ad hoc<\/i> features.<\/p>\n Modelling our application on the base of streams of information is not an intuitive and easy task at first. Nevertheless, our everyday user experience<\/span> can give us a solid understanding of the abstract principles of the reactive manifesto.<\/p>\n Whenever we use an application that runs smoothly and consistently, rarely letting us down with some cryptic or vague error message, we know that we are probably dealing with a system designed to be reactive.<\/p>\n Responsiveness, resiliency and elasticity are desirable features<\/span> of every software application, hence in a certain way, we can tell that reactive architectures are a natural consequence of the goals that we set for our designs.<\/p>\n We know from biology that the term reactive qualifies a behavior.<\/p>\n In software development it translates into a set of emergent properties, rather than a specific technology. Nevertheless, some frameworks are based on abstractions that are more suitable than others to achieve reactive features<\/span>, hence the level of reactiveness actually depends on our attitude towards the integration of these new tools.<\/p>\n Don\u2019t miss the opportunity to learn more on how to integrate reactive design into your natural way of thinking attending to Grace Jansen\u2019s talk Reacting to the future of application architecture <\/i><\/b>at Codemotion Milan 2019<\/a>. Tickets are still available, get yours here<\/a>!<\/p>\n","protected":false},"excerpt":{"rendered":"Reactive systems for the masses<\/b><\/h2>\n
The devil is in the (implementation) details<\/b><\/h2>\n
Conclusions<\/b><\/h2>\n