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.
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.
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.
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.
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.
The components are loosely coupled and collaborate with each other through messages.
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?
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.