How Reactive Principles Provide A Systematic Approach to Uncertainty: Q/A with Sergey Bykov
The Reactive Principles, a new set of guidelines and techniques published by the Reactive Foundation, incorporate the ideas and patterns from both Reactive Programming and Reactive Systems into a set of practical software design principles. These principles distill the experiences of leading experts from the broader distributed systems communities into a collection of principles and patterns for building Cloud Native, Edge Native, and Internet of Things (IoT) applications.
In this post, I catch up with Sergey Bykov, one of the founders of the Orleans project at Microsoft Research, distributed systems engineer, and contributor to The Reactive Principles. We discuss his introduction to Reactive programming, why a disciplined, systematic approach to uncertainty is a necessary aspect for distributed systems, and the practical challenges Reactive principles solve in everyday enterprise environments.
How did you get introduced to Reactive Programming/Reactive Systems?
SB: I've seen what happens when cloud services are built without the Reactive Principles in mind. I watched a service melting down on the day of a major promotional campaign and staying down until it was mostly over.
In another case, I experienced firsthand that a good intention to provide a strong message ordering guarantee can inadvertently cause a memory leak and force engineers to recycle the service every eight hours. These experiences made me more receptive to the wisdom of the Reactive Principles.
What makes the Reactive principles and patterns so important for building distributed systems?
SB: Distributed systems force developers to make a quantum leap from the relative certainty of a single machine or process to the byzantine interactions of interconnected subsystems, where we cannot stop the world to take a snapshot of it or to make it move one step at a time.
This fundamental degree of uncertainty demands discipline and systematic approach to manage the inherent complexity of the systems, to separate and isolate major concerns and fault domains, to achieve predictable performance and scalability characteristics. Reactive principles and patterns capture a good swath of the wisdom that the industry has accumulated over the decades to make applying those learnings and avoiding typical mistakes easier and more consistent.
What practical challenges do the Reactive principles and patterns solve in everyday enterprise environments?
SB: As in cases of other sets of principles and patterns, I think the first step is to establish a common taxonomy, so that architectural discussions could be had using a consistent language and a shared understanding.
On that basis, the principles and patterns offer the list of concerns that are typically the highest priority. That helps focus design decisions and tradeoffs on what matters the most for the technical success of a project.
Lastly, the principles could be used as a 'pre-flight checklist' to verify that no major known concern was overlooked while architecting and building a system.
In your opinion, what makes the Reactive principles and patterns such a good fit for cloud native applications?
SB: Cloud takes the challenges of distributed systems to the extreme. Resources we use in the cloud are not only distributed, they live in a fundamentally multi-tenanted environment shared with an invisible number of other applications. We cannot expect complete performance and fault isolation or direct access, unlike in private data centers.
As a result, cloud native applications are architected to run on an elastic set of 'commodity' resources that may intermittently fail or become unavailable. This forces such applications to be partitioned into chunks that execute mostly independently, to expect failure as a fact of life, to anticipate variable load and the need to scale up and down.
That's exactly where the Reactive principles I believe can help make those individual design decisions systematically and coherently.
How do you recommend software architects and developers get started using these principles and patterns?
SB: I think in some cases it might be easier to start from the 'checklist' approach - to see if the system my organization is already running violates any of the principles. If it does, it's important to answer the question if that was a result of a conscious tradeoff or something that got overlooked or accidentally happened or maybe not even a concern.
Starting from a system that the team is already well familiar with and cross-checking it against the principles could be an easier way to build a shared understanding and interpretation of them for the team. I suspect this should make it easier for the team to apply the principles later to new designs and architectures.
Mark your calendar for Reactive Summit, a one-day virtual conference on Tuesday, November 10th hosted by the Reactive Foundation and focused on Reactive principles, patterns, and projects. I hope you can make it!