¿Por qué es DevOps un concepto de moda?

¿Por qué es DevOps un concepto de moda?

¿Por qué es DevOps un concepto de moda?

Si tu trabajo está relacionado con el desarrollo de software de alguna manera, es muy posible que hayas oído hablar de DevOps como una nueva filosofía que ha sabido adaptarse a los tiempos actuales y ha demostrado funcionar exitosamente. Tal vez hayas oído incluso que su boom viene porque lo han “implantado” en Microsoft (luego vemos lo de las comillas) y eso les ha salvado de la ruina (el fatídico Windows Vista), y te preguntes:

¿Cómo ha ayudado algo que parece tan técnico a que una empresa vuelva a resurgir de sus cenizas?

Respuesta: Porque ya no es algo puramente técnico, sino que puede ser aplicado en cualquier empresa en cualquier ámbito.

DevOps nació en su día para mejorar la coordinación entre desarrolladores y operaciones (de ahí el acrónimo) y su objetivo principal fue evitar algo que se oye muy a menudo:

la culpa es de…

“la culpa es de operaciones, que no ha escalado el hardware”, “la culpa es de los desarrolladores, que metieron un bug que tumbó el servidor”, “la culpa es de Fulanito, que derramó el café en el switch...”

La culpa y sus otras acepciones (“son unos inútiles”, “no han hecho su trabajo”) son un cáncer para cualquier empresa… Últimamente corre mucho la frase, con la que estoy muy de acuerdo:

“En tiempos de crisis, los idiotas buscan culpables; los inteligentes, soluciones”

Sin ser estrictamente la definición de DevOps, resume muy bien cual es su objetivo: Cambiar la cultura de la empresa, para incrementar la eficiencia, reducir los tiempos de entrega, reducir errores, etc. 

Pero OJO, DevOps no es magia. Y sobre todo, no es muchas cosas que comúnmente se le atribuyen. Vamos a intentar arrojar algo de luz…

DevOps

Qué es DevOps

DevOps trata de ayudar a la empresa a cambiar su cultura. DevOps no se “implanta” (por eso las comillas del primer párrafo), y aunque hay multitud de guías, no hay un proceso estandarizado para conseguirlo, sino que yo lo veo como un marco de buenas prácticas, donde el eje central son las personas.

Suelen identificarse 4 áreas en las que trabajar:

Colaboración

Aquí nació DevOps, en la colaboración entre desarrollo y operaciones. Se trata en buscar que los equipos colaboren unos con otros, que las necesidades y objetivos de un equipo no interfieran o bloqueen los de otros.

Sinergias

Como continuación de la colaboración, buscar en qué nos podemos apoyar entre equipos, buscando objetivos comunes y formas de abordarlos en colaboración, siendo estos retos mucho mayores que los de un equipo en solitario.

Herramientas

Todo trabajo necesita herramientas para acelerarlo. Ayudan a detectar y corregir los problemas, y a aumentar las dos áreas anteriores. Si buscar la colaboración y sinergias entre equipos es costoso, no invertir en herramientas (o en las equivocadas) lo es mucho más.

Escalabilidad:

Básicamente, cómo podemos trabajar las otras tres áreas al resto de equipos/departamentos.

Normalmente la empresa se centra en mejorar una o dos áreas, pero los avances en las 4 es la que lleva al éxito.

Qué NO es DevOps

1. Es una receta

Pues no, DevOps no es “magia”, ni una receta a seguir al pie de la letra o una bala de plata para triunfar. De hecho, lo más probable es que aumente los costes, ya que, como todo cambio, lleva aparejado un tiempo de adaptación, con todo lo que ello conlleva. Lo que no quiere decir que llegue un punto de inflexión y entonces se vean los beneficios; pero NO EXISTE esa certeza. 

Existen multitud de casos de éxito (como el de Microsoft), pero nadie habla de los fracasos.

2. Es algo sólo para los técnicos

Craso error también. Como todo cambio en una empresa, si la dirección no está implicada al 100% con él, hundirá el cambio (y a veces, a la empresa). Es más, DevOps debe llevarse a todos los ámbitos y departamentos y la dirección de la empresa es la que debe dirigir (valga la redundancia) y potenciar este cambio.

3. Es fusionar los departamentos de operaciones y desarrollo en uno

Como en DevOps la “palabra” los une, unifico los departamentos y ya tengo DevOps.

Lamentablemente, no es tan fácil (véase el punto 1, es una receta). Una versión que también se oye mucho es crear un nuevo departamento DevOps aparte o contratar una persona que sea DevOps (esta es para RRHH, que a veces se leen unas ofertas de trabajo que asustan). 

Otra versión es que no se unifican departamentos, pero se mezclan las responsabilidades, haciendo que los desarrolladores hagan tareas de operaciones o al revés y ahí queda todo. En algunas startups o empresas muy pequeñas, se creen que hacen DevOps cuando realmente es que todo el mundo hace de todo.

4. Es otra metodología de desarrollo.

Si que es verdad que DevOps se integra muy bien (sobre todo) con metodologías ágiles, pero NO ES UNA METODOLOGÍA DE DESARROLLO, ya que no es siquiera para desarrollar.

Tampoco es Integración continua/despliegue continuo

De hecho, si no lo tienes ya implantado en tu empresa, déjalo para cuando DevOps esté arraigado en ella.

DevOps

Conclusión

DevOps puede ser una cultura de trabajo muy beneficiosa, pero hay que tener presente que requiere de un cambio conjunto de todas las áreas de la empresa y que lograrlo a menudo va a acarrear un coste elevado (mayor cuanto mayor sea el tamaño de la organización). Por tanto, antes de tomar la decisión de dar este paso es imprescindible que los responsables de la misma se informen bien y tengan un entendimiento correcto de lo que ello implica, para evitar esas malas concepciones que desgraciadamente se ven tan a menudo.

Cerrar menú