My Reaction to Venkat Supramaniam’s talk on Reactive Design
On Tuesday, May 9, Chicago Java Users Group (CJUG) hosted Venkat Supramaniam to discuss Reactive design in Java.
For the most part, Venkat used the time to explain a trend he has noticed after years of writing applications: every so many years, we as a development community “re-discover” something we had been doing for a very long time and we then tote it as the new de-facto standard for all future development. Venkat pointed out that this is happening more rapidly recently, as he hypothesized, because the open-source community surrounding languages such as Java and JavaScript spread ideas and solutions much more loudly and at a faster rate than some closed off languages, such as Microsoft’s C# language.
He goes on to defend this theory by pointing out how Rx.NET has been around for nearly a decade, but there was never much discussion about it outside of the .NET community. However, when Microsoft started publishing their ReactiveX libraries, and Netflix contributed the RxJava distribution, suddenly Reactive programming was the latest craze. And there is good reason as to why Reactive programming and architectural design is becoming so popular.
Think back to the days where your office had that one tool developed by that other company that accomplished a very specific goal your organization had…
Let’s be real, you probably still use software like that.
The point, however, is that software like that is software you are “forced” to consume. You are a “captive” of the company designing the application, and any input you may have, or review you might give, might as well fall on deaf ears because that company is still making money off of that product regardless of your opinion.
Now, there has been a recent shift in software requirements at the height of the Internet and Mobile age where we are no longer developing applications for, what Venkat affectionately referred to as, “captive consumers”.
We now live in an age where more and more companies are emerging that develop software for the masses. Applications like Facebook, or Netflix, or Google are consumed by millions every second. If an application targeted at everyone proves to be slow, or unresponsive, or has a bad design, then the people will speak their minds and rate your application poorly because it isn’t useful to them.
So what do you do when you have to develop an application that loads quickly, is responsive, and is then distributed to millions (sometimes billions) of clients every second?
This is where Reactive design comes in.
Per the LightBend group’s Reactive Manifesto , the Reactive Architecture can be summarized by 4 pillars.
- Responsive
- Resilient
- Elastic
- Message-Driven
An application that is Responsive is one that tries to give you something, even when what it receives is an error. While the user is waiting for something to happen, maybe display a loading animation or something to let them know that something is happening. It’s always better to give the user back something as quickly as possible, but don’t lie to your users if something goes wrong. Error’s aren’t a bad thing you should hide from your end user anymore. Of course, don’t give them back your entire stack trace and reveal the inner-workings of your application. But if your service happens to timeout before it can fetch the appropriate data, display a message that says “Oops, we didn’t get a response, please try again”.
When we talk about Resilience, we don’t mean that you have an edge case and a try-catch block for every possible point of failure for your application. Let’s be real for a moment — your application is going to fail. I don’t care who you are, your application is going to fail. Yeah, you. Don’t look at me like that! You don’t believe me, look at Amazon then. You don’t always have to defend against every little thing, but you should have recovery strategies in place. For example, if you rely upon another service to perform some task and that service goes down, don’t panic! Let your end-user know that something is amiss, and have your service keep trying to connect to its dependencies. Of course, your services should be scalable enough that you should have a back up available, which brings us to the next point.
Elasticity in application design is about making sure that you can deploy many instances of your application at once and have fail-safes in place to scale up the number of services you need at any moment, as well as nice-to-have systems that can take down under-utilized instances at any point. We’re probably all familiar with Elasticity, especially if you’ve been working with MicroServices at all over the past couple of years. Elasticity is so important, that we often forget to enforce it in our design when building applications as we think that IaaS (Infrastructure as a Service) systems like AWS, Google Cloud, and Microsoft Azure. That doesn’t make it any less important to think about though, especially because simply being resilient and elastic doesn’t help you when you have issues with “back pressure”.
“Back pressure” refers to when your application is receiving too many requests, or too much data, that it can’t process fast enough to handle what it’s receiving, and so “pressure” begins to “back up” and, if you’re not careful, can shut your application down. (Raise your hand if you’ve ever woken up at 3 AM on a Saturday because support staff told you they saw an “OutOfMemoryException” and the application died…) So how do we handle “back pressure”, you ask? You buffer it.
Buffer? What do you mean buffer, Adam? I know your dad used to be a janitor, are you talking about those things that are used to polish the floors? Those always looked fun in cartoons!
Unfortunately, no. When I say “buffer” I mean more like how your doctor’s office might have a waiting room.
Follow me on this analogy: if you’re a doctor, you can only be with one patient at a time. But you may have scheduled 20–30 patients for physicals in a day. If you get that one patient who has to tell you about their story of why they think that they’re sick or in pain (I’m looking at each and every one of you), you have to let them finish before you can move on with the physical. Now your other patients have to wait for you to get to them for their appointments. But they don’t all wait in the observation room — that would be crazy! No, instead you have your load balancer, ehem, I mean office staff, kindly inform the other patients to just hang out in the waiting room until you are ready to see them. When you’re ready, you let the staff know, they call out a patient’s name, and then the process starts all over again.
To recap, the doctor is your application where processing logic takes place, your office staff are your load balancers, and your waiting room is your “buffer”.
Of course in applications we aren’t dealing with human beings though, we’re usually dealing with bytes and strings. Let’s generalize these by calling them “messages”. So “messages” are the things that get processed, and the result of that processing may result in another “message” you send to another system, and so on. Congratulations! Your application is now “message-driven” as it is responding to incoming messages and only does processing when a message comes in. But of course, the most important thing about message-driven systems is that there is a way to handle a build up of messages. So services like Apache Kafka message buffer are great because messages can stay in your buffer until you are ready to receive them. (and no, the irony is not lost on me that a bureaucratic, distributed message system with such services as ZooKeeper is called Kafka)
Whew — we’ve covered a lot, but we still haven’t even talked about code yet! There was that passive-aggressive dig at AWS, and that weird analogy about a doctor’s office… So let’s talk about how you can get started with implementing some Reactive practices yourself.
Let’s talk about Observables.
An Observable, at its core, is a design pattern that has been around for decades. An Observable is any entity that has a set of Subscribers. Subscribers are interested in what data an Observable has, or may have in the future, and so they listen for when an Observable emits, or sends, a message to them with the data they’d like to receive. It’s the idea of The Hollywood Principal: if you’re an actor in Hollywood seeking work, you work with staffing managers. If you know anything about Hollywood, actors are not expected to bother managers with repeat calls asking if they have new work for them. Instead the policy of any manager in Hollywood is “Don’t call me, I’ll call you”. If you take this pattern and expand on it to the architectural level, you get what is called the Actor Model.
So I don’t want this to become a tutorial post about how to implement the Observable pattern, especially when there are libraries like ReactiveX out there and tutorials such as EggHead’s “Introduction to Reactive Programming”, but I do want to wrap up with some closing observations.
I have been a developer now for about 4 years, professionally, and I must say I am very excited about the potential of Reactive programming. Being predominately a Java programmer, I see huge potential for some of the annoying, monotonous parts of the job. Wouldn’t it be great if you could set up an Observable on a database and return a stream of data to a user whenever it changes or new data is added? Wouldn’t it be great if when you receive a request, you could notify a bunch of services that could handle things like analytics, logging, and you handle bad data without blowing up the whole stack? Wouldn’t it be great to not have to worry about managing a multi-threaded application? (not “not having” a multi-threaded application, but at the very least utilizing Schedulers to manage threads for us)
I see a lot of potential in Reactive programming, and I have enjoyed playing with some tools such as Akka, and even Lagom, but I think there is a lot of work to do to make Reactive tools more understandable and approachable. I don’t believe Reactive design is an end-all-be-all to programming design, but I would be lying if I said it isn’t a great solution for some of the scalability problems I have seen.
