La importancia del perfil DevOps

Hace unos años tuve la oportunidad de acudir a una serie de conferencias encuadradas en un curso de itSMF en las que se hablaba de la importancia del perfil DevOps para el futuro. 

Pues bien, el futuro ha llegado. Se ha confirmado que es uno de los perfiles demandados por las empresas, especialmente, las pequeñas empresas ya que en un sólo perfil, es posible aunar dos trabajadores. 

¿Qué es eso de DevOps? 

En una búsqueda rápida en google os pueden salir muchos resultados sobre esto. Una buena aproximación puede ser "un profesional que agrupa funciones de desarrollador (dev) y responsable de puesta en producción (ops)". Más detalles en esta presentación. 

Yo prefiero verlo como un complemento a uno de los 2 perfiles. Es decir, quien sabe de sistemas, no tiene por qué ser un experto en desarrollo así como puede haber quien pica un código magnífico, pero no ha de conocer todos los detalles de un sistema de producción. Pero una cosa es no ser un experto y otra muy distinta, no tener ni pajolera idea y/o no tenerlo en cuenta a la hora de realizar las funciones del puesto. Lo veo como 2 caras de una misma moneda. Si añadimos QA a la ecuación, devops es una intersección de los 3 roles.

Creo que es fundamental que un desarrollador de software tenga muy en cuenta aspectos que puedan influir en el despliegue y la calidad de su módulo/componente/sistema en un entorno de producción. Estoy pensando en consumos de recursos (memoria, cpu, red), acceso a recursos (imágenes, ficheros de texto, llamadas al sistema), scripts de compilación y/o despliegue, etc. 

En mi máquina funciona

Es típico que cuando se va a desplegar un módulo/componente/sistema el responsable de hacerlo (departamento de operación o administración de sistemas) se encuentre con que algo no funciona. Esto suele ocurrir porque los entornos de desarrollo y producción tienen poco en común. De entrada, considero esto un gran error que, a la larga, sale muy caro. 

El desarrollador debe tener un entorno lo más parecido posible al de producción. Evidentemente, debe haber algunas diferencias, ya que los objetivos de uno y otro no son exactamente los mismos, pero sí han de tener un núcleo común. Habitualmente un desarrollador pica su código en un entorno optimizado para escritorio, con herramientas específicas que facilitan su labor. Y así debe ser. Por otro lado, un sistema de producción está orientado al rendimiento, por tanto, el escritorio no tiene sentido y puede disponer de elementos que no tienen sentido para el desarrollador (cluster, bases de datos segmentadas,...).

Pero esto no quiere decir que el desarrollador se desentienda de su producto con sólo comprobarlo en su entorno de desarrollo, ya que ese módulo/componente/sistema deberá funcionar en un entorno de producción y si no funciona en él, no servirá de nada. Por tanto, ha de preocuparse de simular en todo lo posible, el entorno de producción y de hacer todo lo posible por independizar su código de la plataforma en la que se ejecutará.

Evidentemente este sistema no es infalible y los problemas surgirán a la hora de desplegar en producción (cuando digo producción, digo también entornos de pruebas o preproducción que deben ser, estos sí, idénticos a los de producción). 

Para poder afrontar estos problemas con solvencia y molestando lo menos posible a los desarrolladores, es necesario que quien despliegue tenga ciertos conocimientos de desarrollo que le permitan investigar los problemas con un criterio suficiente que permita aislar la causa y solucionarla o darle la mayor información posible al desarrollador que la solucione.La alternativa es devolver el software al desarrollador diciéndole "esto no funciona" y la reacción, lógicamente, será de poca colaboración.

La idea es que ambos perfiles se solidaricen con el otro, de modo que con un poquito de esfuerzo por cada parte, se reduce el coste total del proceso (desarrollo + puesta en producción). Esta debe ser una de las máximas fundamentales en todo equipo técnico de cualquier empresa.

¿Por qué mola integrar dev y ops en devops?

Durante mis años de trabajo he visto la función desde los 2 lados de la barrera durante tiempo suficiente y puedo asegurar que es fundamental esta colaboración.

Tuve la suerte de empezar trabajando en pruebas de sistema y aprender con los mejores. Ellas (era un equipo mayoritariamente de mujeres) me enseñaron que cuando le dices a un desarrollador que su código falla, has de hacerlo con datos y argumentos suficientes como para que no le suponga un problema sino una ayuda. De lo contrario, se posicionará en actitud defensiva y la colaboración se complica. Desgraciadamente, mucha gente se toma lo profesional como personal y casi nadie toma a bien que le digas que su trabajo (no su persona) no es perfecto.

Trabajando en desarrollo siempre he procurado tener en cuenta la parte de pruebas y lleno mi código de trazas que permitan a quien pruebe ese software (o investigue un fallo) encontrar la causa de forma rápida, sencilla y cierta. Y, en general, me lo han agradecido. Facilitar el trabajo de otros repercute en el éxito del grupo.

En resumen, que cuando uno forma parte de un equipo, ha de tener en cuenta al resto de integrantes para facilitar su trabajo. Parece evidente, pero la realidad es que tradicionalmente, no ha sido una práctica habitual. Afortunadamente, la tendencia está cambiando y las empresas se están dando cuenta de lo que ahorran con perfiles versátiles.