Acercando posturas entre DevOps y NetOps
Por si no te has dado cuenta, estamos escribiendo una serie titulada “Acortando la brecha entre…”
Se trata de tender puentes entre equipos, algo que al principio me parece una trampa.
He visto demasiados artículos que enfrentan a los equipos de DevOps y a los equipos de NetOps entre sí, casi a nivel personal. Eso no es útil, porque no se trata de las personas ni de los equipos, sino de las limitaciones y expectativas que los han formado. A la mayoría de las personas que integran esos equipos les gusta hacer lo mismo en el trabajo: cosas interesantes. Todos queremos hacer algo de lo que estemos orgullosos, que haga algo útil y que sea, bueno, genial.
Lo que diferencia a los equipos y lo que determina la forma de nuestra jornada laboral son los límites y el impacto de lo que hacemos y las herramientas a nuestra disposición. Los equipos de DevOps generalmente resuelven problemas para una aplicação o una colección de servicios. Los equipos de NetOps resuelven problemas para una empresa o para cientos de empresas 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 realmente tiene que empujar 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, disfrutando del poder de la creación y destrucción casi instantánea de recursos. Si bien los equipos de desarrollo y DevOps abstraen felizmente (y con razón) su código y lógica de negocios de los detalles esenciales de la arquitectura subyacente, lo hacen con la confianza implícita de que alguien se asegura de que sus llamadas a la API lleguen y provengan del lugar correcto. Todo el mundo quiere moverse rápido, todo el mundo quiere que las cosas no se rompan o que sean fáciles de diagnosticar y reparar cuando lo hagan. Es solo que los universos que habitan pueden verse un poco diferentes desde adentro.
Es en los límites de estas dos realidades donde pueden empezar los problemas. Está claro que, en muchas organizaciones, existe una división entre las prácticas laborales y los requisitos de SLA de los diferentes equipos. Aunque esta fricción puede considerarse algo nuevo, es una condición que hemos observado durante más de una década, simplemente porque la tecnología de F5 siempre ha sido la interconexión entre los equipos centrados en aplicação y los equipos centrados en infraestructura. Ya sea que se trate simplemente de un cambio en la cantidad de servidores back-end o en el comportamiento de la aplicação , los cambios en la arquitectura de la aplicação siempre deben reflejarse en la capa de entrega de aplicação , donde se realiza la inspección de seguridad, el enrutamiento de contenido o el equilibrio de carga. Ahora que los desarrolladores están organizando su flujo de trabajo para que sea más iterativo, estos cambios se están produciendo cada vez más rápido y, por eso, los síntomas se están volviendo más obvios.
Es por eso que es un momento tan emocionante. Porque nunca ha habido una oportunidad como ésta para superar esta brecha. En F5 hemos estado desarrollando cada vez más herramientas para conectar nuestra tecnología hiperrobusta de clase empresarial a flujos de trabajo más ágiles y automatizados. Hemos estado dando formación en estas nuevas formas de trabajar a todo aquel que lo desee. Y hemos estado transformando la forma en que trabajamos internamente.
Pero el mejor puente entre las divisiones se construye a partir de la comprensión y las experiencias compartidas. Las herramientas y los procesos para sustentar el puente no se mantendrán en pie sin la base de la colaboración. Eso es lo que más espero de trabajar más con NGINX : la oportunidad de superar la brecha y ver cómo se ven las cosas desde su lado y, lo que es más importante, desde el lado de la división del proceso de sus clientes. Trabajando juntos, podemos ayudar a los clientes conjuntos a impulsar una mejor comprensión entre todos los equipos involucrados en la entrega de aplicações seguras, rápidas e innovadoras. Por supuesto que habrá tecnología ahí, después de todo, es lo que hacemos. Pero cubrirá una gama más amplia de casos de uso y estará impulsado por una visión más completa en torno a DevOps y NetOps para satisfacer las necesidades del grupo en el que más nos centramos: nuestros clientes y usuarios.