Es hora de que NetOps adopte la implementación continua.

La implementación continua no tiene por qué significar que todos los cambios se realicen cada vez y de inmediato. Pero hay que empezar por alguna parte.

CI/CD (Integración continua/Entrega continua) es el dominio de los desarrolladores. Es el modelo general para mejorar la velocidad de entrega, lo que realmente significa "listo para la implementación" para aquellos acostumbrados a verlo en un contexto más activo y relacionado con el usuario.

Esto no significa que NetOps pueda ignorar la CI/CD. Al contrario. Pero eso tampoco significa que NetOps tenga que mantener una relación de implementación y entrega de 1:1. La frecuencia con la que las aplicaciones están "listas para su implementación", especialmente si los desarrolladores de sus aplicaciones han perfeccionado el arte de la entrega continua, puede ser abrumadora, particularmente si NetOps aún no ha perfeccionado el arte de la implementación continua.  Pero hay espacio para acomodar una mayor frecuencia de implementación que, en algunos casos, seguramente tendrá el sabor de una implementación continua para los desarrolladores y el negocio. 

El secreto está en la diferencia entre “cambios menores” y “cambios mayores” en una aplicación.

La encuesta NetDevOps Otoño 2016 descubrió que se estaban implementando cambios menores en producción con una frecuencia mucho mayor de lo que solemos creer. Casi el 51% de los encuestados implementan cambios menores en producción más de una vez al día. Más de uno de cada tres promovía cambios importantes entre 1 y 5 por mes, y otro tercio confesaba que realizaba cambios importantes menos de una vez al mes.

Lamentablemente, la definición de cambios “mayores” y “menores” no está cuantificada, pero como suele ser habitual, dichos descriptores relativos suelen ser peculiares no sólo de una industria u organización, sino a menudo de cada aplicação. Aun así, parece que un buen número de empresas –un poco más de la mitad– están implementando cambios importantes en la producción de manera muy regular.

Lo que significa que, en el gran esquema de las cosas, estamos dando pequeños pasos en la dirección de una implementación continua. El problema es que implementar una aplicação nueva y brillante no es lo mismo que implementar actualizaciones de una aplicação existente. Incluso si agregamos nuevos servicios de red o aplicaciones, sigue siendo muy diferente en la escala de "potencial de interrupción" que la implementación de una aplicação completamente nueva.

Digamos por ahora que las aplicaciones nuevas y brillantes van a requerir más coordinación y planificación. Todavía nos quedan lo que seguramente es la mayoría de las aplicaciones en producción como objetivos potenciales para la implementación continua. Una de las cosas que podemos hacer para fomentar esto es poner cierto contexto en torno a los cambios “menores” y “mayores” con respecto a su impacto en los entornos de producción.

Los cambios menores podrían limitarse a aquellos que afectan a la aplicación internamente. Cambios en la lógica, por ejemplo. Pueden incluir parches o actualizaciones para la pila de aplicaciones (servidor web, servidor de aplicaciones, etc.), así como para la infraestructura de aplicaciones que la respalda. Básicamente, los cambios menores solo afectan a la aplicación. No requieren cambios en la red ni en los servicios que la entregan y protegen en su uso habitual.

Los cambios importantes serían, entonces, aquellos que afectan cualquier componente de la red o los servicios de la aplicación que la soportan. Estos cambios podrían requerir ajustes en una política de entrega (¿activar la compresión, por favor?) o la incorporación de un nuevo servicio, como el filtrado de URL o la inspección de solicitudes, para evitar la explotación de una vulnerabilidad descubierta recientemente. Se trata de cambios importantes que afectan a un conjunto más amplio de sistemas de producción que, a su vez, pueden o no afectar a otras aplicações.

Incluso podría darse el caso de que se elabore un sistema de puntuación más matizado que tenga en cuenta el impacto en los servicios externos. Es probable que un nuevo servicio resulte más disruptivo que una modificación de un servicio existente. Una nueva política requiere más atención a su implementación que una existente con una pequeña actualización.

Una vez que hayas acordado el “sistema” que vas a utilizar, será mucho más fácil aceptar habilitar cambios menores a pedido. Básicamente, estás pasando a una implementación continua al permitir que la entrega de aplicaciones fluya a producción siempre que se considere que tiene un impacto potencial mínimo si algo sale mal. Pequeños cambios, pequeños riesgos. Al menos esa es la suposición.

Lo que esto hace es permitir que pequeños cambios técnicos que podrían ser cambios comerciales importantes lleguen a manos de los usuarios más rápidamente. Porque a menudo estos problemas se retrasan en organizaciones grandes y tradicionales. Incluso un pequeño cambio en la interfaz de usuario podría retrasarse durante semanas, o más, debido a conflictos de programación y decisiones tomadas por juntas de control de cambios basadas en prioridades del proyecto o políticas. Incluso ese pequeño cambio podría representar una mejor experiencia de usuario que resulte en mayores tasas de conversión o retención de clientes. Si ese pequeño cambio afecta solo a la aplicación , es decir, es un cambio “menor”, ¿son las políticas de TI realmente una razón para retrasarlo?

La implementación continua no solo permite técnicamente envíos automatizados a producción, sino que también implica derribar las construcciones tradicionales que retrasan los procesos que determinan cuándo las aplicações y las actualizaciones llegan a producción (eso es cultura).

Al establecer un criterio común para diferenciar entre actualizaciones “menores” y “mayores”, entre aquellas que tienen el potencial de impactar sistemas fuera de la aplicación y aquellas que no, las organizaciones pueden habilitar la implementación continua de algunos cambios sin incurrir en riesgos adicionales ni desestabilizar la producción. Y podría significar un impacto positivo para el negocio, lo que significa que todos ganan.