¿Qué es la resiliencia de las aplicaciones?

Las aplicaciones potencian prácticamente todos los aspectos de los negocios modernos, desde el procesamiento de transacciones de clientes y la gestión de la cadena de suministro hasta permitir la colaboración de los empleados y el análisis de datos en tiempo real.

Cuando estas aplicaciones fallan, el impacto puede ser grave. Tiempo de inactividad: períodos en los que una aplicación no está disponible o no puede funcionar correctamente, puede resultar en daños a la reputación, experiencia de usuario degradada y pérdidas financieras significativas.

De hecho, el 98 % de las organizaciones informan ahora de que los costes por tiempo de inactividad superan los 100 000 USD por hora, y un tercio estima pérdidas de 1-5 millones de dólares.

Al diseñar e implementar aplicaciones resilientes, las organizaciones pueden evitar y mitigar estas interrupciones.

La resiliencia de las aplicaciones depende de dos principios básicos:

• Tolerancia a fallos: capacidad de una aplicación para continuar funcionando cuando falla una parte.

• Alta disponibilidad: la capacidad de un sistema de ser accesible y fiable casi el 100 % del tiempo. 

Las aplicaciones resilientes ayudan a reducir las vulnerabilidades en la arquitectura de aplicaciones, mejoran la eficacia operativa y garantizan una experiencia de usuario coherente incluso ante interrupciones inesperadas.

Para crear e implementar aplicaciones resilientes, los desarrolladores y los equipos de TI pueden utilizar varias herramientas y prácticas a lo largo del ciclo de vida de la aplicación.

Los componentes comunes de las aplicaciones resilientes son:

• Redundancia
• Equilibrio de carga
• Contención de fallos
• Observabilidad
• Automatización
• Degradación elegante
• Escalabilidad

La redundancia significa tener copias de seguridad de los sistemas críticos. Si un sistema falla, la copia de seguridad se hace cargo y ayuda a garantizar que el sistema continúe funcionando.

Por ejemplo, es probable que un servicio de procesamiento de pagos tenga varias copias del servicio ejecutándose en diferentes servidores. Si un servidor falla, las copias en otros servidores pueden asumir automáticamente la carga de trabajo para que los clientes no noten ningún problema.

Las organizaciones suelen generar redundancia en áreas clave:

• Bases de datos: almacenar múltiples copias de datos en diferentes ubicaciones para ayudar a garantizar que no se pierda nada si falla un sistema.

• Centros de datos: alojamiento de aplicaciones en varios sitios físicos para que las operaciones puedan continuar incluso si una ubicación deja de funcionar.

• Entornos en la nube: distribución de aplicaciones entre regiones o proveedores, como Amazon Web Services (AWS), Microsoft Azure e IBM® Cloud, para eliminar los puntos únicos de error.

• Conexiones de red: aprovechar múltiples proveedores de Internet o telecomunicaciones para mantener la conectividad durante interrupciones.

El equilibrio de carga implica distribuir el tráfico de red de manera eficiente entre varios servidores para ayudar a optimizar la disponibilidad de las aplicaciones. Es crítico para la resiliencia de la aplicación porque permite a los sistemas mantener el rendimiento y la disponibilidad incluso cuando los componentes individuales fallan o se sobrecargan.

Por ejemplo, si un servidor deja de responder, el equilibrador de carga puede redirigir automáticamente el tráfico a otros servidores en buen estado, manteniendo la aplicación en línea.

La contención de fallos es una práctica de diseño que aísla los componentes críticos dentro de un sistema distribuido, evitando que los problemas localizados se conviertan en interrupciones en todo el sistema.

La contención es especialmente importante en las arquitecturas de microservicios, donde un fallo en un servicio puede afectar rápidamente a muchas otras dependencias si no se contiene adecuadamente.

Las mallas de servicio son especialmente útiles para contener errores. Estas capas de infraestructura ayudan a gestionar la comunicación entre los microservicios en las aplicaciones distribuidas, proporcionando:

• Reintentos automáticos: cuando una solicitud falla debido a un problema temporal (como un breve fallo de red), la malla reintenta automáticamente en lugar de darse por vencida de inmediato.

• Interrupción de circuitos: la malla monitoriza el estado del servicio y deja de enviar temporalmente solicitudes a los servicios con dificultades, dándoles tiempo para recuperarse y evitando caídas en todo el sistema.

• Rastreo distribuido: la malla rastrea las solicitudes a medida que se mueven entre los diferentes servicios, lo que ayuda a los equipos a detectar las ralentizaciones y a determinar exactamente dónde se producen los problemas.

En conjunto, estas capacidades ayudan a garantizar que las fallas en un servicio no se propaguen a otros. Por ejemplo, supongamos que un motor de recomendación de productos falla en un sitio de comercio electrónico. Una malla de servicio puede detectar esta falla, evitar que las solicitudes lleguen al servicio dañado y redirigir el tráfico en consecuencia. Los usuarios pueden continuar navegando y comprando sin interrupciones.

La observabilidad permite a los equipos monitorizar el estado del sistema en tiempo real mediante el uso de tres tipos clave de datos: métricas (indicadores de rendimiento como tiempos de respuesta), registros (registros de eventos como errores o bloqueos) y rastreos (el recorrido completo que realiza una solicitud a través de un sistema).

Al capturar y analizar estas señales, los equipos pueden detectar anomalías, diagnosticar problemas rápidamente y reducir el tiempo de inactividad. Por ejemplo, si un cliente informa de que una página web se carga lentamente, las herramientas de observabilidad pueden ayudar a los ingenieros a rastrear la solicitud hasta el servicio que causó la demora y corregir el problema antes de que afecte a más usuarios.

La automatización desempeña un papel crítico en la resiliencia de la aplicación, ya que permite a los sistemas responder a los problemas sin necesidad de intervención manual.

Por ejemplo, las herramientas de observabilidad detectan problemas y la redundancia proporciona recursos de copia de seguridad. La automatización es lo que conecta estas capacidades, orquestando el proceso de recuperación. Una automatización eficaz puede reducir significativamente el tiempo de recuperación, convirtiendo lo que podrían ser horas de resolución manual de problemas en segundos de respuesta automatizada.

Entre las respuestas automatizadas clave en la resiliencia de las aplicaciones se incluyen:

• Conmutaciones por error con scripts: secuencias predeterminadas de acciones que transfieren automáticamente las operaciones de un sistema fallido a los sistemas de copia de seguridad identificados a través de la planificación de redundancia. Por ejemplo, si la base de datos principal falla, el sistema cambia automáticamente a una copia de seguridad y redirige todo el tráfico allí en segundos.

• Reaprovisionamiento de recursos: aprovisionamiento automático de nuevas instancias o reasignación de recursos cuando fallan los componentes, como la creación de nuevas máquinas virtuales para reemplazar las rotas sin que nadie tenga que intervenir.

• Flujos de trabajo de autorreparación: coordinación entre alertas de monitorización y acciones de recuperación para restaurar el servicio sin participación humana. Por ejemplo, si una aplicación comienza a usar demasiada memoria, el sistema la reinicia automáticamente antes de que los usuarios noten alguna ralentización.

Herramientas como Kubernetes, un sistema de código abierto para gestionar aplicaciones en contenedores, demuestran cómo la automatización une los componentes de resiliencia. Kubernetes puede detectar fallos mediante comprobaciones de estado integradas, reprogramar cargas de trabajo en nodos en buen estado y mantener la continuidad del servicio mediante flujos de trabajo automatizados.

La degradación elegante implica mantener la funcionalidad principal mientras se eliminan las características no esenciales durante el estrés. Por ejemplo, durante los picos de tráfico del Black Friday, un minorista podría desactivar temporalmente las reseñas de los clientes y las listas de deseos para ayudar a garantizar que el carrito de la compra y el proceso de pago sigan funcionando.

Las aplicaciones escalables pueden ajustar automáticamente los recursos en función de las demandas de la carga de trabajo. Esta capacidad ayuda a garantizar el rendimiento y la disponibilidad incluso cuando el tráfico fluctúa.

La escalabilidad se puede lograr de muchas maneras. Por ejemplo, las plataformas basadas en la nube proporcionan escalabilidad a través de capacidades como equilibradores de carga integrados, autoescalado y replicación multirregión, es decir, copia de datos y servicios en múltiples ubicaciones geográficas para mejorar el rendimiento y la fiabilidad. Estas capacidades permiten a los servicios distribuir el tráfico de forma inteligente, mantener el tiempo de actividad y minimizar el tiempo de recuperación en respuesta a condiciones cambiantes.

Por ejemplo, una plataforma de streaming alojada en la nube suele funcionar en 100 servidores. Pero durante un evento global en directo, puede escalar automáticamente a 10 000 servidores en varias regiones, proporcionando una reproducción fluida para millones de espectadores simultáneos.

Dado que las aplicaciones de software se han vuelto esenciales tanto para las operaciones comerciales como para la vida cotidiana de los consumidores, es imperativo que estas aplicaciones resistan interrupciones inesperadas y sigan funcionando en casi todas las condiciones.

Cuatro factores en particular impulsan el creciente énfasis en la resiliencia de las aplicaciones.

• Altas expectativas de los consumidores
• El coste del tiempo de inactividad
• Complejidad arquitectónica
• Presión normativa

Los clientes esperan que los servicios digitales funcionen siempre. Según Google, el 53 % de los visitantes abandonan una página móvil si tarda más de tres segundos en cargarse.

Ya sea una aplicación bancaria, una plataforma de comercio electrónico o un portal sanitario, el tiempo de inactividad puede desencadenar deserciones de clientes, reacciones negativas en las redes sociales y daños duraderos a la marca. La disponibilidad de la aplicación no es solo una métrica técnica, sino un requisito empresarial fundamental.

Las interrupciones de las aplicaciones pueden ser costosas para organizaciones de todos los tamaños. Considere un escenario común: una venta minorista lanza un evento de ventas de alto tráfico, pero el servicio de pago falla debido a la demanda adicional. En cuestión de minutos, miles de transacciones se estancan, los clientes se frustran y la empresa pierde ingresos.

Más allá de la pérdida de ventas, las interrupciones pueden desencadenar una cascada de costes secundarios, desde gastos de corrección e infracciones de los acuerdos de nivel de servicio (SLA) hasta sanciones normativas, indemnizaciones a los clientes y daños a la marca a largo plazo.

Los recientes incidentes de gran repercusión muestran lo significativo que puede ser el impacto:

• Transporte: en 2016, una interrupción del centro de datos dejó en tierra 2000 vuelos y costó a una importante aerolínea unas pérdidas estimadas de 150 millones de dólares.

• Comercio electrónico: durante un pico de ventas en 2018, las interrupciones técnicas costaron a un minorista en línea entre 72 y 99 millones de dólares en ingresos perdidos.

• Redes sociales: en 2021, una interrupción del servicio de seis horas costó a un gigante de Internet aproximadamente 100 millones de dólares en ingresos publicitarios perdidos.
  

Las arquitecturas de aplicaciones modernas tienen muchas partes móviles: microservicios, entornos multinube, bibliotecas de códigos y más. Aunque estos componentes modulares mejoran la escalabilidad, también aumentan el número de posibles puntos de fallo.  

Sin un diseño y una implementación resiliente, incluso los problemas menores pueden agravarse. El fallo de un solo microservicio puede propagarse por docenas de dependencias. Por ejemplo, si un servicio de base de datos que almacena información sobre productos deja de funcionar, puede interrumpir otras característica, como la búsqueda, las recomendaciones o el pago.

Las interrupciones de red entre regiones de la nube también pueden fragmentar los servicios y provocar incoherencias en los datos. A diferencia de un error de microservicio en el que un componente deja de funcionar por completo, estos problemas de conectividad crean un escenario de "cerebro dividido": diferentes partes de la aplicación continúan ejecutándose pero no pueden comunicarse entre sí.

Por ejemplo, el sistema de pedidos de una aplicación de comercio financiero podría desconectarse de los precios en tiempo real, causando a los usuarios ver cotizaciones incorrectas o tener experiencias de operaciones fallidas.

Las interrupciones de la interfaz de programación de aplicaciones (API) también pueden interrumpir la funcionalidad crítica. Mientras que los fallos de microservicios afectan a los componentes internos que controla la organización, las interrupciones de API implican servicios de terceros de los que depende una aplicación pero que no pueden realizar correcciones directamente. Por ejemplo, si el servicio de mapas de una aplicación de entrega se cae, los usuarios no pueden rastrear a los controladores y los controladores no pueden encontrar rutas, lo que interrumpe la experiencia aunque la aplicación siga funcionando.

En ciertos sectores y ubicaciones, los reguladores han establecido requisitos estrictos para la disponibilidad de datos, las capacidades de recuperación de aplicaciones, la mitigación de la pérdida de datos y el tiempo de actividad. Estos requisitos elevan la resiliencia de las aplicaciones de un objetivo técnico a un problema de cumplimiento.

Algunas leyes de protección y privacidad de datos ahora incluyen estándares de disponibilidad junto con mandatos de seguridad. Por ejemplo, el Reglamento General de Protección de Datos (RGPD) exige que los datos personales permanezcan protegidos y accesibles. En caso de fallo del sistema, se espera que las organizaciones recuperen los datos perdidos.

Los sectores altamente regulados, en particular, se enfrentan a algunos de los estándares más rigurosos. 

Aunque la Ley Sarbanes-Oxley (SOX) no exige explícitamente planes de recuperación ante desastres, muchas organizaciones mantienen sistemas de copia de seguridad y procedimientos de recuperación formales para ayudar a cumplir (y demostrar el cumplimiento) con la ley.

Las instituciones financieras también se enfrentan a regulaciones y recomendaciones específicas del sector de organismos como el Consejo Federal de Examen de Instituciones Financieras (FFIEC), que proporciona orientación detallada sobre la planificación de la continuidad del negocio y los objetivos de tiempo de recuperación.

En virtud de la Ley de Portabilidad y Responsabilidad del Seguro Médico (HIPAA), las entidades cubiertas deben implementar salvaguardas administrativas, físicas y técnicas para ayudar a garantizar la disponibilidad e integridad de la información médica protegida electrónica (ePHI). Aunque la HIPAA no exige el acceso 24x7, requiere que las organizaciones sanitarias mantengan el acceso a los datos del paciente cuando sea necesario para el tratamiento.

La regla de seguridad de la HIPAA requiere planes de copia de seguridad de datos, procedimientos de recuperación ante desastres y operaciones en modo de emergencia, lo que lleva a muchas organizaciones a invertir en estrategias avanzadas de conmutación por error y replicación de datos.

Para ayudar a garantizar que los sistemas puedan soportar interrupciones del mundo real, las organizaciones validan la resiliencia de las aplicaciones a través de una combinación de medición continua y pruebas proactivas. Estos enfoques permiten a los equipos monitorear el rendimiento, identificar vulnerabilidades y confirmar si las aplicaciones pueden recuperarse de manera rápida y efectiva.

Los equipos de DevOps, en particular, integran con frecuencia prácticas de resiliencia en pipelines de integración continua/entrega continua (pipelines CI/CD). Esto les permite automatizar las pruebas de los procedimientos de conmutación por error, validar los cambios de configuración y revertir las implementaciones inestables para detectar problemas a tiempo y evitar que las interrupciones lleguen a los usuarios.

Las organizaciones confían en varias métricas clave para evaluar la resiliencia de las aplicaciones. 

Las organizaciones recurren cada vez más a las pruebas para obtener una perspectiva más realista. Mientras que las métricas pueden proporcionar una base, las pruebas pueden ayudar a las organizaciones a pasar de la preparación teórica a una resiliencia probada. 

La inteligencia artificial (IA) y el machine learning (ML) están remodelando la forma en que las organizaciones abordan la resiliencia. Estas tecnologías aportan nuevas y potentes herramientas para evitar el tiempo de inactividad, pero también plantean retos únicos.

Uno de los mayores desafíos es que las cargas de trabajo de IA consumen muchos recursos. Muchos modelos se basan en unidades de procesamiento de gráficos (GPU), que son costosas y difíciles de duplicar en todas las regiones de la nube. Eso hace que la redundancia, una parte esencial de la resiliencia, sea más difícil de lograr.

Los sistemas de IA también pueden fallar de forma inesperada. Con el tiempo, su precisión podría degradarse, un problema conocido como desviación del modelo. O pueden encontrarse con entradas adversarias: datos maliciosos diseñados para engañar al sistema. Estos tipos de fallos pueden ser más difíciles de predecir y contener.

Además, cuando las características de IA se ralentizan o dejan de funcionar, un problema común en los entornos de nube debido a limitaciones de recursos o latencia, el resto de la aplicación aún debe funcionar de manera confiable, lo que ejerce una presión adicional sobre las estrategias de degradación elegantes.

Al mismo tiempo, la IA tiene importantes casos de uso para mejorar la resiliencia:

• El análisis predictivo prevé futuros fallos mediante el análisis de patrones y tendencias históricos. Esto ayuda a los equipos a sustituir de forma proactiva el hardware o ajustar los recursos antes de que se produzcan problemas, como predecir fallos en los discos con días de antelación basándose en las tendencias de temperatura y tasa de error.

• La corrección inteligente utiliza la IA para tomar decisiones de recuperación más inteligentes. Mientras que los sistemas automatizados tradicionales pueden limitarse a reiniciar un servicio averiado, la corrección con IA puede analizar patrones para elegir la estrategia óptima de recuperación, como redirigir el tráfico a regiones menos cargadas o escalar los recursos en función de la demanda prevista.

• La detección de anomalías permite a la IA identificar irregularidades sutiles en tiempo real que la supervisión basada en reglas podría pasar por alto, como combinaciones inusuales de métricas que señalan un problema emergente incluso cuando las métricas individuales parecen normales.

• Las pruebas impulsadas por IA permiten a los equipos DevOps utilizar la IA para simular escenarios de fallo más complejos en una fase más temprana del proceso de desarrollo de software.

En resumen, aunque la IA introduce una nueva complejidad, también puede permitir una recuperación más rápida, una monitorización más inteligente y aplicaciones más resilientes en general, especialmente cuando se integra en entornos nativos de la nube y pipelines de DevOps.