DevOps: ¿Equipo, Rol o metodología?

Recientemente leí el artículo 6 DevOps mistakes to avoid, cuyo primer punto es “Creating a single DevOps team”. Esto genero un pequeño hilo en twitter con @recena, donde colaboró también mi amigo @thejtoken.

Finalmente, @david_bonilla, en la última bonilista, ha escrito también en torno a este tema: ¿Es DevOps un rol o una metodología de trabajo?.

En este artículo doy mis argumentos a favor y en contra.

El problema

No queda claro cuales son las competencias exactas de un DevOps. Es… “un ente” que está entre los desarrolladores (“Dev”) y los de sistemas (“Ops”).

Tampoco está claro cuáles son sus competencias, pero parecen incluir:

• Evitar problemas durante el despliegue de las aplicaciones
• Reducir los silos de conocimiento
• Incrementar la velocidad de desarrollo
• Incrementar la colaboración entre equipos
• Fomentar el auto-aprendizaje individual
• Facilitar el prototipado

Casi na.

Sin embargo, las ofertas de trabajo suelen incluir:

• Gestión de AWS/Azure/cloud.
• Jenkins, Travis u otros servidores de Integración Contínua
• Herramientas de automatización: Ansible, Chef, Puppet, …
• Kubernetes/Docker Swarm.

¿Qué tienen unas que ver con las otras? Pues en realidad poco o mucho, según se mire. El problema radica cuando nos centramos en el uso de las herramientas sin mirar al objetivo de las mismas.

Pero… ¿Debería ser un equipo, un rol en cada equipo o bien una metodología de trabajo? Voy a profundizar aquí.

DevOps es un equipo

Cuando los DevOps son un equipo, el resultado es que se crea una muralla entre los Devs y los Ops. Esta muralla tiene la forma de silo de conocimiento, justamente una de las cosas que se quería evitar.

Este silo de conocimiento suele convertirse en un cuello de botella y hacer que algunos proyectos se bloqueen por otros más urgentes.

Sin embargo, tiene algunas ventajas: la reutilización de recursos es mucho mayor que con otras soluciones y, ciertamente, se mejorará mucho la velocidad de despliegue de los proyectos gestionados.

DevOps es un rol

Si en lugar de un equipo se crea una figura de DevOps dentro de cada equipo, solucionamos el problema de los proyectos estancados y los silos de conocimiento, pero generamos otros.

Para comenzar y de acuerdo con la ley de Conway, si tienes 4 equipos trabajando en un compilador, obtendrás un compilador de 4 fases. Traducido a los DevOps, si tienes 4 equipos tendrás:

• Ansible, Puppet, Chef y SaltStack, todos resolviendo los mismos problemas.
• Jenkins sin pipelines, Jenkins con pipelines, Travis y TeamCity.
• Git, Mercurial, Subversion y gente sin control de versiones.
• …

La cuestión es que cada uno de esos DevOps va a tratar de resolver los problemas que vaya encontrando con sus conocimientos, y resultará muy difícil que comparta esos conocimientos con el resto de los DevOps, por la típica excusa de la falta de tiempo.

Al final, y de una manera muy oculta, se están generando pequeños silos de conocimiento.

Esta aproximación tiene otro problema añadido: Somos personas y tenemos la maldita costumbre de enfermar, cogernos vacaciones y dormir. Si sólo una persona en el equipo tiene este rol, tendremos un cuello de botella.

Además, en las empresas se entiende muy bien eso de “tengo 5 personas en el equipo, así que tengo 5 desarrolladores”, pero muy mal eso de “en mi equipo de 5 personas tengo un QA y un DevOps, por lo que sólo tengo 3.5 desarrolladores”. El resultado es un DevOps-programador, que dedica el tiempo que puede a las labores de DevOps y al final termina echando horas y dejando la empresa.

Pero no todo es malo… Sólo una persona dentro del equipo sabe cómo funciona el producto, cómo se despliega, qué novedades incorpora, etc. Con esta aproximación, cada DevOps conoce su producto y puede mejorar su despliegue.

DevOps es una metodología de trabajo

Si DevOps es una forma de hacer las cosas… ¿Quién se encarga? ¿Necesitamos un “Coach”?

Mi experiencia me dice que los Coach suelen terminar escaldados. Si todo va bien, ha sido gracias al equipo. Si va mal, la culpa es del Coach. En cualquier caso, muchos en la empresa verán que “no hace nada, sólo habla”. No sería la primera vez que veo que se tilda al Coach de Vende-humos.

Eso hace que yo esté en contra de los Coach “puros”. Me gusta pensar en entregar y hacer cosas palpables (más o menos, que ya sabéis cómo es eso del software). No es lo mismo entregar un esquema en un PPT que un Jenkins configurado. El problema es que, muchas veces, el segundo requiere del primero.

Si es una metodología… ¿Dónde están los roles necesarios? ¿Y sus fases de trabajo? ¿Qué entregables hay que gestionar?

Mi experiencia

Es muy bonito eso de pensar en que cada equipo tiene su DevOps, que comparten infraestructuras y conocimientos y ayudan al bien de la empresa.

Sin embargo, la realidad es que:

• los equipos se crean y destruyen de acuerdo con las necesidades de la empresa.
• las personas tienden a ponerse enfermas, coger vacaciones y abandonar la empresa.
• No todos tenemos los mismos conocimientos.

¿Qué ocurre cuando el DevOps no está? Si es un equipo, otro puede tomar el relevo, pero si es un rol o una persona del equipo, es un problema.

La solución obvia es crear un equipo, pero éste termina gestionando más y más hardware hasta que termina degradándose a sistemas y deja de cumplir la funcionalidad de DevOps.

Y claro, la evolución a esto es abstraerse y verlo como una metodología, pero no hay nada especificado y todo es muy difuso, así que depende de la dirección de la empresa que se entienda su puesto o no…

Conclusión

En realidad, más que una metodología, DevOps es una filosofía.

Lo primero que debe plantearse la empresa es si necesita un DevOps, y qué objetivos se buscan con él. Si Desarrollo trabaja bien con Sistemas, a lo mejor no es necesario.

El término DevOps nació en una conferencia de Agile, por lo que veo lógico que la definición de DevOps sea ágil. En un momento dado, una empresa puede necesitar un DevOps por grupo, un equipo determinado o un coach. O incluso una mezcla de varios de éstos. En realidad, no importa.

Lo que importa es mejorar la forma de trabajar de la empresa. Lo que importan son los individuos y las interacciones por encima de procesos y herramientas. Importa que el software funcione, y poder responder al cambio. ¿Os suena de algo? Sí, está en el Agile Manifest.

Si una persona, un equipo o cambiar la forma de trabajar puede ayudarte a conseguir estos objetivos, entonces merece la pena.

Si deja de serlo, cambia tu forma de trabajar, prueba a realizar algún cambio. Adáptate de forma ágil.