Fallar rápido es el mantra de la velocidad hoy en día. Ya sea en DevOps o en el ámbito empresarial, operar en una economía digital exige que el tiempo de actividad se acerque tanto a la perfección como sea posible.
Aunque esta filosofía es buena en teoría, en la práctica suele provocar aún más fallos. Al no centrarnos en encontrar la causa raíz (MTTR) y limitarnos a garantizar la disponibilidad (tiempo de actividad), estamos perdiendo datos valiosos a un ritmo sin precedentes. Seamos realistas: cuando lo único que importa es el tiempo de actividad, MTTR pasa a significar tiempo medio hasta el reinicio en lugar de tiempo medio hasta la resolución. Y sin una resolución —un motivo que explique el tiempo de inactividad—, no se puede evitar que vuelva a ocurrir.
Este enfoque perjudica al negocio.
En realidad, no se están perdiendo paquetes, sino fracciones de céntimo. Y, como nos enseña el clásico tópico del delincuente que desvía fracciones de céntimo de las transacciones hasta acumular millones, cada fracción de céntimo cuenta. Cada segundo que un componente, un servicio o un servidor tarda en responder, se pierde valor, tanto en términos de experiencia como de existencia. Los consumidores no toleran un rendimiento deficiente ni los tiempos de inactividad, y las cuentas de una empresa tampoco pueden permitírselos.
Y si sabe algo sobre rendimiento y ancho de banda, sabrá que ambos cálculos se basan en la cantidad de paquetes por segundo que puede procesar el sistema subyacente. Esto no solo se aplica a la red, sino también a todos los componentes que intervienen en una transacción: la aplicación, los servicios de aplicaciones, los routers, los switches y las bases de datos. Si tiene una conexión de red, está sujeto a este mismo cálculo y limitado por su capacidad para transmitir paquetes.
ADVERTENCIA: A CONTINUACIÓN, MATEMÁTICAS
La velocidad de las redes actuales garantiza que hagamos precisamente eso a un ritmo de millones de paquetes por segundo. Por supuesto, las transacciones comerciales se realizan principalmente a través de una red (literal) de transacciones HTTP, cada una de las cuales transmite información crucial para la actividad empresarial. El número de paquetes necesarios para realizar una transacción depende de la cantidad de datos requerida. Un paquete medio transporta 1500 bytes de datos (esa es la MTU). Por tanto, si un mensaje basado en HTTP que contiene una carga útil JSON representativa de una transacción requiere 4500 bytes (después del cifrado, por supuesto), eso equivale a unos tres paquetes. Seamos generosos y digamos que una transacción comercial digital típica requiere cinco paquetes. Una red de 10 Gbps puede procesar algo menos de 15 millones de paquetes por segundo. Suponiendo que haya suficiente capacidad de computación disponible, podría decirse que eso equivale a 3 millones de transacciones. Supongamos que cada transacción vale una fracción de centavo (un tercio). Eso supone 1 millón de dólares por segundo.
Ahora bien, nadie procesa realmente transacciones a esa velocidad o en ese volumen. Incluso Visa —que, indiscutiblemente, procesa datos a ritmos que la mayoría de las empresas no necesitan— afirma que su capacidad es de unas 24 000 transacciones por segundo. Suponiendo el mismo valor para esas transacciones —un tercio de centavo—, siguen siendo 8000 dólares por segundo.
La cuestión es que un fallo en la cadena de transacciones, compuesta por routers, switches, infraestructura de servicios de red y aplicaciones, infraestructura de aplicaciones y componentes, es Algo Muy Malo™. Resulta costoso, porque un fallo implica que no se procesan los paquetes ni tampoco los centavos que representan. Y no hay ninguna parte de la economía digital que no dependa de la transmisión de paquetes.
Hasta ahora, la respuesta se encuentra en el mantra «fallar rápido»: basta con poner en marcha una nueva instancia de X, Y, Z o cualquier componente que haya fallado. Pero ese componente falló *por algún motivo* y es de suma importancia descubrir y abordar la causa. Rápidamente. Porque entre el fallo y la recuperación siguen transcurriendo valiosos segundos que suponen una pérdida de valor para la empresa. Si falló una vez, es probable que vuelva a fallar. Una y otra vez.
VISIBILIDAD: LA PIEDRA ANGULAR SOBRE LA QUE SE SUSTENTA EL MTTR
Por eso la visibilidad es tan crucial para alcanzar el éxito en la economía digital. Porque es la visibilidad la que permite a todos los equipos de operaciones encontrar y subsanar la causa de los fallos. Por desgracia, la visibilidad suele sacrificarse en aras de la rapidez. No de la velocidad literal de las transacciones, sino del tiempo de obtención de valor. En nuestro afán por lanzar aplicaciones al mercado con mayor rapidez y frecuencia, no hemos invertido lo suficiente en proporcionar la visibilidad necesaria para mitigar los fallos.
De hecho, podría decirse que la filosofía de «fallar rápido» de DevOps es una respuesta a ese problema. Sin la capacidad de encontrar y abordar la causa de los fallos, DevOps ha determinado que es mejor restablecer la disponibilidad que perder el tiempo. Esa capacidad resulta cada vez más difícil de conseguir a medida que las organizaciones adoptan enfoques multinube para desplegar aplicaciones.
En 2018, menos de un tercio (31 %) citó la visibilidad como un reto de la multinube En 2019, esa cifra aumentó a más de un tercio (39 %), igualando al rendimiento y la seguridad como principales retos de la multinube. La visibilidad es un componente fundamental de la «observabilidad» global, que reúne la supervisión, el análisis y las alertas para ofrecer información valiosa sobre el estado de un sistema en cualquier momento. Esto es especialmente importante durante un fallo, porque el estado del sistema está repartido entre múltiples feudos de TI que pueden permitir o no compartir información capaz de conducir rápidamente a una resolución en lugar de limitarse a un reinicio.
La capacidad de una malla de servicios para aportar valor mediante el rastreo distribuido es un excelente ejemplo de cómo proporcionar visibilidad. Pero debemos ampliarla para incluir toda la cadena de servicios de aplicaciones que escalan y protegen las aplicaciones que se ejecutan en un entorno basado en contenedores. Esto incluye también los componentes distribuidos y las aplicaciones que se ejecutan en la nube pública y que pueden formar parte de la cadena de ejecución. Se necesita visibilidad en todos los entornos, infraestructuras y aplicaciones para encontrar y abordar los problemas que provocan tiempos de inactividad o un rendimiento deficiente.
La visibilidad es imprescindible para que las organizaciones vuelvan a medir el éxito en función del tiempo medio de resolución en lugar del tiempo medio de reinicio.
Sobre el autor
Lori MacVittie es ingeniera distinguida y evangelista jefe en la Oficina del CTO de F5, y cuenta con una amplia experiencia en entrega de aplicaciones, estrategia de automatización e infraestructura. Es conocida por convertir la complejidad en claridad, ya sea definiendo mecanismos de protección para agentes de IA, analizando arquitecturas multinube frágiles o explorando los límites de los sistemas escalables. Aporta más de treinta años de experiencia en el sector en desarrollo de aplicaciones, arquitectura de TI y operaciones de redes y sistemas. Antes de incorporarse a F5, fue una galardonada editora de tecnología. MacVittie posee un máster en Informática y es una autora prolífica cuyas publicaciones abarcan la seguridad, la nube y la arquitectura empresarial. También es una apasionada de los juegos de mesa y los videojuegos, y expresa sin complejos sus firmes opiniones sobre el queso.
Más artículos de Lori Mac VittieArtículos relacionados del blog
Proteger los endpoints de las API dificulta la seguridad de las API
Descubre las complejidades de la seguridad de las API, los retos a los que se enfrentan las organizaciones, la evolución de los ataques contra endpoints de API y la necesidad de políticas de seguridad adaptadas.
¿Qué es el sesgo de la IA y por qué es importante para TI?
Descubre los fundamentos del aprendizaje de la IA. Aprende cómo pueden surgir sesgos en la IA y qué riesgos plantean para las TI y la transformación digital.
Redefiniendo la ciberseguridad en el extremo de la nube distribuida con IA y telemetría en tiempo real
La transformación digital y la adopción de tecnologías en la nube están provocando cambios en las arquitecturas de las aplicaciones. Estos cambios introducen nuevas superficies de ataque, que son el objetivo de métodos de ataque avanzados, altamente organizados y con motivaciones económicas. Mediante el uso del framework Morpheus de NVIDIA, F5 está investigando técnicas para detectar estas amenazas avanzadas con telemetría en tiempo real y análisis basados en IA.
El papel de la nube en las aplicaciones nativas del edge
No debería sorprender que, al igual que la aparición de la nube dio lugar a las aplicaciones nativas de la nube, el edge esté impulsando un conjunto de aplicaciones nativas del edge. Sin embargo, estas aplicaciones no residirán únicamente en el edge. Al mismo tiempo, están surgiendo nuevos patrones arquitectónicos que aprovechan las aplicaciones alojadas en la nube y en el centro de datos.
La creciente diversidad de ubicaciones y usuarios está impulsando a las empresas hacia el edge
En el contexto del ámbito de las aplicaciones, el término «usuario» siempre se ha referido a la entidad que interactúa con una aplicación. Del mismo modo que los cambios en las arquitecturas de las aplicaciones impulsan cambios en las tecnologías que permiten ofrecerlas y protegerlas, los cambios en la definición de usuario han provocado cambios en los lugares donde se despliegan las aplicaciones.
El edge está impulsando un renacimiento de las infraestructuras
A medida que las organizaciones aumentan la generación de datos y tratan de extraer valor empresarial de ellos, sin duda recurrirán a la analítica y la automatización basadas en la IA y el aprendizaje automático. Precisamente este tipo de cargas de trabajo son las que más se beneficiarían de una infraestructura optimizada y, sin embargo, hoy en día son las que menos probabilidades tienen de poder aprovecharla.