Asegura la disponibilidad de tus aplicaciones Cloud con el patrón Service Messaging

La Web ha alterado mucho desde los tiempos en donde los usuarios aguantaban largas esperas mientras que navegaban de página a página.

Hoy día, es inadmisible que una operación lanzada por el usuario se extienda en él tiempo o bien genere un fallo general a raíz de una humillación del servicio, o bien una interrupción de la conexión. Y para esto empleamos frameworks como VueJs o bien afines.

Con la llegada de la computación en la nube, los inconvenientes de fallos transitorios relacionados con las comunicaciones o bien la sobrecarga de los servicios de backend, ganan en criticidad y precisan de patrones de aplicaciones en especial diseñados para Cloud.

Este artículo describe el patrón que ofrece un aumento de la disponibilidad, fiabilidad y resiliencia de nuestras aplicaciones Cloud.

Service Messaging

El patrón de correo es aquel que se encara a los inconvenientes que generan las conexiones permanentes entre servicios recónditos como son la dependencia, el acoplamiento y la restricción de la reutilización y escalabilidad de estos.

Para esto plantea efectuar la comunicación a través de un autobus de mensajes que efectúan una conexión asíncrona entre los dos servicios (en un caso así el cliente del servicio y los servicios de facturación y almacén), tal como se ve en la figura.

Múltiples clientes del servicio comunicándose por un autobus de mensajes con el pool de servicios

Los mensajes son unidades de información alfanumérica de pequeño tamaño (en un rango de Kb) que son introducidos en la cola de correo por los clientes del servicio, para ser consumidos por los servicios conforme con el flujo de trabajo que mejor resultados ofrezca.

Figura dos. Ejemplo de mensaje

De esta manera, de mano, consigo múltiples beneficios muy importantes:

Disponibilidad. Puedo agregar tantos clientes del servicio como desee, pues los servicios de autobus de mensajes en Cloud son “infinitos “y con un desempeño que escala conforme el tamaño de la cola.

Cliente del servicio. El número de solicitudes puede situarse muy sobre el volumen medio o bien el máximo aguardado. El cliente del servicio no va a tener ninguna percepción de que la ejecución de la adquisición vaya más lenta.
Servicios. Los servicios pueden hacer una previsión de la carga de trabajo en dependencia del número de mensajes que puedan procesar. Eludiendo el peligro de tener una humillación del servicio al percibir más solicitudes de las que pueda admitir; o bien de un escalado automático sin límites que desemboquen en un costo que desborde al previsto y aprobado.

La cola de mensajes estabiliza los picos de solicitudes, dejando un escalado de los servicios estable y previsible.

Escalabilidad. Vamos a poder escalar de forma indiferente cualquiera de los servicios implicados conforme con las necesidades de negocio. Por servirnos de un ejemplo, frente a la avalancha de ventas, acrecentar las instancias del servicio de facturación, dejando sin alterar el de almacén puesto que la administración del stock es mucho menos compleja. Y usando el tamaño de la propia cola de mensajes como indicador en las reglas automáticas de desarrollo y decrecimiento del número de instancias.
Resiliencia. Si una vez efectuada la operación de venta en la caja y mandado el mensaje, hubiera un corte o bien humillación de las comunicaciones, el usuario no padecería ninguna desconexión o bien fallo, siguiendo trabajando en modo local hasta el momento en que volviera la conexión y se manden los mensajes producidos. Caso de que una instancia del servicio de facturación se cayese o bien tuviese algún inconveniente, se podría seguir efectuando su trabajo con cualquier otra instancia, sin perder información de estado o bien mensajes.

Bregando con estados

Desde el nacimiento de la página web basada en http, me debo “pegar” con un sistema sin estado; y todavía más si deseo desplegar en el Cloud en donde el desarrollo horizontal basado en instancias es el modelo de escalado por defecto.

Es verdad que puedo emplear mecanismos aproximadamente eficaces como registros en base de datos o bien memorias caché compartidas, mas solo en el momento en que me veo obligado a ello.

Conforme con esta arquitectura, sería más adecuado incorporar un patrón de mensajes con metadatos, incluyendo un valor de estado en el propio mensaje que se alteraría conforme el servicio que lo haya procesado.

Otra forma de administrar estados sería emplear un patrón de colas prioritarias. En donde el propio usuario decide la emergencia de la operación sencillamente ingresando el mensaje en una de las colas libres, y que son consumidas por los servicios en un orden temporal establecido. Creándose sencillamente múltiples “pipelines” o bien flujos de procesamiento sin precisar persistir ningún estado.

La cola superior resulta prioritaria a la inferior, descargando al servicio de decidir la emergencia de cada operación

Por último podríamos mandar la contestación al usuario que dio de alta la operación de adquiere, agregando la identificación única de a quien hay que remitirle el resultado del proceso de adquiere en el propio mensaje.

Latencia y dificultad, los efectos secundarios

Mas todo tiene su lado obscuro, y este patrón de aplicaciones en cloud no iba a ser diferente.

De este modo, los inconvenientes vienen primero por el incremento de la dificultad de la arquitectura de mis aplicaciones. No únicamente por tener que incorporar más código a fin de que el usuario interaccione con la cola de mensajes, si no asimismo por edificar servicios que sean idempotentes, que aguanten múltiples lecturas del mismo mensaje, que sepan de qué forma administrar los metadatos, o bien que breguen con el TTL de los mensajes.

Por otra parte, meto latencia a mi sistema y un punto de incertidumbre; en tanto que la arquitectura no está desarrollada a las posibilidades puras, si no a la escalabilidad, disponibilidad y resiliencia.

De manera que, 2 operaciones efectuadas en exactamente el mismo instante serian procesadas en un intervalo de tiempo diferente, con una duración indefinida en un rango temporal aproximado.

Resumiendo, todavía siendo un patrón que se puede aplicar en múltiples escenarios, no es una “bala de plata”. Y hay que descartarlo en aquellos en donde las operaciones en tiempo real sean requisito.

Show me the Code

Deseo compartir 2 geniales tutoriales pasito a pasito publicados por Microsoft, en donde muestran lo fácil que es implantar este patrón con C#:

Partiendo de los dos tutoriales, lo siguiente a implantar sería el remplazo del empleo de la contraseña por un patrón Valet Key, para tener cubiertos mis requisitos de seguridad.

En turincon.netDev | tres patrones de diseño indispensables que deberías conocer para tu sistema en cloud: Retry, Valet Key y Sharding

Imágenes: Azure Interactives