Hoy en día, nos resulta muy difícil definir DevOps porque el problema que resuelve inicialmente ya no existe.

Para algunas empresas recientes, ¡el problema nunca existió! Están haciendo todo correctamente, pero en cambio, el panorama de la ingeniería de software ha evolucionado tan rápido que el vacío se ha llenado con herramientas e ingeniería en la nube.

Estamos lejos de la época original de DevOps y su cambio cultural destinado a romper los silos entre Dev y Ops.

Los silos de desarrollo y operaciones

Allá por 2008, cuando Patricio Dubois Cuando pensó por primera vez en DevOps, estaba observando la colaboración ineficaz entre desarrollo y operaciones en un contexto en el que la gestión de proyectos acababa de pasar de la cascada a la metodología ágil.

Los equipos de operaciones en ese momento administraban todo, desde redes, servidores, máquinas virtuales, sistemas operativos y actualizaciones de software. Esto efectivamente ocultó muchas operaciones manuales. No todo era manual, pero lo era antes de que existieran Puppet, Chef y Ansible, o incluso Terraform.

Gestionar las versiones de software y servidores no fue nada sencillo y requirió mucha experiencia. Algo que impediría la entrega rápida y confiable de nuevas versiones de software.

La nube, la primera señal de que los silos se desvanecen

AWS, nacido en 2006, fue el primer gran proveedor de nube. DevOps se acuñó en 2008 y no pretendía resolver un problema de gestión de la nube, sino los verdaderos silos entre la operación de la infraestructura local. Ésta es la raíz de la confusión sobre qué es DevOps. Casi al mismo tiempo comenzaron dos cambios importantes en el panorama de la ingeniería de software.

Cuando se trata de computación en la nube, utilizamos tres modelos principales: software como servicio (SaaS), plataforma como servicio (PaaS) e infraestructura como servicio (IaaS). Debido a que hemos estado usando esas construcciones de alto nivel, la OPS (administración del sistema) casi ha desaparecido. Es como si el problema cultural original identificado por los padres de DevOps ya no existiera.

Cada modelo ofrece diferentes niveles de control, flexibilidad y gestión de la infraestructura subyacente, y muy pocas empresas mantendrían una infraestructura local.

Entonces, mientras el movimiento DevOps intentaba resolver los problemas de “silos” entre Dev y Ops , la infraestructura de la nube ya estaba eliminando parte del problema al hacer que Ops quedara obsoleto .

Sin operaciones, sin silos

Los motores clave de DevOps son “desplazarse a la izquierda” y “tú lo construyes, lo ejecutas”, lo que solo puede conducir a la transferencia de lo que era una tarea de Ops a los desarrolladores. La nube redujo la necesidad de administradores de sistemas (Ops) al ofrecer el modelo IaaS, lo que redujo el esfuerzo de los desarrolladores para administrar e implementar aplicaciones ellos mismos.

¡Podemos reformularlo para que suene mejor! Las operaciones estaban empoderando a los desarrolladores al ofrecer herramientas para simplificar la integración y la implementación del software, reduciendo así el trabajo pesado requerido por los equipos de operaciones para mantener la infraestructura. Como resultado, terminamos en una situación en la que no necesitábamos administración del sistema (Ops).

Sin embargo, necesitamos a alguien que mantenga esas "herramientas para simplificar la integración y la implementación del software".

Este nuevo rol emergente aún no tiene nombre, ya que fue presentado por el ex Ops, quienes lo rebautizaron como "chicos de DevOps". Llamémoslo ingeniero DevOps. Probablemente alguien lo dijo en algún momento y quedó grabado.

DevOps se redefinió

DevOps nunca se trató de herramientas; se trataba de cultura. La idea es que la ingeniería de software también pueda volverse más “lean” y que la entrega de software pueda realizarse justo a tiempo. Puede que el problema inicial de DevOps haya desaparecido hace mucho tiempo, pero dio origen a la idea más importante en la ingeniería de software: la entrega continua.

He apoyado durante mucho tiempo a quienes afirman que DevOps no es un rol ni un equipo, y si lo llamas así, lo estás haciendo mal. Después me di cuenta de que bueno, las cosas eran más complejas. Incongruentemente creamos un rol, "el tipo que mantiene las herramientas para simplificar la integración y la implementación del software", pero no teníamos un nombre para él.

Cuando lo piensas, ¿realmente necesitas “la persona que mantiene las herramientas para simplificar la integración y la implementación del software” si todo fuera una oferta en la nube? ¿Totalmente gestionado? ¿Funciona con solo hacer clic en un botón?

Este es el sueño de la mayoría de los proveedores de nube y de muchos productos DevOps SaaS (pensemos en GitLab, por ejemplo). La verdad no es tan simple. Si bien, en teoría, las cosas podrían haber sido simples y las tareas de operaciones podrían haberse automatizado, el servicio completamente administrado, etc. En realidad, creamos un monstruo.

Como resultado, el desafío para la mayoría de los equipos de operación/infraestructura (también conocidos como Ops) es navegar por el mapa de innumerables herramientas y servicios, comprender, implementar y conectar esas herramientas en una infraestructura y herramientas coherentes que los desarrolladores puedan usar.

DevOps atascado es esa palabra clave de moda, fácil de derivar: DevSecOps, FinOps, GitOps, MlOps, etc.

Pero si te fijas, la fragancia que queda siempre es Ops. Lo curioso es que cada enfoque tiene como objetivo eliminar las operaciones de las ecuaciones. The Ops, también conocido como "el tipo que inicia sesión en el sistema y hace cosas para que funcione".

TL;DR

Es posible que el problema original que DevOps se propuso resolver ya no exista debido al aumento de la infraestructura en la nube. Sin embargo, DevOps ha dado origen a la importante idea de la entrega continua y ha provocado un cambio cultural en la ingeniería de software.

Si bien el término "DevOps" puede haberse mantenido como una palabra de moda, ha llevado al desarrollo de nuevos enfoques como DevSecOps, FinOps y GitOps, todos los cuales apuntan a eliminar la necesidad de tareas de operaciones tradicionales.

En última instancia, el panorama de DevOps y la infraestructura de la nube evoluciona constantemente y es difícil mantenerse actualizado y seleccionar las herramientas adecuadas. Irónicamente, DevOps inicialmente significó colaboración entre Dev y Ops, pero ha evolucionado hacia excluir a Ops de la ecuación.