Reactive Microservices - 1

Prologue

The term reactive is ubiquitous. Everything from architecture to frameworks, to the general concepts, seems to refer to this term. Quite obviously, reactive has assumed many meanings and definitions and can be understood under a certain context. This article aims to dive deep into what being reactive means and to explore the various contexts where this idea is used. In particular, the article aims to explore the relationship between microservices and reactive and attempt to define what reactive microservices are.

Reactive Systems — Introduction

The operating environment of enterprises today has complexity as a norm. Cloud Computing, Multiple device types (desktops, mobile devices, wearables, Sensors, Gaming Consoles, Smart Homes), near-zero downtime, low latency & petabytes of data processing are few characteristics that have led to a world of services where the experience and expectations of a consumer have changed. In addition, the number of users has increased manifold and these users are always connected.

Organizations are looking for high service availability and also to innovate rapidly.

The traditional N-Tier, CRUD-based application design, simply does not address the challenges of this new reality. The architecture patterns, data processing, and scaling demands need a new approach of distributed systems to address these challenges.

To cater to such demands on the applications, enterprises have been adopting new architecture thinking, that:

• Leverages distributed compute resources at scale
• Is explicit about failures
• Is inherently asynchronous and non-blocking
• Removes all contentions from the systems aiming to leverage resilience and availability from such an approach.

Thus, modern enterprise systems are distributed from the ground up. Operating services in a distributed architecture is a challenge and opportunity both. Bringing all the features of this new architecture paradigm into a unified definition is Reactive Manifesto. Reactive manifesto underlines the traits of Responsive, Resilience, Elastic, Message Driven in a reactive system.

Reactive — Reacts to What?

Responsive: React to User. The system should provide consistent response times and quality of service.

Elastic: Reacts to load. The system should stay respond under varying workloads

Resilient: Reacts to failures. the system should stay response in event of failures

Message-Driven: Reacts to Messages. The system should establish asynchronous message passing.

Reactive architecture embraces the inherent nature of distributed systems i.e.

• Unreliability of network,
• Latency of data across the network,
• Failures in parts of systems,
• Eventual consistency of data

This nature of distributed systems was presented as a set of “fallacies” in a 1994 Sun Microsystems paper — Fallacies of Distributed Computing.

Traditional architectures attempted to hide these fallacies with patterns like 2PC XA/Distributed Transactions, WS-Coordination, Other WS-*, CORBA, etc. These patterns treated communication across services as if these were local method calls by disguising the network calls as method calls within JVM and making a big assumption that the network is always reliable. Reactive Systems are explicit about the network & failures and make them a part of the “flow”. In a distributed system like a microservice, there is no guarantee that the service being called is available or that the network would not fail or drop the messages. By being message-driven, such unreliability can be handled with greater flexibility than remote method invocations or distributed transactions.

The end value of reactive systems is Responsiveness, the ability of the application to be always efficiently available. Responsiveness is the cornerstone of usability.

Terms and Definitions

Reactive Manifesto

The Reactive Manifesto was penned in 2013 to provide business leaders and technologists with a cohesive approach and common vocabulary to accelerate the evolution toward reactive systems. 

Reactive Systems

• Reactive Systems apply reactive principles at the architectural and systems levels. Principles mentioned in the reactive manifesto are the basis of the architecture of reactive systems.
• Reactive Systems are decoupled asynchronously.
• Reactive Systems, which result from adopting reactive architecture can benefit from a reactive programming model, although it is not a pre-requisite. But usage of reactive programming alone doesn’t mean Reactive architecture. Reactive systems imply reactive architecture based on reactive principles.
• This makes them easier to develop and amenable to change. They are significantly more tolerant of failure and when failure does occur, they meet it with elegance rather than a disaster.
• Example of Reactive System: Reactive Microservices.

Reactive Architecture

Can mean:

• Any architecture that is a realization of reactive principles. It doesn’t assume stack or choice of the programming model.
• Reactive principles Solution building blocks that enable development. For example, LightBend Akka toolkit and Lagom frameworks are meant for reactive architecture.
• Reactive architecture applied across related components, services and applications turn the dials towards Reactive Systems

Reactive Programming

• Reactive Programming is based on writing asynchronous non-blocking processing that efficiently uses the threads and CPU cores to reduce the wait/block state of threads, thus removing the CPU contention from threads.
• Aims to leverage multicore CPU architecture instead of relying on the processor clock speed, which has reached a peak (Inverse of Moore’s Law)
• The reactive frameworks provide a way for the programmers to deal with a threaded model that eliminates the need for thread waits. Constructs like Promise or a Future or Stream are used to handle the response that is available “sometime in future”.
• The major specification on reactive programming models is Reactive Streams. This specification provides contracts to enable message stream processing in an async non-blocking fashion.
• Reactive programming style is now new and has been around in various forms like event-listeners in swing and browser JavaScript DOM libraries
• Reactor, RxJava / RxScala framework, Akka are examples of reactive programming tools.
• Usage of a reactive programming model doesn’t automatically mean a reactive system or a reactive architecture.

Reactive Microservices

Developing microservices-based applications on reactive principles and programming model results in reactive microservices. Reactive Architecture and Microservices had evolved independently. Reactive principles can be applied to practically any kind of architecture and microservices can be developed in the traditional “sync-REST” style as well. But because both ideas are rooted in handling distributed services, the notions of consistency, availability, latency, time, scalability & time are common concerns to solve. Reactive microservices enables maximum leverage of an inherently distributed nature. Reactive microservices are one application of reactive architecture.

The message-driven aspect of the reactive manifesto is the pervasive driver in reactive microservices and fits right into the evolution of distributed microservices (from a monolith or to alleviate the distributed monolith problem).

It is possible that microservices are developed without any consideration for either reactive manifesto or reactive programming, but the maturity for such a microservices would be low