Sistemas distribuidos – El Manifiesto de Sistemas Reactivos

El Manifiesto de Sistemas Reactivos
El Manifiesto de Sistemas Reactivos

Artículos relacionados

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.

Datos generados por distinto dispositivos
Datos generados por distinto dispositivos

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.

Monolitica vs Micrcoservices
Arquitectura Monolitica vs Micrcoservices

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.

Publicación de mensajes
Publicación de 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.

Aplicación NTier
Aplicación NTier
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.

Aplicación Reactiva
Aplicación Reactiva

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:
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

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s