• James Townley

Why Reactive Principles Create Cloud Efficiencies: A Conversation with Clement Escoffier

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 Clement Escoffier, senior principal software engineer at Red Hat, Java Champion, and a contributor to The Reactive Principles. We discuss his introduction to Reactive programming, why Reactive principles are a good fit for cloud native applications, and the real-world challenges these principles solve in everyday enterprise environments.

How did you get introduced to Reactive programming/Reactive systems?

CE: Many times, I’ve faced complicated distributed systems affected by fragility. Almost ten years ago, while I was working on IoT gateways, the usage of synchronous and blocking communications was a significant burden. It reduced the system's availability dramatically. It was clear that the communication model was ineffective.

That's how I started working with Reactive principles. Later, I joined the Vert.x team to help developers build Reactive applications and systems.

What makes Reactive principles so important for building distributed systems?

CE: Google has shown everybody, even non-IT people, that it's possible to build a blazing fast, always-up system.

It also stresses the need for a better user experience. We can't live in a world with maintenance windows, service disruptions, intermittent failures, and slowness. That’s the old world. In this new world of hyper-connectivity, systems must be always ready to answer.

Building more robust distributed systems, on bare metal, in the cloud or on Kubernetes, is necessary. But robustness is not enough. We also need to make them efficient, as cloud spending and deployment density are more and more under examination. Reactive principles provide the perfect approach to meet these challenges.

What practical challenges do Reactive principles solve in everyday enterprise environments?

CE: Reactive is a different world. Learning different concepts, different paradigms, and change is always hard.

When you are working with developers used to the traditional way, it can be tough to realize the benefits of Reactive. Once you pass this first stage, the notion of blocking code and blocking I/O is the next challenge. It's a long journey.

Fortunately, recent trends are making Reactive easier to grasp. Event-driven microservices or even Apache Kafka–as examples–make Reactive principles easier to understand.

In your opinion, what makes Reactive principles such a good fit for cloud native applications?

CE: The need for resilience is the first point. The second point is the financial aspect. A cloud environment—private or public—is never offering unlimited resources. At some point, you are reaching a limit, either because of the monthly bill or because there are no more available resources.

In general, Reactive applications use fewer resources (CPU and memory) and handle more load than traditional applications. It is mainly due to the usage of non-blocking I/O. These benefits increase your deployment density. You can run more for the same money.

How do you recommend software architects and developers get started using these principles and patterns?

CE: There are plenty of resources, but first and foremost, you need to understand where you can use Reactive and where it would be counter-productive. If you are building an I/O-based system, great; if you are making a computation-intensive kind of system, not so great.

Then, think about your system in terms of events and communication flow. By abstracting away the structure, you can focus on your system's essence: its behavior.

Finally, you need to pick the right tools; your background, team background, and use case are the main drivers.

Mark your calendar for Clement’s talk, “Reactive Programming with Quarkus - A Reactive Mutiny,” on Tuesday, November 10th at the Reactive Summit, a one-day virtual conference hosted by the Reactive Foundation and focused on Reactive principles, patterns, and projects. I hope you can make it!


  • Twitter
  • LinkedIn




© 2020 All rights reserved. The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see our Trademark Usage page. Linux is a registered trademark of Linus Torvalds. Privacy Policy and Terms of Use