Artículos relacionados
- ¿Conoces que es el Teorema CAP?
- Falacias de la computación distribuida Parte 1
- Falacias de la computación distribuida Parte 2
Introducción
Fue publicado en Julio de 2013 por un grupo de ingenieros de software liderados por Jonas Bonér, actualmente el manifiesto reactivo (Reactive Manifesto) se encuentra en la versión 2.0. Este manifiesto nació debido a que en la actualidad los requerimientos para construir aplicaciones han cambiado mucho, ahora se necesita que las aplicaciones soporten más carga de información (la capacidad de almacenamiento ya no solo se mide en Gigabytes sino que también en Terabytes o Petabytes) que se genera desde distintos tipos de dispositivos (celulares, pcs, servidores onpremise, servidores cloud, tablets, gadgets, etc) esto sin afectar los tiempos de respuesta al usuario y que siempre se encuentren disponibles.
Todos estos nuevos requerimientos demandan que se deba cambiar la forma en que se vienen diseñando y construyendo las aplicaciones para que corran eficientemente, escalen fácilmente y sobrevivan a fallas.
Para lograr esto se propone trabajar con un diseño que tiene como clave una arquitectura fundamentalmente asíncrona y orientada a mensajes en donde los componentes se comuniquen asíncronamente enviando mensaje y publicando eventos.
Manifiesto de Sistemas Reactivo
Para desarrollar un sistema reactivo este debe tener las siguientes características:
1. Responsive (Responsivos)
Un sistema debe detectar rápidamente los problemas y tratarlos efectivamente para mejorar la usabilidad por parte del usuario. Estos tipos de sistemas se enfocan en proveer tiempos de respuesta rápidos y consistentes para mejorar la calidad del servicio. Como resultado conseguimos que se simplifique el tratamiento de errores, mejora la confianza con el usuario final y se estimula a una mayor interacción con el sistema. Deben responder, aun cuando ocurran errores..
2. Resilient (Resilientes)
Un sistema debe mantenerse responsivo cuando encuentre fallas, para lograr esto se debe aplicar estrategias de replicación, contención, aislamiento y delegación. Los fallos ocurridos deben permanecer en cada componente aislándolos de los demás para asegurarse que al fallar se puedan recuperar sin comprometer a todo el sistema. La recuperación de cada componente se delega a un componente externo y la alta disponibilidad se asegura aplicando replicación donde se crea necesario. El cliente no es obligado manejar las fallas que cada componente genere.
3. Elastic (Elasticos)
Un sistema se mantiene responsivo bajo diferentes cargas de trabajo o cambios en la frecuencia de peticiones incrementando o reduciendo los recursos (memoria, procesador, disco) asignados para servir dichas peticiones. Para esto se deben diseñar sistemas sin cuellos de botella o puntos de contención que tengan la habilidad de replicar componentes y balancear la carga entre ellos. Además, se menciona que los sistemas reactivos deben soportar algoritmos predictivos y de escalabilidad para alcanzar elasticidad de una forma rentable sobre plataformas de bajo costo tanto en hardware como software.
4. Message Driven (Orientados a mensajes)
Un sistema envía mensajes asíncronos entre componentes, lo que asegura un bajo acoplamiento, aislamiento, transparencia e independencia de su ubicación. Usando este mecanismo de intercambio de mensajes se asegura la administración de la carga y la elasticidad a través del monitoreo de colas en el sistema.
Comparación de un sistema clásico (Ntier) vs un sistema reactivo
Caso
Se necesita diseñar un sistema web que registre pedidos en una base datos.
Diseño sistema clásico (Ntier)
Bajo este enfoque desde el navegador cliente se envía un request para registrar el pedido al servidor web, este debe esperar que la base de datos termine de procesar la solicitud para devolver la respuesta al usuario.
Diseño sistema reactivo
En este diseño desde el navegador cliente se envía un request para registrar el pedido al servidor web, este deja un mensaje en una cola y responde al cliente para que deje de esperar, luego el mensaje se procesará asíncronamente y se registrará en base de datos, para finalmente notificar al servidor web que ya terminó el registro del pedido y este notifique al navegador del cliente el resultado del pedido.
Si les gusto el tema y quieren saber cómo empezar a desarrollar sistemas con estas características les recomiendo que le den un vistazo al modelo Actores que está hecho exclusivamente para desarrollar sistemas reactivos:
Conclusiones:
En la actualidad los requerimientos para construir aplicaciones han cambiado, ahora se necesita que las aplicaciones soporten más carga de información sin afectar los tiempos de respuesta al usuario y que siempre se encuentren disponibles. Por lo tanto la forma en que se vienen diseñando los sistemas debe cambiar a una arquitectura orientada a mensajes y asíncrona. Para desarrollar un sistema reactivo nuestro aplicativo debe tener las siguientes características: responsivo, resiliente, elástico y orientado a mensajes.
Referencias:
- Manifiesto de sistemas reactivos
- Why Do We Need a Reactive Manifesto?
- Reactive manifesto 2.0
- Pluralsight – Implementing the reactive manifesto with Azure and AWS
- Sistemas reactivos
Metal Tip:
Este artículo lo escribí escuchando la canción Me against the world de la banda Lizzy Borden de Estados Unidos, les comparto el enlace.
Happy coding and Stay Heavy lml
Code2Read por Luis Aldazabal Gil 