10 Mitos de DevOps

Al igual que sucede con cualquier tendencia emergente, se ha generado una buena cantidad de mitos y falacias alrededor de DevOps. A continuación analizo los más comunes.

1. Es exclusivo de empresas nativas de internet

Es cierto que empresas como Netflix, Flickr y Etsy, cuya operación está basada en el internet, son algunas de las pioneras de lo que es reconocido como el movimiento DevOps. Sin embargo, los corporativos han estado aplicando principios similares a DevOps para entregar software desde hace años, posiblemente décadas.

2. Se resume en que los de operaciones aprendan a programar

Los equipos de operaciones están acostumbrados a escribir scripts para administrar ambientes y tareas repetitivas. El concepto de infraestructura como código implica que para crear un ambiente de ejecución un administrador de sistemas crea una nueva versión del código que define a dicho ambiente. Esto provoca que ahora los equipos de operaciones tengan que crear y administrar grandes cantidades de código y por lo tanto requieran aplicar técnicas de ingeniería de software tales como control de versiones y rastreo de issues. Así que ahora los equipos de operaciones, más allá de programar,  también construyen software y gestionan su ciclo de vida.

3. Solo es para desarrolladores y operadores

Aunque su nombre (dev + ops) sugiere eso, en realidad DevOps aplica a todos los involucrados en proyectos de TI.

4. No es compatible con ITIL

Algunas personas argumentan que prácticas de DevOps tales como la entrega continua no son compatibles con los controles prescritos por ITIL. Esto no es del todo correcto. En realidad, la mayoría de los principios de ITIL se alinean bien con los principios de DevOps. El problema no es ITIL como tal, sino que ITIL es utilizado predominantemente en organizaciones con procesos lentos e inflexibles.

5. No es aplicable en industrias reguladas

Las industrias con alta regulación (ej. financiero) tienen necesidades adicionales de controles y revisiones que aseguren el cumplimiento de normas y capacidad de ser auditadas, por lo que pueden ser vistas como no aptas para algo “tan radical” como DevOps. En realidad, una buena cultura de DevOps fomenta el cumplimiento de normas y facilita la auditabilidad. En las empresas en industrias reguladas siempre habrá puntos de revisión manuales, pero esos elementos no son incompatibles con DevOps.

6. No es aplicable en outsourcing

Los equipos de outsourcing externos forman parte del flujo de trabajo. Las organizaciones deben asegurarse de que las prácticas, herramientas y procesos de estos equipos externos sean compatibles con las del resto del equipo, de tal manera que exista una comunicación y colaboración adecuada.

7. No hay DevOps sin la nube

DevOps responde a las posibilidades y restricciones que ofrece el cómputo en la nube. Sin embargo, hacer cómputo en la nube no es un requerimiento para DevOps. Las organizaciones pueden establecer procesos eficientes para obtener y administrar recursos de cómputo independientemente de si estos se encuentran hospedados en la nube.

8. No aplica para sistemas grandes y complejos

Los sistemas complejos requieren la disciplina y colaboración que brinda DevOps. Tales sistemas típicamente tienen grandes cantidades de componentes de software y hardware, que posiblemente sean construidos de acuerdo a ciclos de vida independientes. DevOps facilita la planeación y coordinación de estos ciclos para lograr entregas predecibles y estables.

9. Solo cuestión de comunicación

Algunas personas se refieren a DevOps como “ChatOps” argumentando que simplemente consiste en que los equipos se dediquen a chatear entre sí por medio de  IRC o Slack. Es cierto que DevOps depende de una buena comunicación, pero una buena comunicación sin procesos adecuados no sirve de mucho.

10. DevOps requiere liberar a producción diario

Algunas empresas argumentan orgullosamente que liberan cambios a producción todos los días, incluso varias veces al día. En ciertos tipos de empresas esto es posible y recomendable, pero en otro tipo de empresas no solo no es viable sino que no tiene mucho sentido. DevOps busca mejorar el proceso de liberación y alinearlo a la frecuencia que tenga más sentido para el negocio.