Formación escrita en DevOps

¿Qué es DevOps?

DevOps es un proceso para desarrollar, entregar y operar software. Aunque la definición parezca sencilla, conviene entender bien qué es DevOps. En las librerías y en Internet abundan las definiciones interesadas o, en el mejor de los casos, incompletas y confusas.

Algunas definiciones comerciales vinculan estrechamente DevOps a ciertas herramientas de compilación y entrega o a plataformas de infraestructura en la nube. Aunque pueden ser muy útiles para lograr los objetivos de TI y de la organización con DevOps, no basta con añadir otra herramienta sobre la que apenas tiene control porque no la ha escrito usted, o con migrar las aplicaciones a la nube, para anunciar que ya entrega con DevOps. Como dice un refrán antiguo y poco conocido, hasta los cuervos se reirían de eso.

Otra definición engañosa, aunque algo mejor, presenta DevOps como el punto de encuentro entre el trabajo y las personas de una organización de TI, donde se reúnen quienes desarrollan y prueban software y quienes se ocupan de su funcionamiento en producción. Cuando llegue al final de este libro, verá lo limitada que resulta esa definición.

La mejor forma de definir DevOps es relacionarlo con marcos de desarrollo ágil e iterativo de software y de mejora de procesos, como Scrum, Lean, ITIL, IDEAL (Initiate, Define, Establish, Act and Learn: iniciar, definir, establecer, actuar y aprender) y Six Sigma DMAIC (Define, Measure, Analyze, Improve and Control: definir, medir, analizar, mejorar y controlar).

Aunque Scrum ágil, Lean, ITIL, IDEAL y Six Sigma DMAIC pueden facilitar DevOps de manera eficiente, no se pretende que DevOps sea una combinación mejorada que englobe estas metodologías y técnicas. La razón es sencilla: salvo Scrum ágil, ninguno de esos métodos o marcos surgió específicamente para resolver los problemas de la industria del software y atender sus necesidades.

Muchas prácticas y principios de DevOps provienen del movimiento Lean, tras adaptarse, probarse, validarse y ajustarse al desarrollo, la entrega y las operaciones de software. DevOps también tomó y adaptó numerosas técnicas y filosofías del movimiento de entrega continua, el kata de mejora de Toyota, la teoría de las restricciones, el Manifiesto Ágil y la infraestructura ágil.

Movimiento Lean:

El movimiento Lean puede resumirse en siete principios:

1. Vea el conjunto y aporte valor al cliente mediante el pensamiento sistémico.
2. Integre la calidad, cree flujo y trabaje bajo demanda (pull) en vez de empujar el trabajo (push).
3. Entregue lo más rápido posible. Reduzca el tiempo que va desde la materia prima hasta el producto terminado o, en software, desde la idea hasta las ventajas y funcionalidades que ya funcionan en producción.
4. Amplíe el aprendizaje y adopte el pensamiento científico.
5. Faculte a su equipo, lidere con humildad y respete a cada persona.
6. Elimine el desperdicio de herramientas y sistemas y, sobre todo, el tiempo que puede perder en actividades improductivas.
7. Decida lo más tarde posible, justo a tiempo.

Movimiento de entrega continua:

La canalización de despliegue hace posible la entrega continua. Tiene tres funciones importantes: visibilidad, retroalimentación y despliegue continuo.

• Visibilidad - Haga visibles para todos los miembros de su equipo y de otros equipos todos los aspectos del sistema de entrega, desde la construcción y el despliegue hasta las pruebas y la publicación. Así fomenta la colaboración y ofrece transparencia a sus clientes y partes interesadas.
• Retroalimentación - Usted y su equipo se enteran de los problemas en cuanto ocurren y pueden corregirlos rápidamente antes de seguir construyendo sobre algo que ya ha fallado.
• Despliegue continuo - Despliegue y publique cualquier versión del software en cualquier entorno, incluidos los de pruebas y producción, mediante un proceso totalmente automatizado.

Kata de mejora de Toyota:

Use el kata de mejora de Toyota como rutina para pasar de la situación actual a una nueva de forma creativa, orientada a un objetivo y con sentido. Se basa en un modelo de cuatro partes:

1. Piense en una visión más amplia o una dirección mejor...
2. Comprenda las condiciones actuales.
3. Defina las siguientes condiciones objetivo.
4. Por último, avance hacia esas condiciones objetivo de forma continua e iterativa. Por el camino descubrirá obstáculos que deberá abordar y resolver.

Otros enfoques de mejora intentan predecir el camino y centrarse en la implementación. Con el kata de mejora de Toyota, se aprende y se avanza a partir de los descubrimientos que se hacen sobre la marcha. Usted y sus equipos lo utilizan para aprender mientras intentan alcanzar una condición objetivo, y se adaptan según lo aprendido.

Teoría de las restricciones:

En toda organización que entrega software, incluida la suya, hay un conflicto permanente entre TI y el negocio. Responder con rapidez a las necesidades empresariales sin perder estabilidad y previsibilidad en producción es una disyuntiva constante para TI. Sabe que no hay publicaciones en producción sin riesgo. En un sistema complejo como el suyo, no puede actuar con suficiente rapidez si quiere una publicación de bajo riesgo. Y tampoco puede garantizar un riesgo bajo si quiere publicar código rápidamente en producción.

Puede hacer frente a este conflicto cuando:

• Divide su organización de TI en muchos equipos pequeños, autónomos, independientes, autosuficientes y muy colaborativos. Empiece a ver los equipos como «unidades inteligentes» con una misión.
• Reduce el tamaño de los lotes de trabajo en curso que asigna a cada equipo.
• Reduce el tiempo de entrega, es decir, el que se tarda en convertir ideas y requisitos en ventajas y funcionalidades que ya funcionan en producción.
• Establece ciclos de retroalimentación más rápidos, fiables y continuos para asegurarse de que el software está listo para desplegar.

Manifiesto Ágil:

Con DevOps, aplica los valores fundamentales del Manifiesto Ágil:

• Valora más a las personas y sus interacciones que los procesos y las herramientas.
• Valora más el software que funciona que la documentación exhaustiva.
• Valora más la colaboración con el cliente que las condiciones y la negociación del contrato.
• Valora más responder al cambio que seguir un plan.

Infraestructura ágil:

Nuestras organizaciones, grandes o pequeñas, incluida probablemente la suya, dependen de infraestructuras de nube híbrida que combinan nubes públicas y privadas con servidores dedicados. Así aprovechan la seguridad de la coubicación junto con la flexibilidad y la escalabilidad de la nube pública.

Estas son algunas de las razones principales por las que una infraestructura ágil beneficia a DevOps:

• Paga por lo que utiliza con precios transparentes y sencillos.
• Puede aprovisionar y desaprovisionar rápidamente sus entornos de pruebas y producción a partir de su código base (IaC, infraestructura como código).
• Tiene flexibilidad arquitectónica.
• Puede expandirse fácilmente a otras regiones.
• Probablemente tenga una mejor seguridad.
• Sigue cumpliendo los requisitos sin auditorías ni costes adicionales.

CONCLUSIÓN

En esta sección hemos explicado qué es DevOps y qué no es. También hemos repasado los principales movimientos y principios en los que se basa.

Una pequeña advertencia: muchos profesionales de métodos ágiles llevan años aplicando definiciones rígidas. No se aferre a una definición de DevOps grabada en piedra que dicte cómo deben aplicarlo su organización, su producto, su servicio y, sobre todo, su equipo. No hay una solución universal ni en los métodos ágiles ni en DevOps.

Recuerde que se trata de aprender, experimentar y adaptarse. DevOps puede hacer mucho por nosotros, pero nos corresponde determinar qué versión y qué estilo de DevOps nos convienen. Eso hacen todas las organizaciones que aplican DevOps con éxito, incluidas Google, Amazon, Facebook, Netflix y Apple.