Las decisiones sobre el desarrollo, la prueba, la implementación, el funcionamiento y el mantenimiento de las aplicaciones de la empresa no se toman en un silo. Antes, puede que el personal de operaciones de la red fuera el que tenía el control, el que tenía la última palabra antes de que pudiera hacerse algo importante. Y, para ser sinceros, a la mayoría de ellos probablemente le gustasen las cosas de esa manera.
Pero las cosas han cambiado. Ahora, en lugar de ejercer un control estricto, al equipo de NetOps le está bombardeando gente (gente de DevOps, para decirlo todo) que prefiere hacer las cosas a su manera. Cosas que el que equipo de NetOps preferiría que no se hiciesen (como pasar por alto los protocolos de seguridad de su nueva aplicación o jugar con la configuración del equilibrio de carga de esa actualización de aplicación).
Ahora, podría decirse, la gente de DevOps está tratando de mejorar las cosas. Para que sean más adaptables. Más autogestionadas y menos microgestionadas. Más Agile («ágil» en inglés).
El caso es que, en el entorno empresarial actual, DevOps necesita de NetOps para mantener el estilo de trabajo de Agile. Sencillamente, el equipo de DevOps no puede hacerlo solo (todas esas aplicaciones se ejecutan en una infraestructura subyacente, después de todo). Y no cabe esperar que el equipo de NetOps pase a un segundo lugar y renuncie a todas sus responsabilidades de siempre. Ni tampoco sería deseable que lo hiciese. NetOps representa un papel importante en el mantenimiento de la seguridad y el rendimiento de todas las aplicaciones que DevOps crea, e incorpora importantes habilidades y capacidades al flujo de trabajo de CI/CD.
Si está en DevOps y quiere de que sus colegas de NetOps profundicen más en el flujo de trabajo de CI/CD, lo primero es que ellos quieran participar y consideren el valor de cambiar el status quo. Esto es en realidad bastante fácil de hacer, dado que el fruto al alcance de todos que proporciona la automatización se consigue para todas las tareas tediosas, rutinarias y que requieren mucho tiempo, y las que hay que hacer una y otra vez. El tipo de tareas que cualquier trabajador en su sano juicio estaría feliz de delegar en un robot.
Los pedidos de cambio son un ejemplo estupendo. Abrirse camino entre una pila de pedidos, introducir manualmente cada cambio y luego comprobar que esté todo bien, porque después de todo es la novena vez que lo hace esa mañana y todo se pone en marcha al mismo tiempo y... ¿por qué está metido en esto, para empezar? ¿Rellenando pedidos de cambio todo el día, todos los días? No lo ve claro.
Hay una forma mejor de hacer estas cosas. Y es automatizar todas esas tareas redundantes y repetidas que empantanan un día interesante y productivo.
El 42 % de las organizaciones ya han automatizado sus implementaciones de servicios de aplicaciones, según nuestro Informe sobre el estado de los servicios de aplicaciones.
Los de empresa querían que nos encargásemos de esto, porque se trata del producto, ¿verdad? ¿A quién le importa si a los hombres y mujeres que lo hacen les gusta su trabajo, verdad? (¡Incorrecto!)
Sin embargo, un rendimiento y una seguridad sólidos de sus aplicaciones es un efecto secundario muy apetecible para el trabajo, ya que es menos redundante y soporífero.
La belleza de la automatización está en que, si se hace bien la primera vez, sabe que lo hará bien siempre a partir de entonces.
Al automatizar los servicios que hacen que sus aplicaciones sean fiables y seguras, no sólo se libera tiempo para proyectos más interesantes y menos repetitivos, sino que también se mejora la calidad de esos servicios. Eso es porque los flujos de trabajo bien hechos y automatizados no nacen por sí solos. El papel del ingeniero de NetOps es crear el modelo óptimo en el que opera cada flujo de trabajo automatizado, generando al mismo tiempo resultados óptimos una y otra vez.
La belleza de la automatización está en que, si se hace bien la primera vez, sabe que lo hará bien siempre a partir de entonces.
En un flujo de trabajo automatizado, NetOps no sólo consigue mantener el control de sus áreas de especialización (lo que hace que sus aplicaciones sean más rápidas, fiables y seguras), sino que también puede generar procesos automatizados que son tan sencillos de usar. DevOps no volverá a plantearse hacerse el listo (lo que, de nuevo, hace que sus aplicaciones sean más rápidas, fiables y seguras).
Casi siempre ocurre que ni el equipo de DevOps el de NetOps son capaces de dar por sí mismos con todas las soluciones necesarias para mantener las aplicaciones y datos críticos de una organización. Siempre se ha dado el caso de que estos dos equipos necesitan trabajar juntos. Y las capacidades de automatización de hoy en día ayudan mucho a reducir la fricción en torno a estas interacciones.
DevOps, NetOps, SecOps... ninguna Ops es una isla independiente. En el flujo de trabajo moderno de CI/CD, el éxito viene a través del desarrollo de metodologías claramente definidas y probadas que puedan replicarse rápida y fácilmente (es decir, automáticamente) mediante sistemas complejos. La creación de una base sólida para estos flujos de trabajo automatizados requiere una asociación sólida entre DevOps, NetOps y SecOps, y que cada uno de los equipos preste su experiencia respaldando a los demás.
No importa el entorno (nube, contenedor, etc.), sus aplicaciones dependen de servicios de aplicaciones subyacentes, servicios de red y servicios de seguridad. El cometido de NetOps es mantener el flujo de datos a través de la red, asegurarse de que las aplicaciones sean escalables y tengan capacidad de respuesta, y garantizar que los datos estén disponibles cuando se necesiten y siempre protegidos. Además, cada equipo de Ops tiene un papel que desempeñar en la reducción del riesgo, ya sea el riesgo de que su aplicación no funcione como se espera, el riesgo de que su red se vea saturada o el riesgo de que amenazas externas intenten atacar sus activos. Y es interesante observar que los principios de DevOps que impulsan buenos resultados para el desarrollo de software (cultura, automatización, medición y compartición) son los mismos principios que impulsan buenos resultados de seguridad, según el Informe de estado de DevOps de 2019 de Puppet.
Esta interacción entre los diversos equipos de Ops es constante. Es la forma en que la TI ha funcionado a lo largo de la era de Internet. Pero siempre hay oportunidad de mejorar, como cuando el proceso de desarrollo de software de Agile entró en escena, empujando los límites de la rapidez con la que las aplicaciones se pueden desarrollar e implementar. En ese momento, DevOps comenzó a realizar el gran cambio hacia un enfoque más ágil de desarrollo, adoptando una forma más rápida de llegar «del código al cliente».
Ese aumento de velocidad está impulsando el cambio abismal que ahora DevOps está presenciando. Esto tiene su lado bueno, y es que DevOps es capaz de moverse más rápido y ser más proactivo; y tiene su lado malo, que es que se puede crear fricción si los procesos de otros departamentos no están configurados para trabajar de la misma manera.
Ignorar esos otros departamentos o ignorar a los compañeros de trabajo que no se han puesto al día con la nueva forma de hacer las cosas es una mala idea. Cuando el equipo de DevOps trata de hacerlo todo por sí mismo, es ineficiente e inadecuado. Así es como los procesos se rompen (inadvertidamente o no), y los procesos rotos pueden llevar a que todo tipo de cosas vayan mal. Y no sólo para DevOps, sino para todos, incluyendo a sus clientes, que son las últimas personas que interesa afectar negativamente.
Para que DevOps haga bien su trabajo, necesita a NetOps como amigo y no como enemigo. Y el eje de cualquier asociación sólida es la comunicación. DevOps necesita comunicarse con el equipo de la red sobre cómo obtener los servicios que necesita para respaldar sus aplicaciones.
A menudo el equipo de DevOps será el experto en automatización, en el marco general, y con cosas como la infraestructura como código; pero el equipo de red es el experto en saber los recursos arquitectónicos reales que se necesitan aprovisionar y las herramientas que están disponibles para ese aprovisionamiento. Mediante el entendimiento y el respeto mutuo, DevOps y NetOps pueden identificar dónde se necesita la automatización y la mejor manera de llevarla a cabo.
El equipo de DevOps no tiene nada que perder y mucho que ganar ayudando a sus compañeros de NetOps a extender el papel de la automatización en todo el flujo de trabajo de CI/CD. La clave está en reconocer que, al igual que usted es el experto en el desarrollo de código, uno o más de sus compañeros de trabajo son expertos en el aprovisionamiento de servicios de red y seguridad para respaldar ese código. No pierda la oportunidad de ayudarles a ser los mejores expertos que puedan ser.