[ technology ]

¿Qué rayos es DevOps?

DevOps sin duda es algo ya muy normalizado en la industria de la tecnología en los últimos días, y al haberme dedicado prácticamente 10 años en esa "área de conocimiento" dentro de la Ingeniería de Software, me atrevería a decir y criticar que aún hay un entendimiento muy pobre de lo que en realidad es, y que definitivamente no dio solución a lo que buscaba: cerrar o eliminar la brecha que hay entre desarrollar y desplegar/operar el software. Como muchas cosas en la industria, nace de manera accidental y es malentendido y difundido como algo que será copiado después, como lo que yo llamaría la "fiebre del Ops".

Origen

DevOps no nació como un rol, sino por la frustración de un consultor con un problema concreto. En 2007, Patrick Debois, un consultor belga, se topó con el problema de la escasa comunicación entre equipos de desarrollo y de operaciones. En 2008 asistió a una Agile Conference en Toronto con Andrew Shafer llamada "Infraestructura Ágil", en la que fue el único asistente. De otra charla, titulada "10+ Deploys per Day: Dev and Ops Cooperation at Flickr", que Debois vio vía streaming, quedó totalmente convencido de lo que tenía que hacer. En octubre de 2009 organiza una conferencia DevOpsDays en Gante, Bélgica; siendo "DevOps" solamente un hashtag fácil de recordar, esto respaldado por una entrevista en la que él mismo lo explica en 2012. Así que digamos que "por accidente" bautizó todo un movimiento en la industria que la cambiaría para siempre.

Línea de tiempo de DevOps

Estado Actual

DevOps de acuerdo a muchas definiciones por grandes empresas de software se queda siempre por consenso en ser:

Una filosofía cultural y un conjunto de prácticas que integra a los equipos de desarrollo de software y operaciones de TI en un solo flujo de trabajo continuo, con el objetivo de entregar aplicaciones y servicios de forma más rápida, confiable y frecuente que con los modelos tradicionales de silos separados.

Pero, ¿entonces por qué ahora es un rol definido? Mi opinión es porque tiene que haber individuos especializados solamente en la parte crítica que es principalmente la automatización. Con el tiempo este rol empezó a abarcar muchas otras cosas más como la parte de SRE (Site Reliability Engineering, que ya existía en Google desde 2003) con la parte de infraestructura y monitoreo. Sin embargo, SRE se puede considerar algo mucho más completo que DevOps. De acuerdo al libro de SRE de Google:

La clase SRE implementa la interfaz DevOps.

Como podemos ver hay muchas contradicciones. Muchas personas y sobre todo empresas creen que DevOps y SRE es intercambiable; pero DevOps está más enfocado en cómo hacer suceder las cosas, y en SRE hay una mentalidad igual pero que va más allá pensando en medir y garantizar la eficiencia de las plataformas y servicios.

Hay otro rol que quisiera tocar, y es el de Platform Engineer que anda muy de moda estos días. Podría decir que muchos ven a un ingeniero de plataforma como una especie de desarrollador senior + devops senior. Cuando creo que igual aquí el verdadero traslape vuelve a ser con SRE. Por definición, platform engineering está pensado para construir plataformas internas y cadenas de herramientas que permiten el "autoservicio" en equipos de desarrollo. En mi opinión, esto es también cubierto dentro de SRE ya que también existe la creación de herramientas internas para muchos propósitos. Como ejemplo, los equipos SRE de Google terminaron creando Kubernetes. Si bien no como una solución que ofrece autonomía a los desarrolladores, el objetivo era más o menos el mismo: quitarse trabajo repetitivo (Toil, de acuerdo a SRE), para enfocarse en cosas de valor.

SRE, DevOps y Platform Engineering

DevOps sigue siendo un rol solicitado, y hoy en día intercambiable con muchos otros como Cloud, DevSecOps, Security, Performance, SRE, Platform, etc. Es importante que sepamos qué es, ya sea que desempeñemos o no el rol. Y también es importante tener bien presente que a pesar de la cantidad de roles y trabajo que se ha hecho en la industria, en la mayoría de lugares sigue rota la comunicación entre el desarrollo y la operación de software.

AI y el futuro de DevOps

Debo empezar a decir que DevOps está lejos de desaparecer. Si bien trabajas en la industria, o desempeñas algún rol de los mencionados, sabemos que aunque uno abandone el rol o el título DevOps, terminará teniendo el mismo tipo de responsabilidades y actividades. Es un rol imprescindible, y en mi experiencia aún pobremente usado en muchas empresas. He notado siempre una preferencia a seguir creando silos y subdividiendo todo creyendo que la "súper especialización" generará mejores resultados, cuando creo que solo genera aburrimiento y conformismo en muchos ingenieros.

Ahora con todo el hype del AI (Artificial Intelligence) fue el área con menos despidos, ya que fue donde se introdujeron más errores y preocupaciones de seguridad a la hora de hacer uso del AI para generar código. Creo que muchos lo vimos: cientos de personas lanzando negocios SaaS (Software as a Service) que terminaron hackeados horas después de haber sido lanzados y de captar sus primeros clientes. Va a seguir siendo un rol seguro por todo el conocimiento y experiencia que se debe tener.

Finalmente quisiera decir, que de este lado de la cancha, debemos seguir presionando para expandirnos y apuntar hacia SRE, crear colaboración con otras áreas y estar como frente unido como ingenieros cuidando la calidad y las prácticas frente a toda la burocracia y el desmejoramiento que vivimos en la industria. Aún hay muchas barreras entre áreas, y la barrera entre el desarrollo y la operación simplemente no disminuye. Hagamos conciencia, y seamos responsables: la salud de las plataformas y el bienestar de la industria dependen mayormente de los ingenieros.

Fuentes