DevOps
Bibliografía
1. Introducción
Ciclo de vida de un proyecto DevOps
DevOps es una filosofía que combina las prácticas de desarrollo de software (Development) y operaciones de IT (Operations) con el objetivo de mejorar la colaboración, la automatización y la entrega continua de software.
La filosofía detrás de DevOps busca reducir los ciclos de desarrollo y ofrecer aplicaciones de alta calidad de manera más rápida y eficiente. Para lograrlo, DevOps se apoya en principios ágiles, y pone un fuerte énfasis en la medición y monitoreo de los procesos.
El principio fundamental de DevOps es promover una cultura de colaboración y responsabilidad compartida entre los equipos de desarrollo y operaciones. Para ello, se fomentan prácticas como el uso y fomento de herramientas open source. Estos procesos permiten que cualquier miembro del equipo, ya sea interno o externo a la organización, pueda contribuir al desarrollo del software.
DevOps también implica un cambio cultural dentro de las empresas, ya que obliga a rediseñar la forma en que se desarrollan y despliegan las aplicaciones. Esto se traduce en un enfoque más orientado a la creación de productos en lugar de proyectos, estableciendo equipos estables con ownership de cada producto y asegurando su mantenimiento a lo largo del tiempo.
Una de las tareas clave de un profesional de DevOps es la automatización de los despliegues en los diferentes entornos, así como la creación de infraestructura efímera.
Este concepto de infraestructura efímera se refiere a la creación y destrucción dinámica de recursos para cada despliegue, garantizando que se eliminen los recursos innecesarios y se creen nuevos para cada nueva versión del software.
El rol de SRE (Site Reliability Engineer) se complementa con DevOps, pero se enfoca más en automatizar procesos manuales y en garantizar la estabilidad y fiabilidad de los sistemas. Mientras que los ingenieros de DevOps trabajan principalmente en la integración continua y la automatización del flujo de trabajo, los SRE se enfocan en mejorar la confiabilidad y el rendimiento a través de la observabilidad del estado de los sistemas, los SLAs (Service Level Agreements) y los errores presupuestarios.
Los SLAs (Acuerdos de Nivel de Servicio) son compromisos formales entre un proveedor de servicios (en este caso, el equipo de operaciones) y sus clientes (los usuarios o las partes interesadas). En el contexto de SRE, los SLAs se utilizan para establecer expectativas claras sobre el rendimiento y la disponibilidad del sistema.
El error budget es un concepto clave dentro de la ingeniería de confiabilidad del sitio (SRE). Se refiere a la cantidad de "fallos" o "tiempo de inactividad" que se permite dentro de un determinado período mientras aún se cumple con los SLAs.
1.1. Agilidad
Para que una organización sea verdaderamente ágil, debe basarse en tres pilares fundamentales:
-
DevOps: Promueve un cambio cultural hacia la colaboración y la automatización de procesos. Incluye la creación de pipelines automatizados, la infraestructura como código y la infraestructura inmutable.
-
Microservicios: Implica el diseño de aplicaciones como un conjunto de servicios independientes y débilmente acoplados, que se comunican entre sí a través de APIs REST y están diseñados para ser resistentes a fallos.
notaLas APIs REST (Representational State Transfer) son un conjunto de principios de la arquitectura para la comunicación entre sistemas a través de la web. Utilizan los estándares de HTTP y se basan en la transferencia de recursos, que se identifican mediante URLs. Las principales características de las APIs REST son:
- Cliente-Servidor: La arquitectura se divide en dos roles: el cliente solicita recursos y el servidor los provee.
- Sin Estado: Cada solicitud es independiente y no depende de solicitudes anteriores.
- Interfaz Uniforme: Las API siguen un conjunto de convenciones claras, facilitando la interacción.
- Métodos HTTP: Se utilizan los métodos estándar de HTTP: GET (leer), POST (crear), PUT (actualizar), DELETE (eliminar).
- Representaciones de Recursos: Los recursos se representan generalmente en formato JSON o XML, lo que permite al cliente procesarlos.
- Escalabilidad y Flexibilidad: Las APIs REST son fáciles de escalar y evolucionar sin que interfieran entre sí.
-
Contenedores: Ofrecen portabilidad, escalabilidad y facilitan la creación de entornos de despliegue rápidos con infraestructura inmutable.
Estos tres elementos trabajan en conjunto para transformar las organizaciones de un enfoque tradicional basado en procesos en cascada a una metodología ágil y flexible que favorezca la entrega continua de software.
1.2. Metodologías de Trabajo
Sprints de la metodología de Agile
En DevOps, el flujo de trabajo comienza con la discusión sobre las nuevas características que se desean agregar al sistema. Una vez acordadas, se crea una issue o ticket (una etiqueta que permita identificar la nueva característica o fallo) y se asigna a un desarrollador. A continuación, el desarrollador hace un fork del repositorio, realiza los cambios necesarios y, finalmente, crea un pull request para que el propietario del repositorio realice una revisión del código (merge request).
Una buena práctica en DevOps es organizar el trabajo mediante ramas dedicadas a cada tarea o ticket. Esto facilita el trabajo en equipo y asegura que los cambios no interfieran con el trabajo de otros desarrolladores. Además, se recomienda dividir el trabajo en tareas pequeñas para permitir iteraciones rápidas, obtener retroalimentación continua y minimizar riesgos.
El desarrollo debe seguir un enfoque iterativo, donde las nuevas funcionalidades se implementan en sprints de entre una y dos semanas. Sin embargo, la duración de los sprints puede variar dependiendo de la naturaleza del proyecto.
1.3. Producto Mínimo Viable (MVP)
En el contexto de DevOps, el Producto Mínimo Viable (MVP) es la versión más simple del producto que se puede lanzar para validar una hipótesis de negocio y obtener retroalimentación del cliente. El objetivo del MVP es aprender rápidamente, no solo entregar funcionalidad. El proceso de desarrollo y despliegue se enfoca en obtener retroalimentación constante para pivotar, ajustar o mejorar el producto según sea necesario.
2. Métricas Clave en DevOps
Para medir el desempeño y la eficiencia de un equipo DevOps, es esencial contar con un conjunto de métricas que permitan identificar áreas de mejora y evaluar el progreso. Algunas de las métricas más utilizadas son:
- Mean Lead Time: El tiempo promedio desde que una idea es concebida hasta que un producto es desplegado en producción.
- Change Failure Rate: La tasa de fallos que ocurren debido a cambios o nuevas versiones del software.
- MTTR (Mean Time to Recovery): El tiempo promedio que tarda un sistema o servicio en recuperarse de una falla. Esta métrica es crucial para evaluar la capacidad de respuesta del equipo ante incidentes y para identificar patrones de fallos que puedan requerir mejoras en el sistema.
- MTTF (Mean Time to Failure): El tiempo promedio que un equipo o sistema sin capacidad de reparación permanece operativo antes de que ocurra una falla. Se utiliza para estimar la vida útil de componentes no reparables, como bombillas o equipos que no tienen un mantenimiento programado.
3. Pruebas y Desarrollo Basado en Pruebas
3.1. Test-Driven Development (TDD)
Proceso de TDD
El Desarrollo Guiado por Pruebas (TDD) es una práctica fundamental en DevOps que prioriza la escritura de pruebas antes de escribir el código que las hace pasar. Este enfoque ayuda a mantener el enfoque en los requisitos del sistema y asegura que el código esté correctamente validado desde el principio.
El flujo básico de TDD se basa en el ciclo "Red-Green-Refactor": primero, se escribe una prueba que falla (Red), luego se implementa el código que hace pasar la prueba (Green), y finalmente, se refactoriza el código para mejorar su calidad sin alterar su funcionalidad.
3.2. Behavior-Driven Development (BDD)
Proceso de BDD
El Desarrollo Guiado por Comportamiento (BDD) es una extensión de TDD que se enfoca en el comportamiento esperado del sistema desde la perspectiva del usuario final. En lugar de centrarse únicamente en las pruebas unitarias, BDD se ocupa de la integración de los sistemas y permite verificar que el software cumpla con los requisitos de alto nivel.
4. Microservicios
Diferencia de un sistema monolítico y un sistema basado en microservicios
Los microservicios son una arquitectura de software en la que una aplicación se divide en servicios pequeños, independientes y sin estado, cada uno de los cuales persiste su propio estado en una base de datos separada. Esta estructura facilita la resiliencia, ya que cada microservicio puede escalarse y gestionarse de manera independiente.
La arquitectura de microservicios también favorece la escalabilidad horizontal, que permite agregar más instancias de un servicio en lugar de aumentar el poder de procesamiento de un solo servidor. Los microservicios, junto con una infraestructura en la nube, permiten un enfoque verdaderamente cloud-native, lo que facilita la actualización, el despliegue y la gestión de las aplicaciones.
4.1. Patrones de Resiliencia
- Retry Pattern: Permite a las aplicaciones manejar errores transitorios al intentar reconectar con servicios externos, incrementando el tiempo de espera entre intentos hasta que se agoten los reintentos.
- Circuit Breaker Pattern: Evita que las aplicaciones sigan intentando conectarse a servicios externos que probablemente fallarán. Este patrón mejora la estabilidad y resiliencia de las aplicaciones, previniendo fallos en cascada en sistemas distribuidos.
- Bulkhead Pattern: Aísla los recursos para evitar que un fallo en un componente afecte a otros. Combina este patrón con el Circuit Breaker para manejar fallos de manera eficiente y desacoplar componentes.
- Monkey Testing: Implica matar procesos o servicios aleatoriamente para evaluar la resiliencia del sistema ante fallos imprevistos.
6. Infraestructura como Código (IaC)
Infraestructura como Código
La Infraestructura como Código (IaC) es un principio fundamental en DevOps que permite crear, gestionar y configurar la infraestructura de manera programática. Al tratar la infraestructura como código, se asegura la reproducibilidad, la trazabilidad y el control de versiones, lo que permite la creación de entornos consistentes y predecibles.
Las herramientas como Docker y Kubernetes son esenciales para IaC, ya que permiten la automatización del despliegue y la gestión de la infraestructura mediante contenedores y orquestación. Este enfoque asegura que la infraestructura esté actualizada y que no haya discrepancias entre los entornos de desarrollo, prueba y producción.
7. Integración y Despliegue Continuos (CI/CD)
La integración continua (CI) y el despliegue continuo (CD) son prácticas clave de DevOps que buscan mejorar la eficiencia y la calidad del software mediante la automatización de las pruebas y el despliegue.
- CI: Implica la integración constante de las características completas en la rama principal del repositorio, lo que permite la construcción, pruebas y fusión continua.
- CD: Se refiere al despliegue automático del código a un entorno de producción o un entorno similar a producción.
Las prácticas de CI/CD incluyen la creación de commits regulares para reducir los errores de fusión, realizar pruebas automáticas antes de fusionar ramas y emplear técnicas como feature flags para activar o desactivar partes del código según sea necesario.
Con una implementación sólida de CI/CD, se puede lograr un flujo de trabajo eficiente y confiable, lo que permite a los equipos entregar nuevas funcionalidades de manera más rápida y con menos riesgo.