Migrating an application to a reactive architecture

With the growing demand for resilient real time applications, reactive programming is becoming a very popular and relevant topic within software development circles.

Atul Shukla and Revanth Talari from USEReady have spoken about this at the AWS Re:invent 2014 conference in Las Vegas.

In their talk, they showed how to start with a traditional blocking architecture and then turn it into a reactive architecture.

A non-reactive application is synchronous, high-coupled, blocking and works like a pulled system:

A reactive application, on the other hand, is responsive, resilient, elastic and message-driven (asynchronous and non-blocking).

Now, let’s explore what those concepts mean in practice and the approach the speakers have applied to convert the application.

1. Responsive

Pushed instead of pulled: the application server pushes to the client in real time.

In order to accomplish that goal, the speakers created WebSocket servers in AWS EC2 instances, and SNS (AWS Simple Notification Service) to push to the client.

They relied on SockJS (a javascript based web-socket library) both for the client and the server.

2. Resilient

The application as a whole must keep running even when some components of the system fail.

In order to make the application resilient, the speakers have created instances that run the application simultaneously in many data centers (AWS availability zones) with AWS Route 53 taking care of the DNS.

3. Elastic

The application must scale according to demand. If it gets more user requests, then it should scale up and run the application in more EC2 instances. However, if the demand drops off, then it should automatically scale down, killing idle instances.

In order to make the application elastic, the speakers used ELB (Elastic Load Balancer) to balance the load of the EC2 instances; Auto-scaling to scale up and down (creating and killing instances according to the demand); Elastic BeansTalk to deploy the application; And DynamoDB as really fast and low-latency NoSQL database.

4. Message-driven

The components are loosely coupled and collaborate with each other through messages.

The speakers used AWS SQS (Simples Queue Service) and AWS SWF (Simples Workflow Service) to create and forward messages.

Summary

Let’s see how our architecture looks now:

In summary, in our application’s final reactive architecture, the server receives a message from the clients (HTML), then those messages are stored in a SWS queue and then processed by a SWF worker. Next, the worker saves the message in DynamoDB and sends it to a new SQS Queue that is processed by another SWF worker. Next, the worker pulls the message from this new queue and then notifies all the other clients (HTML) about the new message through SNS. Voilá!

That’s awesome! Isn’t it?

If your want to learn more, please watch Atul Shukla's and Revanth Talari's talk at Re:invent and see their slides:

This post was first published on my Portuguese blog at http://blog.andrefaria.com/migrando-uma-aplicacao-para-arquitetura-reativa.

Please leave a comment with your feedback.