¿Qué es la resiliencia de las aplicaciones?

Las aplicaciones impulsan prácticamente todos los aspectos de los negocios modernos, desde el procesamiento de transacciones de clientes y la gestión de cadenas 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. El tiempo de inactividad, periodos en los que una aplicación no está disponible o no funciona correctamente, puede dañar la reputación, degradar la experiencia del usuario y provocar importantes pérdidas económicas.

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

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 fallas: la capacidad de una aplicación para continuar operando cuando falla parte de ella.

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

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

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

Los componentes comunes de las aplicaciones resilientes incluyen:

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

Redundancia significa tener versiones de respaldo de sistemas críticos. Si un sistema falla, la copia de seguridad se hace cargo, lo que 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 a menudo crean 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.

• Centro de datos: Hospedaje de aplicaciones en múltiples sitios físicos para que las Operaciones puedan Continuar incluso si una ubicación falla.

• Entornos en la nube: Distribuir aplicaciones entre regiones o proveedores -como Amazon Sitio web Services (AWS), Microsoft Azure e IBM Cloud®- para eliminar puntos únicos de fallo.

• Conexiones de red: Aprovechar múltiples proveedores de Internet o telecomunicaciones para mantener la conectividad durante las 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 las aplicaciones porque permite que los sistemas mantengan 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 particularmente útiles para contener errores. Estas capas de infraestructura ayudan a gestionar la comunicación entre microservicios en aplicaciones distribuidas, proporcionando:

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

• Interrupcióndel circuito: la malla monitorea el estado del servicio y deja de enviar solicitudes temporalmente a los servicios con dificultades, lo que les da tiempo para recuperarse y evita fallas en todo el sistema.

• Seguimiento distribuido: la malla rastrea las solicitudes a medida que se mueven entre diferentes servicios, lo que ayuda a los equipos a detectar ralentizaciones e identificar exactamente dónde ocurren los problemas.

Juntas, 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 servicios puede detectar este error, evitar que las solicitudes lleguen al servicio roto y redirigir el tráfico en consecuencia. Los usuarios pueden Continuar navegando y comprando sin interrupciones.

Laobservabilidad permite a los equipos monitorear 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 fallas) 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 una página web de carga lenta, las herramientas de observabilidad pueden ayudar a los ingenieros a rastrear la solicitud hasta el servicio que causó el retraso y solucionar el problema antes de que afecte a más usuarios.

La automatización desempeña un papel crítico en la resiliencia de las aplicaciones al permitir que los sistemas respondan a los problemas sin necesidad de intervención manual.

Por ejemplo, las herramientas de observabilidad detectan problemas y la redundancia proporciona recursos de respaldo. La automatización es lo que conecta estas capacidades, Orquestate 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 de problemas manual en segundos de respuesta automatizada.

Algunas respuestas automatizadas clave en la resiliencia de las aplicaciones incluyen:

• Failovers con scripting: Secuencias predeterminadas de acciones que transfieren automáticamente las operaciones de un sistema fallido a los sistemas de backup identificados mediante la planificación de redundancia. Por ejemplo, si la base de datos principal falla, el sistema cambia automáticamente a una base de datos de backup y redirige todo el tráfico allí en cuestión de segundos.

• Reaprovisionamiento de recursos: aprovisionamientoautomá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 autocorrección: Coordinación entre alertas de monitoreo y acciones de recuperación para restaurar el servicio sin intervenció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 administrar aplicaciones en contenedores, demuestran cómo la automatización une los componentes de resiliencia. Kubernetes puede detectar fallas a través de controles de estado integrados, reprogramar cargas de trabajo en nodos saludables y mantener la continuidad del servicio a través de flujos de trabajo automatizados.

La degradación elegante implica mantener la funcionalidad principal mientras se eliminan 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 los comentarios de los clientes y las listas de deseos para ayudar a garantizar que el carrito de compras y el proceso de pago sigan funcionando.

Las aplicaciones escalables pueden ajustar automáticamente los recursos de acuerdo con 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 multirregional, es decir, copia de datos y servicios en múltiples ubicaciones geográficas para mejorar el rendimiento y la confiabilidad. Estas capacidades permiten que los servicios distribuyan de manera inteligente el tráfico, mantengan el tiempo de actividad y minimicen 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 vivo, puede escalar automáticamente a 10 000 servidores en múltiples 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 diaria 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 costo del tiempo de inactividad
• Complejidad arquitectónica
• Presión normativa

Los clientes esperan que los servicios digitales siempre funcionen. 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 de atención médica, 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 las aplicaciones 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 marca de 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 costos secundarios, desde gastos de corrección e infracciones de los acuerdos de nivel de servicio (SLA) hasta sanciones normativas, compensación al cliente y daños a la marca a largo plazo.

Los incidentes recientes de alto perfil muestran cuán significativo puede ser el impacto:

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

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

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

Las arquitecturas de aplicaciones modernas tienen muchas partes móviles: microservicios, entornos multinube, bibliotecas de código y más. Si bien estos componentes modulares mejoran la escalabilidad, también aumentan la cantidad de posibles puntos de falla.  

Sin un diseño e implementación resiliente, incluso los problemas menores pueden escalar. Una sola falla de microservicio puede afectar a docenas de dependencias. Por ejemplo, si un servicio de base de datos que almacena información de productos deja de funcionar, puede interrumpir otras característica, como la búsqueda, las recomendaciones o el pago.

Las interrupciones de la red entre regiones de la nube también pueden fragmentar los servicios y provocar inconsistencias en los datos. A diferencia de una falla de microservicio donde 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 ejecutar pero no pueden comunicar entre sí.

Por ejemplo, el sistema de órdenes de una aplicación de negociación financiera podría desconectar de los precios en tiempo real, provocando que los usuarios vean cotizaciones incorrectas o tengan una experiencia fallida.

Las interrupciones de la interfaz de programación de aplicaciones (API) también pueden romper funcionalidad crítica. Si bien las fallas de microservicios afectan a los componentes internos que controla la organización, las interrupciones de API involucran servicios de terceros de los que depende una aplicación pero que no pueden realizar arreglos directamente. Por ejemplo, si el servicio de mapas de una aplicación de entrega deja de funcionar, 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 de datos y privacidad 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 falla del sistema, se espera que las organizaciones recuperen los datos perdidos.

Las industrias altamente reguladas, 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 respaldo y procedimientos formales de recuperación para ayudar a cumplir y demostrar el cumplimiento de 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 continuidad de 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 de salud protegida electrónica (ePHI). Si bien la HIPAA no exige el acceso las 24 horas del día, los 7 días de la semana, requiere que las organizaciones de atención médica mantengan el acceso a los datos del paciente cuando sea necesario para el tratamiento.

La regla de seguridad de HIPAA requiere planes de copia de seguridad, procedimientos de recuperación ante desastres y operaciones, lo que lleva a muchas organizaciones a invertir en Estrategias avanzadas de conmutación por error y data replication.

Para ayudar a garantizar que los sistemas puedan soportar las interrupciones del mundo real, las organizaciones validan la resistencia de las aplicaciones mediante una combinación de mediciones continuas y pruebas proactivas. Estos enfoques permiten a los equipos monitorear el rendimiento, identificar vulnerabilidades y confirmar si las aplicaciones pueden recuperar con rapidez y eficacia.

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

Las organizaciones se basan 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 visión más realista. Cuando las métricas pueden proporcionar una base, las pruebas pueden ayudar a las organizaciones a moverse de una preparación teórica a una resiliencia demostrada. 

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 presentan desafíos únicos.

Uno de los mayores desafíos es que las cargas de trabajo de IA consumen muchos recursos. Muchos modelos dependen de 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 maneras inesperadas. Con el tiempo, su precisión podría degradarse, un problema conocido como desviación del modelo. O pueden encontrar entradas adversarias: datos maliciosos diseñados para engañar al sistema. Estos tipos de fallas 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 limitacionesde recursos o latencia), el resto de la aplicación debe seguir funcionando de manera confiable, lo que ejerce una presión adicional sobre las estrategias de degradación elegante.

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

• El análisis predictivo pronostica fallas futuras mediante el análisis de patrones y tendencias históricos. Esto ayuda a los equipos a reemplazar el hardware de manera proactiva o ajustar los recursos antes de que ocurran problemas, como predecir fallas de disco con días de anticipación en función de 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 simplemente reiniciar un servicio fallido, la corrección impulsada por IA puede analizar patrones para elegir la estrategia de recuperación óptima, como redirigir el tráfico a regiones menos cargadas o escalar recursos en función de la demanda prevista.

• Ladetección de anomalías permite a la IA identificar irregularidades sutiles en tiempo real que el monitoreo basado 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.

• Laspruebas impulsadas por IA permiten a los equipos de DevOps utilizar la IA para simular escenarios de falla más complejos en una etapa anterior del proceso de desarrollo de software.

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