La promesa incompleta · Entre Dev y Ops

Hace unos días, con un compañero desarrollador comentábamos un artículo sobre un producto implementado usando sólo Serverless y que, por lo tanto, es NoOps. Durante la conversación, me llamó la atención lo fácil que es confundir el significado de NoOps, así que decidí escribir este post.

Aunque es largo, espero que os guste ;)

La importancia de la definición

Si se busca NoOps en Internet y se lee con atención las explicaciones de lo que es, es fácil encontrarse con muchas definiciones, algunas diciendo más o menos lo mismo, pero otras poniendo matices o incluso significados muy personalizados y alejados de la realidad.

NoOps es un término que, al parecer, fue acuñado por Mike Gualtieri, Vicepresidente de Forrester, por allá en 2011… desde aquello ha llovido bastante. Lo expuso en un artículo bastante controvertido, en el que proponía el término como “No” + “Ops” = “NoOps”. No parecía una declaración de paz.

Aunque explicaba que, aunque los esfuerzos de los ingenieros de sistema que hacían funcionar la aplicaciones eran críticos, los desarrolladores de las aplicaciones deberían invertir más tiempo en acercarse al negocio, no al hardware.

Reconocía la necesidad de despliegues más rápidos y más seguros, pero él creía que DevOps era, en realidad, un paso atrás, y, en su lugar, proponía NoOps, con la misma meta de mejorar los despliegues pero implicando que los desarrolladores de las aplicaciones no necesitan mantener conversaciones con los ingenieros de operaciones… nunca.

Su plan implicaba que los, entonces novedosos, conceptos como IaaS y PaaS debían permitir a los desarrolladores no sólo levantar las instancias o VMs necesarias, sino gestionar las releases.

Esto fue la génesis de un debate que aún dura hoy, pero veamos un poco cómo evolucionó.

La primera fase de NoOps

Como suele pasar, Internet hirvió con discusiones sobre el tema, y gurúes de aquí y allá salían defendiendo unas u otras opiniones. Ni siquiera había dos bandos.

Incluso, algunos eran citados hablando del tema, a menudo, fuera de contexto. Por ejemplo, un año después, Adrian Cockcroft publicó un artículo en su blog aclarando que Netflix sí que seguía teniendo un equipo de operaciones, sólo que el funcionamiento había evolucionado con el pasar del tiempo.

O, otro ejemplo, Lucas Carlson, fundador de la, pronto extinta, AppFog, en 2012 predecía que 2013 sería el año del NoOps.

Un poco más tarde, algunos defendían la necesidad de mantener equipos de operaciones, eso sí con títulos del estilo de los del Y2K.

La segunda fase de NoOps

Mientras algunos buscaban puntos intermedios, otros empezaron a ver en el Serverless el camino hacia el NoOps, y otros tantos seguían defendiendo la permanencia del concepto DevOps.

El concepto

Tal y como ocurrió con DevOps, NoOps ha sido definido, redefinido y asimilado de formas muy distintas. En muchos casos, parece que ser NoOps, según la variable interpretación de quien lo usa para ello, es un beneficio de negocio.

Igualmente que con DevOps, no es una solución, no es una herramienta, sólo es una forma de trabajar en equipo. Y, por supuesto, no significa que no haya nadie a cargo de las operaciones, sólo significa que es otra forma de llevarlas a cabo, que implica cambios en la forma de trabajar de mucha gente. No sólo para los ingenieros de sistemas, sino también para los desarrolladores.

Confusiones y errores

Sólo por poner algunas cosas claras:

DevOps no es sólo desplegar. NoOps, tampoco.
NoOps no es impopular entre los ingenieros de sistemas.
DevOps, como NoOps, defienden la automatización, pero hay que ir con cuidado con las abstracciones.
Seguro que hay negocios que pueden adoptar NoOps. Pero eso no significa que todos puedan.

Conclusión

Uno no se siente capacitado para predecir si el cielo, en el futuro, va a ser de un color o de otro. La experiencia nos debería decir que lo que existió, aunque hoy no sea necesario, no siempre desaparece del todo. Si no, que se lo cuenten a los programadores de Cobol y RPG, o a los operadores de AS400.

Lo que sí que da la sensación es que estos cambios son evolutivos, no revolucionarios. Y probablemente, no serán los últimos.