Es hora de que NetOps adopte el despliegue continuo

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

El despliegue continuo no tiene por qué implicar implementar todos los cambios de inmediato y en todo momento. Pero hay que empezar por algún sitio.

La CI/CD (integración continua/entrega continua) es el ámbito de los desarrolladores. Es el modelo general para agilizar la entrega, que en realidad significa «listo para el despliegue» para quienes están acostumbrados a entenderla en un contexto más activo y relacionado con el usuario.

Eso no significa que NetOps pueda ignorar la CI/CD. Al contrario. Pero tampoco significa que NetOps tenga que mantener una proporción de 1:1 entre despliegues y entregas. La frecuencia con la que las aplicaciones están «listas para el despliegue», especialmente si los desarrolladores de aplicaciones han perfeccionado el arte de la entrega continua, puede resultar abrumadora, sobre todo si NetOps aún no domina del todo el arte del despliegue continuo. Sin embargo, es posible dar cabida a una mayor frecuencia de despliegue que, en algunos casos, sin duda les parecerá un despliegue continuo a los desarrolladores y a la empresa.

El secreto reside en la diferencia entre los «cambios menores» y los «cambios importantes» en una aplicación.

La encuesta NetDevOps del otoño de 2016 reveló que los cambios menores se implementaban en producción con mucha más frecuencia de lo que se suele pensar. Casi el 51 % de los encuestados implementaba cambios menores en producción más de una vez al día. Más de uno de cada tres implementaba entre uno y cinco cambios importantes al mes, mientras que otro tercio reconocía que realizaba cambios importantes menos de una vez al mes.

Lamentablemente, no se cuantifica qué se entiende por cambios «mayores» y «menores», pero, como suele ocurrir, estos términos relativos suelen ser específicos no solo de cada sector u organización, sino también de cada aplicación. Aun así, parece que un número considerable —algo más de la mitad— implementa cambios importantes en producción con mucha frecuencia.

Lo que significa que, en términos generales, estamos dando pequeños pasos hacia el despliegue continuo. La cuestión es que desplegar una aplicación nueva y reluciente no es lo mismo que desplegar actualizaciones de una aplicación existente. Aunque añadamos nuevos servicios de red o de aplicaciones, sigue siendo muy distinto, en cuanto al «potencial de disrupción», del despliegue de una aplicación completamente nueva.

Así que, por ahora, digamos que las aplicaciones nuevas van a requerir más coordinación y planificación. Aun así, la gran mayoría de las aplicaciones en producción siguen siendo posibles candidatas para el despliegue continuo. Una de las cosas que podemos hacer para fomentarlo es contextualizar los cambios «menores» frente a los «mayores» en función de su impacto en los entornos de producción.

Los cambios menores podrían limitarse a aquellos que afectan internamente a la aplicación. Por ejemplo, cambios en la lógica. Podrían incluir parches o actualizaciones de la pila de la aplicación (servidor web, servidor de aplicaciones, etc.), así como de la infraestructura de la aplicación que le da soporte. Básicamente, los cambios menores afectan únicamente a la aplicación. No requieren cambios en la red ni en los servicios de aplicaciones que permiten ofrecer y proteger dicha aplicación durante su uso habitual.

Por tanto, los cambios importantes serían aquellos que afectan a cualquier elemento de la red o a los servicios que dan soporte a la aplicación. Los cambios importantes podrían requerir ajustes en una política de entrega (¿podrías activar la compresión?) o la incorporación de un nuevo servicio, como el filtrado de URL o la inspección de solicitudes, para evitar que se aproveche una vulnerabilidad descubierta recientemente. Se consideran cambios importantes porque afectan a un conjunto más amplio de sistemas de producción que, a su vez, podrían afectar o no a otras aplicaciones.

Puede que incluso desarrolles un sistema de puntuación más matizado que tenga en cuenta el impacto en los servicios externos. Es probable que un servicio nuevo cause más trastornos que un ajuste en uno existente. Implementar una política nueva requiere más atención que aplicar una pequeña actualización a una ya existente.

Una vez que hayáis acordado el «sistema» que vais a utilizar, resulta mucho más fácil aceptar que se implementen cambios menores bajo demanda. En esencia, estáis avanzando hacia el despliegue continuo al permitir que la entrega de aplicaciones pase a producción siempre que se considere que su impacto potencial es mínimo si algo sale mal. Cambios menores, menor riesgo. Al menos, esa es la premisa.

Esto permite que pequeños cambios técnicos que podrían suponer grandes cambios empresariales lleguen más rápido a los usuarios. Porque, en las grandes organizaciones tradicionales, estos cambios suelen retrasarse. Incluso un pequeño cambio en la interfaz de usuario puede demorarse semanas —o más— debido a conflictos de planificación y a decisiones de los comités de control de cambios basadas en las prioridades de los proyectos o en cuestiones políticas. Y eso a pesar de que ese pequeño cambio podría mejorar la experiencia de usuario y aumentar las tasas de conversión o de retención de clientes. Si ese pequeño cambio afecta solo a la aplicación, es decir, si es un cambio «menor», ¿son las políticas internas de TI realmente un motivo para retrasarlo?

El despliegue continuo no consiste únicamente en habilitar técnicamente el paso automatizado a producción, sino también en derribar las estructuras tradicionales que ralentizan los procesos que determinan cuándo se ponen en producción las aplicaciones y las actualizaciones (eso es cultura).

Al establecer criterios comunes para diferenciar entre actualizaciones «menores» y «mayores», entre aquellas que pueden afectar a sistemas externos a la aplicación y aquellas que no, las organizaciones pueden habilitar el despliegue continuo para determinados cambios sin asumir riesgos adicionales ni desestabilizar el entorno de producción. Y eso podría tener un impacto positivo en el negocio, lo que beneficiaría a todos.

Sobre el autor

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

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 Vittie