Ballmer-DevOpsUna de las palabras de moda en los últimos tiempos en el mundo del desarrollo del software es, sin duda, DevOp. Si lees habitualmente noticias y artículos sobre el sector (que no sean totalmente técnicos) has escuchado hablar sobre ello casi seguro.

Según muchos estudios recientes y de acuerdo a lo que afirman todas estas famosas publicaciones, los “DevOps” están llamados a ser el futuro de los trabajadores del sector. Hasta ahí llegan las afirmaciones.

Pero ¿qué es realmente un DevOp? ¿Qué características tengo que tener para serlo? ¿El DevOp nace o se hace? ;-)

Voy a tratar de explicar cómo yo lo veo a ver si puedo ayudar a aclarar las ideas...

Los cambios que está sufriendo el mundo del software

DevOp es una palabra formada por trozos de otras dos (o sea, un acrónimo), en este caso Developer y Operations. Como tal, el DevOp se encargaría de tareas propias de desarrollo y de operaciones en producción de lo que ha desarrollado (despligue, pero no solo eso). Aparentemente es como un híbrido entre un programador y un tipo de sistemas.

En las empresas grandes y profesionalizadas en EEUU todas las funciones del departamento técnico suelen estar muy bien separadas y aisladas. Así tenemos a:

  • Arquitectos de software, jefes de proyecto, desarrolladores, testers... en el lado del desarrollo,
  • Administradores de bases de datos (DBA), administradores de servidores Web, expertos en almacenamiento y virtualización, responsables de infraestructura, mantenimiento de sistemas, etc... en el lado de las operaciones.

Son como dos mundos estancos que tradicionalmente han tenido que trabajar juntos pero tienen poco que ver (lo sé, Spain is different, pero sobre eso hablaré un poco más abajo).

Si embargo en la actualidad el mundo del desarrollo del software está cambiando mucho. Y no solo me estoy refiriendo a empresas que se dediquen específicamente a desarrollo de software, sino a que casi cualquier empresa de cualquier sector tiene hoy en día la necesidad de desarrollar o mantener algún tipo de software.

Como manifestó Marc Andreessen de manera muy elocuente hace casi tres años “Software is eating the world”, y las empresas que no lo quieran ver lo van a pasar muy mal a medio plazo.

Todos estos cambios afectan al desarrollo de software de varias maneras:

  • En primer lugar, más que crear soluciones programadas desde cero, hoy en día existe una gran necesidad de pegar entre sí componentes mediante programación. Es decir, combinar virtualización, Cloud Computing, proyectos Open Source, APIs, sistemas operativos, herramientas propias... y asegurarse de que estas piezas van a funcionar juntas. En este entorno es muy importante ser capaz de comunicarse con diversos actores dentro de la empresa y fuera de ésta, al mismo tiempo que tener conocimientos técnicos importantes. En definitiva, se desarrolla menos desde cero y se “pegan” más piezas.
  • La velocidad de desarrollo lo es todo. Existe un consenso en el sector en que la capacidad de hacer pequeños ajustes, desplegarlos para probarlos y decidir sobre si se quedan finalmente en la solución, es extremadamente importante para competir. Ese ciclo continuo de desarrollo-despliegue-prueba es muy importante realizarlo rápido y a veces varias veces en paralelo. Empresas como Amazon, por ejemplo, realizan cientos de pequeños ciclos como este diariamente (no exagero), pero es la tendencia en todas las empresas que desarrollan productos para la Web.
  • La proliferación de las metodologías ágiles y la integración continua en el área de los desarrolladores, y de la automatización (con Puppet o SCSM) y la virtualización en el lado de los sistemas.

En este entorno complejo la coordinación y la velocidad son muy importantes, por lo que seguir los procesos habituales, quizá excesivamente burocratizados, significa que se entorpece la evolución del software. Debido a todo esto existe cada vez más una mayor interdependencia entre los roles tradicionales de desarrollo y de sistemas.

¿Qué es un DevOp entonces?

Los DevOps están en el centro de todo esto, ya que son perfiles que poseen un perfil técnico en desarrollo, saben de automatización y gestión de sistemas y muestran una buena capacidad de comunicación y coordinación de gente. Podemos considerarlos ubicados en la intersección de estos roles:

DevOps

  • Desarrollo de software, porque es su principal objetivo.
  • Testing: porque antes de desplegar a producción hay que asegurarse de que todo está funcionando perfectamente. En esto entran en juego las pruebas automatizadas y la integración continua, algo que el DevOp debe dominar y asegurarse de que está correctamente implementado.
  • Operaciones: asume la responsabilidad de poder desplegar las modificaciones y retirarlas según las necesidades, para poder probar y decidir rápido. No puede depender de que otro equipo diferente tenga que hacerlo o resta agilidad. Esta capacidad de despliegue y gestión no quiere decir que tengan carta blanca en los servidores de producción. De hecho muchas veces tendrán acceso al despliegue mediante programas automatizados que permiten gestión de cuestiones muy concretas únicamente. Aún así la responsabilidad es muy grande pues se está desplegando a producción y cualquier fallo grave impactará en el negocio, de ahí la importancia de la faceta anterior (testing).

Como vemos el concepto es bastante difuso, pero a pesar de ello está adquiriendo gran importancia.

¿Los chicos para todo?

En absoluto. Aunque hay mucho “hype” alrededor de todo esto y algunos han interpretado (quizá interesadamente) que un DevOp es un “chico para todo”, que programa, testea y se encarga de los sistemas, no tiene nada que ver. Es una intersección, no una unión. La figura de arriba lo ilustra bien. Por lo tanto tiene un poco de todo, pero no es todo de todos los roles. Quedan muchas áreas fuera de la intersección  y se sigue necesitando la misma gente de desarrollo, de IT/Infraestructura y de testing.

El DevOp está en el medio, como un puente entre todos esos mundos, coordinando, comunicando (algo muy importante) y también llevando a cabo algunas de las tareas de todos esos grupos.

Es más un cambio de organización, de cómo se hacen las cosas en un equipo, que un cambio de competencias de los miembros del equipo, aunque alguno o algunos deben asumir ese rol específico que sí tiene sus propias tareas.

No obstante el concepto “DevOp” afecta al comportamiento de todos los roles:

  • Desarrolladores: Muchos tienen un grave problema con esto porque están acostumbrados a que su responsabilidad termine en la implementación de una funcionalidad técnica, sin preocuparse de gestionar su propia aplicación en producción. Es muy importante desarrollar algo pensando en el ciclo virtuoso que comentaba arriba, es decir, que además de funcionar sea fácilmente testeable, y que sea fácil de integrar en producción sin interrumpir el servicio ni interferir en todo el proceso. Se acabó lo de “Pero, ¡en mi equipo funciona!”.
  • Testers: el código pasará a producción inmediatamente, por lo que hay que automatizar las pruebas y asegurarse de que el software va a funcionar siempre, no va a tener problemas de escalabilidad y se comportará de la manera esperada. A la responsabilidad habitual de tener que probar el software se une el hecho de que ahora ese software pasará a producción mucho antes.
  • Sistemas: deben facilitar la realización del ciclo virtuoso a los DevOps, ayudar a automatizar los procesos y ceder parte de su parcela de competencias (y poder) a los desarrolladores. No siempre es algo fácil de conseguir.
  • Todos: se acabaron los silos. Tradicionalmente los tres roles mencionados no hablan demasiado entre sí. Exclusivamente lo necesario. A veces incluso no están ni siquiera físicamente juntos y hay muchos silos de información que no se comparte (la información es poder, además). Una de las labores del DevOp es que esto no ocurra y que todos estén realmente en el mismo punto de la comunicación, compartiendo la información y colaborando.

¿Un nombre bonito para algo que siempre ha existido?

En España, por fortuna o por desgracia, la situación es muy diferente a la descrita al principio. En la mayor parte de las empresas españolas, que suelen ser PYMEs o micro-PYMEs, no existe tanta especialización de roles. No suele ni haber siquiera un rol específico de testing, aunque sí que la parte de sistemas y la de desarrollo suelen estar separadas.

De todos modos en empresas pequeñas siempre ha existido una relación mucho más estrecha entre desarrollo y operaciones, por lo que siempre ha habido un rol “puente” que se puede asemejar al rol de DevOp.

El director de sistemas de la empresa no es un DevOp. Sus funciones son otras y generalmente mucho menos técnicas aunque tenga un componente de esto.

Aunque no es una cuestión sólo de tamaño. Para introducir en la empresa la filosofía DevOp es necesario cambiar la forma de trabajar para que se asemeje al ciclo que menciono más arriba. Es más una forma de actuar y de pensar a la hora de desarrollar software que unas tareas concretas que debas hacer. En una PYME es más sencillo probablemente porque siempre ha existido una relación más estrecha entre todos los roles, y muchas están actuando en la práctica ya así, aunque pueden afinarlo.

En definitiva, lo que pretendía con este post es aclarar un concepto que se escucha por todas partes y que realmente es difícil encontrar por ahí algo que explique su verdadero significado.

¡Espero que te haya sido útil!

💪🏻 ¿Este post te ha ayudado?, ¿has aprendido algo nuevo?
Pues NO te pido que me invites a un café... Te pido algo más fácil y mucho mejor

Escrito por un humano, no por una IA