Tempo de leitura: 4 minutos
Today I had an interesting experience when I was trying to tweet something and that led me to write this post about reactive systems. For the first time, I got a message from twitter saying: “internal server error”. Then, I tried to reload the page and was presented with a better/more friendly message saying that Something went wrong and that they were already working to fix the problem. For an instant of a few seconds I tried to reload the page twice and the friendly error message was still there. But then, for the third time, boom… the system was up and running again.
I don’t have real information about what happened but I can guess it and I would like to share that with you.
What probably happened was that the system was able to recover itself after a system crash. So that leads us to a very fundamental concept of modern software architectures:
“Fault-tolerance and self-recovery are more important than crash-proof”.
It’s nearly impossible for system to be crash-proof for a variety of reasons. However, nowadays with the advents of cloud computing and being lean and agile methodologies the mainstream for software engineering, it’s totally feasible for a system to be able to recover itself, even if the hardware where it’s running is broken. A modern reactive architecture can acquire new computational resources and within a few seconds prepare the whole environment, deploy and be up and running with the last state before crashing.
That’s what we call REACTIVE SYSTEMS. These are software architectures that don’t try to be perfect but try to be resilient and fault-tolerant. In this post I would like to share a few tips that can help you to build stronger, more robust and flexible software systems.
Federated Architectures and Micro-Services
The model for modern reactive architectures is implemented in a federated way, where you have micro-services taking care of small-specific responsibilities, with a single point of trust for data. The architecture itself is usually distributed over different environments and interfaces are well-defined among the services. Business operations will be spread over several software components that are seamlessly integrated, still ensuring distributed atomic transactions.
Test Automation
The code is utterly tested. In such environments safety isn’t provided by a separated Q.A. team that takes over after the development phase . Rather, the safety is guaranteed by sometimes hundreds of thousands of automated tests that are executed all over the architecture. From unit, to integration, acceptance and performance testing, everything is fully automated. The code coverage and compliance with quality standards is continuously monitored.
Small Teams and Test First Approach
Reactive systems are built in small cross-functional teams that join business and tech people altogether. Two pizzas should be enough to feed the whole team, and they usually take care of one or two micro-services. They also apply the Test First Approach, validating every aspect from the business to the technology development. They create hypothesis and acceptance criteria that will further on be translated to code and become automated tests. Problems are solved much earlier and with a cost that is hundreds of times lower.
Virtualisation and Reactive Systems
Another key aspect for reactive systems is virtualization. Do you remember the traditional developer answer when things break: “Works on my machine”? That would never happen in a reactive environment because the environments are identical. Also, if someone had to manually rebuild and configure the environments in order to recover a system, it would never be done in a few seconds. So, the creation and maintenance of development, staging/testing and production environments are automated and virtualised.
Elasticity
Often times systems fail because they receive a high peak of demand, with so many simultaneous connections that the current hardware simply can’t handle. In these cases, reactive systems will be able to acquire new resources, properly balance the load and then they will instantly release the computing resources when the demand diminishes. In other words, this is the capacity to be elastic. Elasticity is also the point where your cost for hardware infrastructure is best optimised. In all the other cases, either you’re gonna have your systems running under capacity or you will have your machinery idle. In both cases you’re gonna have high costs by paying for expensive unused computer power or by loosing credibility with your customers when they try to access your system and it doesn’t work.
Responsiveness
Reactive systems are also responsive, which means they can adapt and transform themselves for the environment where they are being used. Responsiveness in this case is not only related to the user interfaces but also to the kind of feature that will be made available in such different environments.
Message Driven
Reactive systems are asynchronous. Asynchronous architectures make it easier to diminish coupling and to manage flow among computing resources when your load-balancing your system. It also provides a better way for error handling. Such non-blocking architectures are indeed far better to improve user experience as well.
There are much more aspects related to building reactive systems and I hope the ones I shared here are already a good staring point for you. Stay tuned by visiting our website LeanIT101.com and get in touch on twitter @screscencio.
Please, subscribe and share!
