El péndulo de DevOps: agilidad vs. Control

Por: Cindy Blake el 2 de agosto de 2023

La gestión de cambios en los activos de la nube es un dolor universal que sienten muchos líderes de ingeniería en la actualidad, a pesar de todos los avances en herramientas y prácticas como GitOps. Esto se debe a que, en realidad, es simplemente imposible tener todo siempre completamente bloqueado; no vivimos en una utopía con cero incidentes. Si su organización de ingeniería impide que se realicen cambios a través de la consola en la nube o en su infraestructura como código (IaC) sin cumplir con prácticas estrictas de GitOps o procesos de gestión de cambios a través de CI/CD, entonces es probable que tenga desarrolladores muy frustrados. que no pueden solucionar problemas o depurar en tiempo real y que tienen poco control en un incidente del mundo real.

La ingeniería, como todo lo demás en la vida, tiene que ver con el equilibrio.

La pandemia creó una mentalidad y una práctica completamente nuevas para gestionar la ingeniería y las operaciones distribuidas y de alta velocidad. De la noche a la mañana, las empresas que no estaban diseñadas para trabajar a distancia tuvieron que continuar sus operaciones de una manera global, distribuida y asincrónica con la que no estaban completamente familiarizadas. Esto requirió una nueva forma de pensar sobre la entrega de software y aceleró las prácticas de DevOps que respaldan esa entrega. La infraestructura de autoservicio eliminó las barreras para que los desarrolladores garantizaran un rendimiento y una velocidad continuos.

Al mismo tiempo, su nube no puede ser el salvaje oeste en el que todos crean infraestructura a medida. Resulta imposible de gestionar y las configuraciones erróneas pueden ser riesgosas. Las barreras de seguridad y la automatización de políticas se han convertido en un tema candente. Hoy en día, con los mercados tecnológicos deprimidos y los costos de la nube aumentando, parece haber una tendencia creciente a volver a bloquear las cosas, incluso a riesgo de frustrar a los desarrolladores.

Esto plantea la pregunta: ¿Cómo se puede lograr una infraestructura sin trabas para sus desarrolladores y al mismo tiempo seguir políticas y mejores prácticas de cumplimiento, riesgo y costo? Hay una manera de encontrar el equilibrio.

Como muchos aspectos de la seguridad, hemos aprendido que cuando las restricciones y barreras son demasiado altas, los usuarios finalmente encuentran formas de sortearlas. Esto también se aplica a las operaciones. Si bien a veces puede parecer más fácil bloquear todo que diseñar una forma mejor y más equilibrada para permitir a los desarrolladores moverse rápidamente, eventualmente este enfoque resulta contraproducente. Esta es exactamente la misma evolución que está experimentando la industria de aplicaciones y seguridad nativa de la nube en este momento. Todas las barreras y controles aplicados han creado demasiada fricción en los procesos de desarrollo y los desarrolladores finalmente los pasan por alto.

CloudOps puede aprender mucho de la disrupción que atraviesa la industria de la seguridad hoy en día. De la misma manera que la seguridad en un momento dado se ha vuelto completamente inútil, las alertas no en tiempo real o las alertas eventuales sobre la deriva de la infraestructura simplemente no son suficientes cuando se administra una nube efímera. Lo que realmente se necesita es el mismo tipo de escaneo continuo y en tiempo real de los activos de la nube y de IaC, similar al que aplicamos a nuestros sistemas a través del monitoreo y la observabilidad. Estas soluciones se convirtieron en una columna vertebral esencial de nuestro negocio para garantizar operaciones continuas y disponibilidad de los servicios en la nube.

A medida que adoptamos IaC y los beneficios que aporta, todo como código desbloquea una mayor agilidad y visibilidad, lo que le permite remediar automáticamente sin bloquear todo. Como dice DevOps, "avance y falle rápido". En lugar de centrarse en no cometer nunca un error, concéntrese en cómo solucionarlo de inmediato.

Al proporcionar una comparación continua de los activos reales de la nube con su estado deseado a través de IaC y GitOps, es posible detectar desviaciones de configuración y violaciones de políticas de inmediato, como cualquier otro tipo de infracción o falla importante del sistema. Los fallos y los incidentes son inevitables. No es realista, e incluso peligroso, construir sistemas con un diseño subyacente inherente que le impida cambiar algo en la consola de la nube a las 2:00 a.m. durante una interrupción.

Con un enfoque bloqueado, un desarrollador tendría que esperar la aprobación de la gestión de cambios durante un incidente de producción de alta presión, a menudo a las 3:00 a.m. (porque los dioses de los incidentes siempre hacen que sucedan en medio de la noche) o en un fin de semana. No necesitamos mirar mucho más allá del catastrófico incidente de Knight Capital que duró 40 minutos y costó 440 millones de dólares para comprender que a veces el tiempo no está de nuestro lado y que un retraso puede tener graves consecuencias.

La deriva de la nube se ha vuelto tan preocupante como el tiempo de actividad o cualquier otro aspecto crítico de las operaciones comerciales continuas, y es por eso que debemos aplicar los mismos principios para monitorear la deriva en tiempo real que aplicamos a nuestra CPU y carga. Esto permitirá recibir alertas cuando su nube y su IaC ya no estén alineados e incluso señalar problemas que se pueden prevenir en tiempo real. Puede automatizar la creación y escalamiento de tickets y también clasificar si esto es algo que debe solucionarse en tiempo real con sugerencias de solución proporcionadas o abrir un ticket para solucionarlo más tarde. La elección debe ser suya, no la debe realizar un administrador que tiene mucho menos contexto sobre los sistemas y el impacto final en el negocio.

Algunos proveedores predican codificar su nube en IaC y luego bloquearla para que nunca tenga que volver a hacerlo. Esto se siente como un deja vu; Definitivamente hemos escuchado esto antes. Suena muy parecido a la promesa de JVM de 'escribir una vez, implementar en cualquier lugar' que nunca se cumplió.

Al seguir este camino, se resignará a no agregar nunca nuevos activos en la nube ni cambiar sus configuraciones de nube. Si hay algo que hemos aprendido sobre la nube es que es un objetivo en constante movimiento. (Lea lo que la gestión de activos en la nube puede aprender del mundo de las finanzas, otra industria en constante cambio). Si esto no funcionó hace décadas con la JVM, ciertamente no funcionará en un entorno dinámico y en constante cambio como la nube. Ese es un viaje de tontos.

Existen importantes desventajas a la hora de limitar la agilidad y la velocidad. Este es un consejo ganado con esfuerzo, presenciado de primera mano por herramientas como CMDB heredada y nuevas empresas que han olvidado que la nube es efímera y, en primer lugar, ¡posiblemente la razón por la que todos la usamos! Entonces, si nuestra nube cambia constantemente y es un objetivo en constante movimiento, ¿no deberían nuestras herramientas construirse de la misma manera para mantenerse al día? Las soluciones creadas para la era nativa de la nube en rápida evolución deben buscar continuamente activos nuevos, no administrados y modificados y garantizar que su infraestructura de nube siempre siga las políticas y estándares regulatorios.

Una vez que seamos capaces de encontrar el equilibrio entre agilidad y control, podremos aprovechar los beneficios de la velocidad y la seguridad (como muestra una y otra vez la investigación de DORA) que son el punto de referencia de los equipos de alto rendimiento. La automatización de la gestión de activos en la nube puede proporcionar gobernanza, políticas y control y, al mismo tiempo, permitir la velocidad y agilidad que las organizaciones de ingeniería requieren hoy en día.

Hay una minoría de personas que afirman que no les preocupa la variación de la configuración de los activos de la nube porque tienen todo completamente bloqueado. Se pueden realizar cero cambios en la consola de la nube o en IaC sin pasar por GitOps para procesos estrictos de gestión de cambios a través de CI/CD. Apuesto a que tienen desarrolladores felices, ¡no!

Durante la pandemia, las organizaciones tuvieron que hacer felices a los desarrolladores por temor a que se fueran. Por lo tanto, DevOps se esforzó por crear una infraestructura de autoservicio para que los desarrolladores eliminen las barreras a la velocidad. Ahora, con los mercados tecnológicos deprimidos, tal vez sea más fácil bloquear las cosas, incluso si eso implica el riesgo de perder ingenieros.

A medida que adoptamos IaC y sus beneficios, no es necesario vivir en la edad de piedra de bloquear todo. ¿Cómo puede lograr una infraestructura sin trabas para sus desarrolladores y al mismo tiempo seguir políticas y mejores prácticas de cumplimiento, riesgo y costo? Hay una manera.

¿La solución? El escaneo continuo en tiempo real de sus activos en la nube y su IaC con comparación continua puede revelar inmediatamente desviaciones de configuración y violaciones de políticas. Las emergencias son inevitables. Es atrevido/estúpido/tonto pensar que nunca necesitará cambiar algo en la consola de la nube durante una emergencia o que un desarrollador esperará la gestión de cambios cuando la producción finalice a las 3:00 a. m. de un fin de semana. Sucede y debes afrontarlo.

Archivado en: Blogs, Entrega continua, Pruebas continuas, Cultura DevOps, DevOps en la nube, Práctica DevOps, TI como código Etiquetado con: devops, gitops, IaC, respuesta a incidentes, autoservicio