Hoy en día independientemente del
tipo de negocio en que una empresa esté involucrada,
la dependencia del software es enorme. La forma de construir y entregar software dicta en gran medida el éxito o
fracaso del negocio en cuestión.
Para la puesta en marcha de un
nuevo software, es necesario por una parte construirlo o como normalmente se
llama a esta actividad desarrollarlo. Una vez desarrollado es necesario
desplegarlo, es decir instalarlo en los servidores desde los cuales dará
servicio y por lo tanto se podrá hacer uso de su funcionalidad. En este
escenario no debemos olvidar hablar de la necesidad de mantenimiento del
software. Los negocios, las leyes, las normas, las modas, en definitiva el
mundo cambia y el software construido ha de ser modificado para adecuarse a las
necesidades de cada momento.
Las actividades de desarrollo y
despliegue las llevan a cabo distintas personas que tienen conocimientos
distintos y complementarios. Hay especialistas en desarrollo y especialistas en
despliegue o instalación de software. Los primeros se denominan DEVelopers en
inglés y los segundos OPerators. Los developers o profesionales de desarrollo
diseñan y construyen software y su objetivo es estar siempre cambiando el
software para mejorarlo y crear nuevas funcionalidades, en definitiva estar
siempre “cambiando”. Los operators o profesionales
de operaciones por su parte, tienen la misión de mantener el software
permanentemente dando servicio, impidiendo que se produzcan fallos y caídas inesperadas,
en definitiva mantener la “estabilidad”.
Aunque developers y operators
tienen el mismo objetivo final, resulta que sus objetivos individuales suelen
entrar en conflicto. Si queremos algo estable (operators), los cambios no son
bienvenidos (developers).
DevOps es una forma de dar nombre
a un conjunto de buenas prácticas que tienen en cuenta esta dicotomía de
intereses e intentan que el trabajo de profesionales de desarrollo y
operaciones fluya adecuadamente dando respuesta a las necesidades de software
de las organizaciones hoy en día.
Los departamentos de Tecnologías
de la Información (TI) de las organizaciones son responsables de responder con rapidez
a los cambios del software, cambios muy necesarios en un mundo cómo el actual muy
competitivo y proporcionar servicios seguros, estables y de confianza a los
clientes.
Según “DevOps Handbook” de Gene Kim y Jez Humble en TI se produce una
espiral de destrucción debido a que: primero los profesionales de operaciones
están intentando mantener estables sistemas cuya infraestructura es compleja,
frágil y en muchos casos está mal documentada, segundo alguien en la organización
(marketing, comercial, …) promete grandes funcionalidades que harán las
delicias de los clientes y que van a estar disponibles para ya, tercero todo esto encamina a que las cosas cada vez
sean más difíciles, cada profesional de desarrollo y
operaciones esté cada
vez más ocupado, el trabajo se
desestructure, se vuelva todo más complicado y cómo consecuencia la comunicación se vuelve más lenta y la
cantidad de trabajo pendiente se vuelve cada vez más grande. Y todo esto
empeora y empeora con el paso del tiempo.
Para romper esta
espiral, es necesario disponer de medios que permitan dotar de robustez a los
sistemas complejos y buscar flujo de trabajo en el ambiente de desarrollo. Esto
hará que los profesionales de TI estén entregados a un trabajo en el que el sobreesfuerzo
y la heroicidad no tengan que ser una constante, es decir un entorno
normalmente “amable” de trabajo.
Existen evidencias de que usar
prácticas recomendadas por DevOps mejora la construcción y puesta en marcha del
software. Una de ellas es el informe “State of DevOps Report” que llevan
publicando Jez Humble y Gene Kim desde 2013 anualmente (https://puppet.com/resources/whitepaper/state-of-devops-report
). En las conclusiones del informe de 2018 dice:
Cada año, el State of DevOps report nos
enseña algo nuevo. Este año nuestros datos han mostrado que mientras hay muchos
caminos individuales de realizar una transformación DevOps, hay formas más
rápidas de llegar al éxito. Las organizaciones pueden elegir entre ser
sistemáticas en cuanto a cómo evolucionan o pueden adoptar una aproximación más
particularizada. Por supuesto, es posible que una aproximación particular
funcione, pero lo que vemos entre las organizaciones que han alcanzado los
niveles más altos de evolución en DevOps, es que no llegaron ahí por
casualidad.
Estamos encantados de ser capaces de
proporcionar algo concreto y útil a los equipos que están trabajando duro para
mejorar la forma en que trabajan……
Tener en cuenta las prácticas
DevOps es crítico para que las organizaciones lidien con la confrontación de
intereses entre profesionales de desarrollo y operaciones. Mientras esto no se
consiga, los logros de TI serán muy dolorosos y como consecuencia esto hará que
las organizaciones que no adopten prácticas DevOps sean cada vez menos competitivas.
