DevOps es un conjunto de prácticas, directrices y cultura destinada a eliminar los silos entre equipos de Desarrollo y Operaciones. Es parte de un enfoque más amplio que aboga por la colaboración continua en todo el ciclo de vida del producto, desde el desarrollo hasta la operación. Se enfatiza la mejora continua a través de la automatización, la medición de resultados y el intercambio de conocimientos dentro de una cultura de apoyo.
Pero… una simple definición no nos permitirá entender en profundidad la complejidad, el peso especifico y la historia que contiene este concepto. Vamos a intentar adentrarnos en un breve recorrido sobre el significado mas puro de DevOps en el mundo de IT.
El problema del desarrollo tradicional de Software
DevOps viene a solucionar el problema del Conflicto Cronico y la Espiral Descendente del desarrollo de Software Tradicional.
Evolución de los metodos y practicas en IT
Al igual que en otras industrias, con el paso del tiempo los procesos que alguna vez funcionaron (y dieron buenos resultados) comienzan a perder efectividad y a encontrar problemas en su implementación practica y, sobretodo, en sus resultados de mercado. Lo que era “suficientemente bueno” en decadas previas, ahora no lo es.
Durante las últimas cuatro décadas, el costo y el tiempo requerido para desarrollar e implementar Features se ha reducido exponencialmente:
- En los 80-90’s: 1-5 años en llevar a producción.
- En los 2000’s (introducción de Agile): se redujo el desarrollo a 1-5 semanas. Aunque el paso a producción podíoa llevar varios meses y tener resultados catastroficos.
- En 2010 (adopción de DevOps): despliegue en producción reducido a horas o minutos gracias a la adpción de DevOps con bajo indice de incidentes.
Las organizaciones que adoptan los principios de DevOps despliegan cambios a producción cientos o miles de veces por día. Estos procesos les dan una gran ventaja sobre sus competidores. El “Fast Time to Market” y la experimentación son dos de los sustratos mas importantes de esta practica permitiendo a las organizaciones “Ganar en el Mercado”.
En la actualidad, la industria no define a una empresa como empresa de tecnología. Ya sea que fabrique vehículos, brinde atención médica o gestione el delivery de comida rápida, toda empresa hoy es una empresa de tecnología.
“A bank is just an IT company with a banking
license.” — Christopher Little.
La adopción de prácticas culturales y organizacionales sólidas en este ámbito es fundamental para su éxito. Las empresas que no las integren desde sus cimientos se arriesgan a perder competitividad y quedar relegadas en el mercado.
Esto establece la urgencia del problema que viene a resolver DevOps y nos explica que sin intervención drástica los resultades empeoran a medida que pasa el tiempo.
El conflicto crónico
En muchas organizaciones, existe un conflicto fundacional entre los equipos de Desarrollo y Operaciones.
Cada equipo tiene objetivos, responsabilidades e incentivos contrapuestos que llevan a un conflicto de intereses:
- Desarrollo se enfoca en responder a los cambios del mercado, implementando características y cambios en producción lo más rápido posible.
- Por otro lado, Operaciones se enfoca en proporcionar un servicio estable, confiable y seguro, lo que dificulta la introducción de cambios que podrían poner en riesgo la producción.
Este conflicto crea un ciclo de espieral descendente que resulta en:
- Tiempos de entrega cada vez más largos.
- Exceso de burocracia de cambios.
- Reducción de la calidad de los productos.
- Descenso de la confiabilidad de los sistemas.
- Incremento de disrrupciones de Servicio.
- Acumulación de deuda técnica.
El término Deuda Tecnica es un termino acuñado por Ward Cunningham, que es analogo a la Deuda Financiera. Describe como las desiciones que tomamos conllevan a problemas que se tornan incrementalmente mas dificiles de resolver a lo largo del tiempo. Esto reduce las opciones que tenemos disponibles para resolverlos.
Los 3 actos del Conflicto Cronico:
Acto 1: Operaciones.
- El equipo de Operaciones lucha con sistemas complejos, poco documentados y frágiles. Su objetivo es mantener la infraestructura Online para poder dar valor a los clientes. Todos los días ejecuta operaciones de Workarounds lo que lleva a la acumulación de deuda técnica. Sin tiempo para solucionar los problemas a largo plazo.
Acto 2: Desarrollo.
- Bajo presión de entregar un nuevo, muy grande y con gran costo, el equipo de desarrollo ejecuta mas workarounds y agrega más deuda técnica, prometiendo arreglar los problemas más adelante. Todo esto para llegar con la fecha de entrega seteada por el C-Level y los PM.
Acto 3: Espiral descendente.
- Todo se torna un poco mas dificil de manera incremental. Los cambios pequeños causan problemas cada vez mas grandes. La acumulación de deuda técnica y los procesos ineficientes conducen a tiempos de entrega más largos, peor calidad y una incapacidad para responder a los cambios y necesidades del mercado. Tampoco se puede proporcionar un servicio estable a los clientes. Esto resulta en una pérdida competitiva en el mercado.
En el día a día, nos encontramos en situaciones donde los tiempos de implementación de cambios requieren meses. Esto es especialmente común en organizaciones grandes y complejas que trabajan con aplicaciones monolíticas, entornos escasos para pruebas de integración, tiempos prolongados para pruebas y despliegue en producción, alta dependencia de pruebas manuales, y múltiples procesos de aprobación requeridos.
Esto se logra más fácilmente cuando contamos con una arquitectura modular, bien encapsulada y con acoplamiento flexible, de forma que equipos pequeños puedan trabajar con altos niveles de autonomía. Los fallos, al ser pequeños y contenidos, no causan interrupciones globales.}
¿En qué se basa DevOps?
La Convergencia de DevOps (John Willis)
Converger es un verbo que significa dirigirse hacia un mismo punto o lugar, ya sea de forma física o abstracta.
El término “convergencia” en el contexto de DevOps está relacionada a la forma en que esta disciplina fusiona diversas filosofías, metodologías y movimientos de gestión.
DevOps no surgió como una idea aislada, sino que representa una evolución de pensamiento de varias áreas. La convergencia de estas diversas filosofías y metodologías le da a DevOps su profundidad y poder transformador. Al sintetizar años de conocimiento de diferentes disciplinas, DevOps representa un avance significativo en la entrega de valor en el proceso de desarrollo de software.
Influencias directas de DevOps
DevOps se inspira directamente en muchos de los procesos de la Revolución de Manofactura de los 80’s y “toma prestados” muchos de sus conceptos fundacionales y practicas.
Después de las recesiones a principios de los 80, la industria de la manofactura, buscaba competitividad en un mercado globalizado. La Empresas que aplicaron los Principios de Lean mejoraron la productividad de planta, los Lead Times, aumentaron la calidad de sus productos y la satisfacción de los clientes.
Estas prácticas y procesos incluyen:
- Lean Manufacturing: DevOps utiliza y se inspiera en los principios Lean de manufactura para optimizar el flujo de trabajo, reducir el desperdicio y aumentar la eficiencia.
- Theory of Constraints (Teoría de restricciones): De esta teoría, DevOps adopta la práctica de identificar y abordar los cuellos de botella en el proceso de desarrollo, lo que mejora la entrega general.
- Toyota Kata: Este enfoque promueve la mejora continua y sistemática a través de la experimentación. DevOps integra esta cultura para optimizar continuamente los procesos.
- Organizaciones de alta fiabilidad (HROs): DevOps incorpora las lecciones de las HROs (como aviación o atención medica) sobre cómo crear sistemas confiables y con menor tendencia a fallas.
- Modelos de gestión de alta confianza: Estos modelos promueven culturas de colaboración, autonomía y responsabilidad. DevOps refuerza estos principios, creando un ambiente donde los equipos puedan innovar y moverse rápido.
- Agile: DevOps es considerado una continuación natural del movimiento Agile, enfatizando la adaptabilidad, entrega rápida y ciclos de retroalimentación para responder a los cambios.
Componentes de DevOps
Entonces, a partir de lo mencionado anteriormente, DevOps viene a solucionar la problematica del conflicto crónico y la espiral descendente. En este sentido, nos enfocaremos en 3 componentes claves:
- Personas.
- Procesos.
- Herramientas.
La sinergia entre estos 3 componentes es fundamental para poder solucionar el conflicto cronico con DevOps.
The Three Ways (los tres caminos)
Este termino es introducido en los libros The DevOps Handbook y The Phoenix Project. Los autores Gene Kim, Patrick Debois, John Willis y Jez Humble, describen los valores y filosofia que enmarcan los procesos, procedimientos y los pasos practicos necesarios para llevar a cabo DevOps.
Se trata de tres principios interconectados que, al implementarse juntos, permiten a las organizaciones mejorar significativamente su capacidad para entregar software de forma rápida, confiable y segura.
The First Way: Pensamiento de Flow y Sistemas.
Pone foco en visualizar al sistema completo como un solo Flujo de Trabajo y no como un silo de trabajo o departamento.
El flujo tiene una dirección de izquierda a derecha. De Desarrollo a Operaciones.
Para optimizar este flujo, el Primer Camino pone foco en:
- Hacer el trabajo visible. Visibilidad de los equipos.
- Reducir el tamaño de los Batches de Trabajo.
- Foco en la Calidad. Evitar que errores sean pasados de un lado a otro.
- Optimizar por los Objetivos Globales.
Algunas de las practicas utilizadas en este Camino son:
- Estrategias de visualización Kanban.
- Continous Integration.
- Continous Delivery.
- Continous Deployment.
- Test Automatizados.
- Limitar el Work In Progress (WIP) de cada colaborador.
- Reducir el número de Handoffs.
The Second Way: Amplificar los Feedback Loops.
El Segundo Camino promueve los Feedback Loops constantes y, sobretodo, lo mas rapido posible.
En este caso el flujo va de Izquierda a Derecha. De Operaciones a Desarrollo.
Propone amplificar el Feedback para prevenir que los problemas sucedan nuevamente y promueve, como nombramos anteriormente, más rapida detección y recuperación. Esto nos permite crear sistemas cada ves mas seguros donde los problemas son encontrados y resueltos antes de que ocurra una falla catastrofica.
Para optimizar este flujo, el Primer Camino pone foco en:
- Brindar procesos de Feedback Loops constantes desde Ops a Dev.
Algunas de las practicas utilizadas en este Camino son:
- Continous Build.
- Pruebas Automatizadas.
- Telemetría y Monitoreo.
- SLIs, SLOs y SLAs
- User Feedback.
The Third Way: La Cultura del Aprendizaje y Experimentación Continua.
Este camino encarna uno de los conceptos mas importantes de DevOps: la cultura organizacional.
Promueve la creación de una cultura organizacional que sea:
- Generativa.
- Altamente confiable.
- Que soporte experimentación basada en el método cientifico.
- Y que facilite el Aprendizaje Continuo a partir de aciertos pero tambien de errores.
A partir de este ultimo punto, el Tercer Camino, tiene la principal idea de generar una acumulación de conocimiento acumulativo y colectivo dentro de la organización. Sin importar, el equipo al que un ingeniero pertenezca lo hará con años de acumulación de practicas, conocimiento y experimentación.
Algunas practicas que este Camino implementa:
- Continous Learning.
- Experimentación.
- Blameless postmortems.
- Retrospectivas.
“The Three Ways” son mucho más que un simple conjunto de prácticas técnicas. Proporcionan un camino estratégico para que las organizaciones transformen su forma de desarrollar y entregar software, permitiéndoles competir y prosperar en la era digital.
De la Teoría a la Practica
Entender los conceptos claves, sus intenciones y fundamentos basicos son necesarios para poder comprender DevOps. Nos permitirá tomar desiciones concientes y en linea con lo que la organización necesita.
Pero…
Estos conceptos son muchas veces abstractos y poco practicos a la hora de idear su implementación. En esta seccion intentaremos acercarnos un poco más a la practica de DevOps.
Patrones practicos
Es importante entender que, luego de muchos años de implementación en miles de organizaciones en el mundo, DevOps desarrollo patrones prácticos que se repiten en la mayoría de los casos de implementación, más allá de las individualidades particulares y del contexto:
1. Reducir los Silos Organizacionales
Esto significa eliminar las barreras que existen entre Dev y Ops. Esto podemos lograrlo a través de la configuración de objetivos e incentivos comunes ademas de una Responsabilidad Compartida entre las areas involucradas dentro de la Cadena de Valor de producto.
2. Aceptar la falla como algo normal
Se trata de reconocer que los errores son inevitables en cualquier proceso de desarrollo y que no deben ser motivo de culpa o miedo. Es importante crear una cultura de aprendizaje continuo donde los errores se analizan para comprender las causas y evitar que se repitan en el futuro.
3. Implementar cambios graduales
DevOps promueve realizar cambios pequeños y controlados en horas o días, en lugar de intentar realizar cambios masivos de una sola vez que pueden llevar meses o años. Esto se realiza reduciendo el tamaño de los Batches de Trabajo permitiendo que los equipos se adapten gradualmente al cambio y que se puedan identificar y corregir los problemas a medida que surgen.
4. Aprovechar las herramientas y la automatización
Se trata de utilizar un set de herramientas compartidas y aprovechar la Automatización de tareas repetitivas que no agregan valor al producto final, para liberar tiempo a los equipos para que puedan enfocarse en actividades más creativas y estratégicas. La automatización también permitirá mejorar la calidad, confiabilidad y seguridad del producto.
Automatizar el trabajo del proximo año.
5. Medir todo
Se refiere a la importancia de recopilar datos sobre el proceso de desarrollo y la entrega de software para poder medir el progreso y tomar decisiones informadas. Las métricas pueden ayudar a identificar áreas de mejora, a evaluar la eficacia de las prácticas DevOps.
Esto aplica tanto para los sistemas en producción como para los procesos de trabajo de los equipos de desarrollo y operaciones.
Herramientas comunes
El paso del tiempo y la adopción de DevOps por parte de las organizaciones, a llevado a la recopilación de patrones comunes de las herramientas que se utilizan para satisfacer los pilares conceptuales a implementar DevOps.
| Herramienta DevOps | Descripción | Ejemplo |
| Planning & Collaboration | Definición de requerimientos, planificación de sprints, seguimiento de tareas, comunicación entre equipos. | Jira, Confluence, Trello |
| Source Code Management (SCM) | Herramientas y prácticas para rastrear y controlar cambios en el código fuente. | Git, GitHub, Bitbucket |
| Continuous Integration/Delivery | Automatización de la integración y entrega de cambios de código en un repositorio centralizado para lanzamiento rápido y automatizado de cambios. | Jenkins, GitLab CI, CircleCI |
| Container Orchestration | Gestión de la vida útil de los contenedores en un entorno de muchos contenedores. | Kubernetes, Docker Swarm, Amazon ECS |
| Package Management | Gestión de paquetes de software, que permite a los desarrolladores importar y utilizar bibliotecas y herramientas de terceros en sus proyectos de una manera fácil y controlada. | npm, NuGet (para .NET), Maven,pip (para Python), Composer , RubyGems. |
| Continuous Monitoring | Registro y análisis automatizado de eventos y métricas para comprender el rendimiento y el estado operativo. | Prometheus, Grafana, Datadog |
| Cloud | Uso de recursos de computación ofrecidos a través de internet por proveedores de servicios en la nube. | AWS (Amazon Web Services), Microsoft Azure, Google Cloud |
| Infraestructura como código | Gestión y aprovisionamiento de infraestructuras de TI mediante archivos de definición, en lugar de configuración manual de hardware o software. | Terraform, Ansible, Azure ARM, AWS CloudFormation |
Estas herramientas y procesos juntos conforman un conjunto robusto de prácticas para agilizar y mejorar el desarrollo y la operación de software en un ciclo de vida continuo.
¿Existe tal cosa como un rol de “DevOps Engineer”?
El término “DevOps Engineer” es común en el mundo de la tecnología; muchos profesionales lo destacan en sus resúmenes y perfiles de LinkedIn. Sin embargo, surge la pregunta: ¿Existe realmente un rol que se ajuste a la definición completa de un “DevOps Engineer”?
Desde una perspectiva teórica de DevOps, considerando la complejidad del concepto y sus diversos componentes e implementaciones, la respuesta podría ser negativa. En la teoría, no hay una sola persona que pueda encarnar y aplicar DevOps en su totalidad dentro de una organización. La implementación efectiva de DevOps requiere colaboración y sinergia entre múltiples individuos, procesos y procedimientos.
Es por esto que, desde un punto de vista teórico, el rol de “DevOps Engineer” no existe como tal.
Ahora bien…
Existe un largo trecho entre la teoría y la práctica. En el proceso de implementar DevOps, y basándonos en una diversidad de casos prácticos, el mercado laboral ha configurado una descripción de trabajo que converge numerosas prácticas y tecnologías. Este perfil engloba las funciones necesarias para llevar a cabo los fundamentos y principios de DevOps desde un punto de vista practico e individual.
Es así como el papel del “DevOps Engineer” ha ganado terreno. Los reclutadores de RRHH, las ofertas de trabajo y muchos Managers y equipos buscan a estos roles en el mercado.
En consecuencia, desde una perspectiva práctica y basada en la realidad, podemos afirmar que el puesto de “DevOps Engineer” sí existe, es reconocido y utilizado ampliamente.
¿Qué es DORA?
DORA es el acrónimo de DevOps Research and Assessment, una iniciativa que comenzó como un proyecto de investigación que buscaba comprender las prácticas de alto rendimiento en el campo del desarrollo y operaciones. Con el tiempo, se estableció como un conjunto de métricas que sirven como puntos de referencia fundamentales para los equipos de DevOps. Estas métricas ayudan a las organizaciones a entender en que lugar del proceso de Adopción de DevOps se encuentran.
Las 4 metricas clave
Para medir el éxito de DevOps DORA desarrollo 4 métricas claves:
1. Frecuencia de Despliegue (Deployment Frequency)
¿Con qué frecuencia se realizan despliegues de producción? Esta métrica mide la agilidad y la velocidad con la que un equipo puede mover el código desde el commit hasta la producción.
2. Lead Time para Cambios (Lead Time for Changes)
El lead time para cambios es el tiempo que tarda una commit en pasar al entorno de producción. Este indicador ofrece una visión de la eficacia con la que un equipo responde a las necesidades de desarrollo y mantiene un flujo constante de mejoras hacia la producción.
3. Tiempo de Restauración del Servicio (Time to Restore Service)
Cuando ocurren incidentes o fallas, ¿cuánto tiempo tarda su equipo en restaurar el servicio? Esta métrica refleja la capacidad de un equipo para responder a problemas y recuperarse rápidamente, minimizando el impacto en los usuarios finales.
4. Tasa de Cambio Fallido (Change Failure Rate)
¿Qué porcentaje de los cambios de producción resultan en fallas en el servicio o degradan la calidad? Una baja tasa de cambio fallido indica que un equipo no solo entrega rápidamente sino que también mantiene o mejora la estabilidad y la calidad del sistema.
Leave a Reply