Superando la brecha entre DevOps y NetOps

Robert HaynesResponsable de marketing técnico

Por si no te habías dado cuenta, estamos escribiendo una serie titulada «Salvando la brecha entre…»

Este trata de salvar la brecha entre equipos, algo que, de entrada, me parece una trampa.

He visto demasiados artículos que enfrentan a los equipos de DevOps y NetOps, casi hasta el punto de convertirlo en algo personal. Eso no ayuda, porque no se trata de las personas ni de los equipos, sino de las limitaciones y expectativas que les han dado forma. A casi todos los integrantes de esos equipos les gusta hacer lo mismo en el trabajo: cosas interesantes. Todos queremos crear algo de lo que sentirnos orgullosos, que sea útil y que, bueno, mole.

Lo que diferencia a los equipos y determina cómo es nuestra jornada laboral son los límites y las repercusiones de lo que hacemos, así como las herramientas de las que disponemos. Los equipos de DevOps suelen centrarse en una aplicación o un conjunto de servicios. Los equipos de NetOps se ocupan de una empresa, o de cientos de ellas en el caso de los equipos de NetOps en la nube (sí, existen). La mayoría de los equipos de redes tienen al menos un pie en el mundo físico, porque algo tiene que transportar realmente esos fotones y electrones de un lugar a otro. La mayoría de los equipos de DevOps trabajan en el mundo etéreo de lo virtual y disfrutan de la posibilidad de crear y destruir recursos casi al instante. Aunque los equipos de desarrollo y DevOps abstraen con gusto (y con razón) su código y su lógica de negocio de los detalles más minuciosos de la arquitectura subyacente, lo hacen confiando implícitamente en que alguien se asegura de que sus llamadas a la API lleguen al lugar adecuado y regresen desde él. Todo el mundo quiere avanzar rápido y evitar que las cosas fallen o, cuando lo hagan, que sean fáciles de diagnosticar y solucionar. Lo que ocurre es que los universos que habitan pueden parecer algo distintos desde dentro.

Es en los límites entre estas dos realidades donde pueden empezar los problemas. Está claro que, en muchas organizaciones, existe una brecha entre las prácticas de trabajo y los requisitos de los SLA de los distintos equipos. Aunque esta fricción pueda considerarse algo nuevo, es una situación que llevamos observando desde hace más de una década, sencillamente porque la tecnología de F5 siempre ha servido de nexo entre los equipos centrados en las aplicaciones y los centrados en la infraestructura. Ya se trate simplemente de un cambio en el número de servidores backend o en el comportamiento de la aplicación, los cambios en la arquitectura de las aplicaciones siempre han tenido que reflejarse en la capa de entrega de aplicaciones, donde se llevan a cabo la inspección de seguridad, el enrutamiento de contenidos o el balanceo de carga. Ahora que los desarrolladores están organizando su flujo de trabajo para que sea más iterativo, estos cambios se producen cada vez más rápido y, por tanto, los síntomas son cada vez más evidentes.

Por eso estamos viviendo un momento tan emocionante. Porque nunca antes habíamos tenido una oportunidad como esta para salvar esta brecha. En F5 hemos estado desarrollando cada vez más herramientas para integrar nuestra tecnología extremadamente robusta y de nivel empresarial en flujos de trabajo más ágiles y automatizados. Hemos estado ofreciendo formación sobre estas nuevas formas de trabajar a todo aquel que la desee. Y hemos estado transformando nuestra forma de trabajar internamente.

Pero el mejor puente para salvar las diferencias se construye a partir del entendimiento y las experiencias compartidas. Las herramientas y los procesos que sustentan ese puente no se mantendrán en pie sin el cemento de la colaboración. Eso es lo que más me ilusiona de trabajar más estrechamente con NGINX: la oportunidad de salvar la brecha y ver cómo son las cosas desde su perspectiva y, lo que es más importante, desde la de sus clientes al otro lado de la división entre procesos. Trabajando juntos, podemos ayudar a nuestros clientes comunes a fomentar un entendimiento cada vez mayor entre todos los equipos implicados en la entrega de aplicaciones seguras, rápidas e innovadoras. Por supuesto, habrá tecnología de por medio; al fin y al cabo, es lo que hacemos. Pero abarcará una gama más amplia de casos de uso y estará impulsada por una visión más completa de DevOps y NetOps para satisfacer las necesidades del grupo en el que más nos centramos: nuestros clientes y usuarios.

Sobre el autor

Robert HaynesResponsable de marketing técnico

Más artículos de Robert Haynes