La cultura DevOps, más que herramientas

¿Cómo comenzó DevOps?

El movimiento DevOps comenzó hace más de 10 años. Patrick Debois intentaba aplicar la mentalidad ágil a la infraestructura que administraba, aunque sin mucho éxito. Más tarde conoció a Andrew Clay Shafer, que trabajaba en la idea de infraestructura ágil, y a Jean-Paul Sergent, que exploraba formas de mejorar la colaboración entre los equipos de desarrolladores y los equipos de operaciones de IT.

Planearon compartir sus ideas en una conferencia. En 2009, Debois vio una charla de Flickr sobre la cooperación entre desarrolladores y operaciones para lograr múltiples despliegues por día en producción. Esto lo motivó a organizar una conferencia en Gante (Bélgica). Llamarla "Administradores de sistemas ágiles" no parecía el nombre más atractivo para la conferencia, y acabó llamándose "DevOpsDays".

Actualmente, puedes buscar trabajos de "DevOps" y encuentras una amplia variedad de habilidades requeridas y de roles. Algunas vacantes se centran en Terraform o Ansible, otras se parecen más a un arquitecto Cloud de AWS o a un experto en Docker/Kubernetes, pero pocas hablan de una mentalidad DevOps. El mismo Patrick Debois publicó un esquema sobre los roles DevOps en su blog:

Desde la conferencia que acuñó el término DevOps, la cantidad de herramientas asociadas crece día a día. Las herramientas captan toda nuestra atención la mayor parte del tiempo. Sin embargo, la colaboración entre desarrolladores y operaciones es el pilar de la mentalidad DevOps con el objetivo puesto en la entrega continua.

Estructura del equipo DevOps

Normalmente, cada equipo en la misma empresa tiene distintas responsabilidades, por lo que sus prioridades y objetivos son diferentes. Esto genera cuellos de botella y retrasos en las entregas de nuevas funcionalidades. Y esta es una de las causas fundamentales que originaron el movimiento DevOps.

La relación entre los equipos en el contexto DevOps, fue analizada por Matthew Skelton en 2013 en “DevOps Topologies”. Aquí puedes encontrar una de las formas más comunes para acelerar las entregas: crear un equipo de DevOps especializado en la automatización y CI/CD. Aunque hay que tener cuidado ya que está categorizado como un antipatrón porque este equipo puede convertirse en un silo (y DevOps se trata de romper silos, ¿verdad?).

Este estudio en torno al trabajo entre equipos (no solo DevOps) evolucionó con Manuel País y juntos escribieron el libro “Team Topologies” donde analizaron las diferentes formas de estructurar equipos para el desarrollo de software.

En el libro presentan diferentes patrones para organizar los equipos y además describen las fuerzas ocultas que impulsan las relaciones entre los equipos.

Uno de los muchos puntos clave del libro es el concepto de la carga cognitiva. Una persona es capaz de retener una determinada cantidad de información para realizar una tarea. Y lo mismo vale para un equipo.

Ahora imagina un equipo que trabaja con una gran cantidad de herramientas o un equipo que maneja muchas responsabilidades diferentes (o ambas). Inevitablemente, aparecerán retrasos y cuellos de botella debido a contextos cambiantes, dedicaciones multitarea o días llenos de reuniones. Nuevamente, la motivación DevOps es eliminar cualquier retraso para lograr un flujo rápido. El libro da indicaciones sobre cómo afrontar estas situaciones.

¿Qué será lo siguiente?

Después de una década desde que DevOps comenzó en 2009, el desarrollo de software ha evolucionado: computación en la nube, infraestructura como código, microservicios, docker, kubernetes…

Entonces, ¿DevOps sigue siendo relevante o se ha convertido en otra palabra de moda vacía? Tal vez escuchemos a Kris Buytaert hablando de ello en DevOps Barcelona 2022. Mientras tanto, te recomendamos leer:

• “13 años de devops y 130 presentaciones después: cómo cambió mi modelo mental de devops” de Patrick Debois
• “De Devoops a Devops, 10 años de aprendizaje” de Kris Buytaert