Why Do We Need a Reactive Manifesto?
Last week a group of us released a document that I (Jonas Bonér) have been working on lately; The Reactive Manifesto. I wrote the first version and it has since then been enhanced through the contributions of various people and evolved into the blueprint for writing Reactive Applications that you can see today. Some of the early contributors and reviewers have been people like Erik Meijer, Martin Odersky, Greg Young, Martin Thompson, Roland Kuhn, James Ward and Guillaume Bort, and during the first week more than 500 people have signed the manifesto.
In this post I wanted to take the time to explain the reasoning behind the manifesto and why I think it is needed.
Application requirements have changed dramatically in recent years. Both from a runtime environment perspective, with multicore and cloud computing architectures nowadays being the norm, as well as from a user requirements perspective, with tighter SLAs in terms of lower latency, higher throughput, availability and close to linear scalability. This all demands writing applications in a fundamentally different way than what most programmers are used to.
As a result, over the last few years we have seen quite a few different techniques and tools emerge in the industry as a way to address these new requirements. Some of them are old and proven, but to a large extent forgotten techniques, while others are novel and creative. Regardless, the common theme across these is that they allow you to write applications that:
- react to events: the event-driven nature enables the following qualities
- react to load: focus on scalability rather than single-user performance
- react to failure: build resilient systems with the ability to recover at all levels
- react to users: combine the above traits for an interactive user experience
One of the interesting things is that we have seen techniques and tools based on these ideas emerge independently of each other, across a multitude of communities, platforms and industries. This has been very exciting to watch and participate in. While this diversity is a great thing, it has led to communication challenges and missed opportunities for collaboration and integration. As the manifesto argues, we believe that these ideas have to be applied from top to bottom and in a modern application this usually means across multiple languages, platforms and tools. Unfortunately the lack of a common vocabulary and vision have made it harder to bridge the different communities, learn from each other and ensure these techniques and tools work nicely together.
The primary motivation for this manifesto is to come up with a name for these new type of applications (similar to NOSQL, Big Data, SOA and REST) and to define a common vocabulary for describing them — both in terms of business values and technical concepts. Names matter and hopefully this will help bring the communities together and make it easier for users and vendors to talk about things and understand each other.
Up to now the usual way to describe this type of application has been to use a mix of technical and business buzzwords; asynchronous, non-blocking, real-time, highly-available, loosely coupled, scalable, fault-tolerant, concurrent, reactive, event-driven, push instead of pull, distributed, low latency, high throughput, etc. This does not help communication, quite the contrary, it greatly hinders it.
Instead, I believe it was necessary to bring all these characteristics together into a new class of applications - Reactive Applications and to define them through four high-level traits; Event-Driven, Scalable, Resilient and Interactive. Read the manifesto for details on how they complement each other, interact and together paints the full picture.
Typesafe supports the Reactive Manifesto because we believe it is the architecture for the future. We formed the company with the mission and vision to make it easier for developers to solve these problems. Clearly there are many technologies available today and more in the future that enable reactive applications to be created. They come from a number of different communities, vendors and individuals. And I think that an important step towards bringing this goodness to the masses, and for a reactive architecture to become the default way of writing applications in the future, is to join forces evangelizing the ideas behind the Reactive Manifesto.
The manifesto is pushed to GitHub: https://github.com/reactivemanifesto/reactivemanifesto. We want it to be a living document so we encourage you to help out making it better. Now we have version 1.0 published on reactivemanifesto.org, but when we have enough improvements to justify a new version we will tag it and republish.
We need your help. Join us in defining the blueprint for future web and enterprise applications. Go Reactive.