Quizás el mayor impacto en las operaciones debido a la migración abrupta de consumidores y empleados a las experiencias digitales es la disponibilidad. Ciertamente, un porcentaje significativo de organizaciones tuvo dificultades con el acceso remoto a medida que los trabajadores pasaban de la oficina al hogar. Pero sólo algunos trabajadores terminaron trabajando desde casa, mientras que poblaciones enteras de repente dependieron de los equivalentes digitales de la vida cotidiana.
Consideremos los hallazgos de Nokia , que informa que "el tráfico ascendente (redes seleccionadas en los EE. UU.) durante el mes de marzo de 2020" vio un "aumento del 30% en el tráfico ascendente con respecto a sus niveles previos a la pandemia". O estos datos que muestran un aumento del 72% en las transacciones (y del 29% en las páginas vistas) para la segunda semana de abril.
La demanda de experiencias digitales está aumentando. Y hay pocas cosas más frustrantes para un usuario que una aplicación o un sitio web que no se carga. Para ser honesto, hay pocas cosas más frustrantes para un operador que una aplicación o un sitio web que no se carga.
Lograr una alta disponibilidad no es solo una cuestión de insertar un balanceador de carga en la ruta de datos. Eso es parte de la ecuación, pero es solo uno de los pasos necesarios para garantizar que una aplicación o un sitio web permanezca disponible.
Lo primero que debes hacer es responder dos preguntas no tan sencillas:
A primera vista, parecen más simples de lo que realmente son. Esto se debe a que para responderlas es necesario saber mucho sobre la aplicación y su infraestructura.
Empecemos, ¿vale?
Esta pregunta realmente profundiza en el algoritmo de equilibrio de carga correcto a utilizar, ya que los algoritmos son los que determinan cómo se distribuye el tráfico (solicitudes) entre los recursos (servidores). La respuesta a eso depende de muchas cosas, pero comienza con la arquitectura de la aplicación y los patrones de uso.
Verás, si estás intentando hacer que una aplicación tradicional (monolítica, cliente-servidor, web de tres niveles) sea altamente disponible, tienes que entender los patrones de uso desde una perspectiva completamente diferente.
Esto se debe a que un "servidor" back-end es responsable de ejecutar toda la lógica empresarial. ¿Estás intentando iniciar sesión? ¿Estás pidiendo un producto? ¿Estas navegando por el catálogo? Todo el mismo "servidor". Podrías pensar que puedes simplemente usar un algoritmo simple como round-robin para distribuir el tráfico. Al contrario, amigo mío. Cada función empresarial tiene diferentes requisitos de computación, memoria, red y datos. Esto significa que cada función empresarial supone una carga diferente en el "servidor". Una única instancia de "servidor" puede verse rápidamente sobrecargada simplemente al dirigirle demasiadas solicitudes que consumen muchos recursos.
La mejor manera de optimizar la distribución de solicitudes para garantizar la disponibilidad de las aplicaciones tradicionales es utilizar un algoritmo basado en el mínimo de conexiones. Esto mantendrá la carga distribuida entre las instancias de "servidores" en función de la cantidad de conexiones abiertas actualmente. La razón por la que esto funciona es porque las solicitudes que consumen muchos recursos tardarán más en procesarse, lo que mantendrá las conexiones activas. Al dirigir las solicitudes a "servidores" con menos conexiones, es más probable que todas estén disponibles.
Para las aplicaciones modernas (basadas en microservicios), esta pregunta se responde más fácilmente. Esto se debe a que una aplicación moderna ya está descompuesta en funciones comerciales que escalan individualmente. Sigue siendo una buena idea utilizar un algoritmo basado en el menor número de conexiones posible porque algunas solicitudes para la misma función pueden consumir más recursos que otras, pero el tráfico se equilibra naturalmente en una arquitectura de aplicación moderna, por lo que prácticamente cualquier algoritmo servirá para mantener todos los "servidores" disponibles.
Lo interesante (para mí, al menos) de la disponibilidad es que saber cómo distribuir las solicitudes es solo la mitad de la batalla. El otro no es, lamentablemente, el láser rojo y azul, sino que se basa en la visibilidad del estado de salud de la aplicação.
Aquí es donde debería insertarse mi disertación sobre la observabilidad* pero, por el bien de la brevedad y su cordura, simplemente la resumiré de esta manera:
Si utiliza algo distinto a la "disponibilidad de la aplicação " para determinar el estado de una aplicación, está poniendo en peligro la alta disponibilidad. Esto se debe a que ninguna de las demás medidas observables proporciona información sobre la aplicación. Si bien se necesita la disponibilidad de la red, el transporte y la plataforma, hasta que se garantice que la aplicación está lista para recibir solicitudes, se generan problemas si se le envía tráfico.
Los cuatro componentes de la observabilidad son importantes. Si se pierde la conectividad de red, después de todo, el resto realmente no importa. Por lo tanto, es necesario vigilar las cuatro medidas, lo que significa comprobarlas todas. No importa cuál sea la arquitectura de la aplicación. Todas las aplicaciones dependen de las capas de red, transporte y plataforma. Donde la arquitectura hace la diferencia es en la capa de la aplicación, porque la arquitectura puede limitar la forma en la que se determina si la aplicación funciona o no.
Siempre debes preguntar por la forma de "verificar el estado" de la aplicación durante el desarrollo. Ya sea a través de una API o una solicitud HTTP, la existencia de un "control de estado" dedicado ofrece a los desarrolladores y operadores una forma sencilla de verificar que la aplicación está funcionando correctamente. Esto puede incluir funcionalidad que verifique la conectividad con recursos externos, como datos o API de socios. Dado que la falla de cualquiera de estos componentes puede provocar que la aplicación parezca no disponible o no responda para el consumidor, es importante verificar la disponibilidad de todos los componentes necesarios.
A menudo, la literatura de marketing quiere hacernos creer que la alta disponibilidad es tan simple como clonar un servidor y colocarle un balanceador de carga delante. Pero la realidad es que hay consideraciones, mediciones y preparaciones serias necesarias para garantizar que una aplicación tenga alta disponibilidad. No se trata sólo de asegurarse de que las instancias estén disponibles; se trata de asegurarse de que todas las aplicaciones dependientes estén disponibles y distribuir las solicitudes de una manera que no sobrecargue ninguna instancia determinada.
La ventaja de todo el trabajo extra que dedicas a garantizar la alta disponibilidad de las aplicaciones es una experiencia positiva para el cliente y menos llamadas frenéticas a altas horas de la noche sobre aplicaciones caídas.
*En realidad no tengo una disertación sobre la observabilidad. Pero si lo hubiera hecho, aquí es donde lo habría insertado.