.png)
In recent years, we have seen an increased need for scalability for applications, their code, and their infrastructure. Here at Optis, we think that those should go hand in hand. We will look at Infrastructure as Code (IaC) in a next instalment of these Tech Talks, but for today we would like to focus on the coding part.
What is the reactive programming paradigm? Why should we adhere to its principles? Which benefits does it provide when designing code for a major business? Here to give an explanation along with some examples is Thomas Houtekier, software engineer at Optis.
Because of the increased importance of scalability, legacy infrastructure and code just do not cut it anymore. Monolithic applications are much harder to scale and can be bottlenecked by their infrastructure. Microservices solve some of these issues, but they require careful design to scale well in the real world. If not, you risk having a distributed monolith on your hands. This means having to deal with a monolith’s scaling issues and microservices’ complexity while reaping none of the advantages. The increased maintenance costs will also raise the total cost of ownership (TCO).
Enter reactive programming. Based on the reactive manifesto, it proposes optimising microservice design through four key values. Microservices should be responsive, resilient, elastic, and message-driven.They should respond at all times, even in the face of failure and highly varying workloads, and do so asynchronously. If done correctly, this results in components that are isolated from each other, which yields better maintainability, extensibility, scalability, and resilience.
In this section, we will examine how the key values mentioned above will provide your organisation with concrete, tangible benefits.
Elasticity is often used as a synonym for scalability, butThomas explains that elasticity goes further than just scaling up. Elasticity also means scaling down when it is optimal. This means that a website will not only scale from hundreds to hundreds of thousands requests, but will also not use unnecessary resources when servicing just a hundred.
In other words, the code ensures that your infrastructure will only demand the exact amount of resources needed. By running an elastic application on an elastic infrastructure, you can go a lot further compared to running a rigid, monolithic application on that same elastic infrastructure. This, in turn, generates loads of potential savings down the line.
Resilience is all about managing complexity: balancing lots of microservices running in tandem, for example. One way of managing complexity is embracing failure by dealing with it appropriately. If one of your services goes down, you obviously don’t want it to take down your entire application. Using reactive programming means anticipating and preparing for failures from the get-go in the design stage.It’s all about taking preemptive measures and managing risks instead of trying to prevent every failure, which is a futile attempt.
Resilience also means expecting and embracing the failure of other systems. With reactive programming, you are in the driver’s seat. No longer having to rely on an external party and its technicians to debug your system will increase self-confidence for both your engineers and developers. The capacity to help your customers more quickly and efficiently will also help you garner a reputation as reliable and responsive.
One surefire way to improve both elasticity and responsiveness is using asynchronous communication, which will in turn increase your resilience. Asynchronous communication can be summarised as allowing one component of an application to continue to work while waiting for another component’s reply, instead of idling for a very long time — potentially forever. By separating the input and output streams of data, you avoid the possibility of your code containing blocking communication.
For example, simultaneous HTTP request responses by multiple microservices can lead to confusion when it comes to their handling order. This requires communications to be decoupled through asynchronous systems such as Apache Kafka. Decoupling will leave an application less vulnerable to cascading failures, improving its scaling capabilities and, therefore, its elasticity.
To summarise, a lot of thought needs to be put into designing microservices. That is, if you want your system to be responsive and avoid unpleasant billing surprises at the end of the month. Adhering to the key values of reactive programming will do just that. Following the reactive manifesto’s guidelines means improving your responsiveness through elasticity, resilience, and asynchronous communication.
February 18, 2022
