Fundamentos de la computación en la nube
DevOps e infraestructura como código
Cómo desarrollo y operaciones se fusionaron en una sola práctica continua, qué detecta cada etapa de un pipeline de CI/CD, y cómo describir la infraestructura como código, en vez de dar clics en una consola, mantiene los entornos consistentes y reproducibles.
- Explicar qué cambia DevOps en cómo trabajan juntos los equipos de desarrollo y operaciones
- Describir las etapas de un pipeline de CI/CD y qué detecta cada una antes de que un cambio llegue a producción
- Explicar cómo la infraestructura como código reemplaza los cambios manuales en consola por configuración versionada y declarativa
- Identificar el drift de configuración y por qué ocurre cuando la infraestructura se cambia fuera de su definición en código
- Comparar el flujo de plan y apply de una herramienta declarativa de infraestructura como código contra hacer el mismo cambio a mano
La lección pasada te dejó con más piezas en movimiento de las que un solo despliegue puede manejar
La lección pasada te dejó con un equipo corriendo una cantidad creciente de servicios independientemente desplegables, cada uno lanzando en su propio calendario. Enviar una sola aplicación a mano, probada manualmente y copiada a un servidor por quien estuviera de guardia, ya era lento y propenso a errores. Enviar 10 servicios de esa forma no solo es más lento, deja de ser algo que una persona pueda hacer de forma confiable. DevOps, y las prácticas construidas alrededor, existen para responder justo ese problema.
Qué cambia DevOps en verdad
Antes de DevOps, desarrollo y operaciones solían ser 2 equipos separados: desarrollo escribía código y lo entregaba, operaciones lo desplegaba y lo corría, y cada lado culpaba al otro cuando un lanzamiento rompía algo. DevOps, en las propias palabras de AWS, es una combinación de filosofías culturales, prácticas y herramientas que aumenta la capacidad de una organización para entregar aplicaciones y servicios a alta velocidad. En la práctica, eso significa que el mismo equipo escribe, prueba, despliega y opera sus propios servicios, lo cual le da a ese equipo un incentivo directo para hacer que el despliegue mismo sea rápido y seguro, en vez de lanzar un build por encima de una pared y esperar lo mejor.
Integración continua, entrega continua: qué pasa en realidad en cada etapa
| Etapa | Qué pasa | Qué detecta |
|---|---|---|
| Origen | Un desarrollador sube código a un repositorio compartido | Nada todavía, esto solo arranca el pipeline |
| Build | El código compila y se empaqueta en un artefacto desplegable | Errores de sintaxis, dependencias faltantes |
| Pruebas | Una suite de pruebas automatizadas corre contra el build | Regresiones en comportamiento existente |
| Staging | El build se despliega en un entorno previo a producción | Problemas de integración y configuración |
| Producción | El build se despliega para usuarios reales | Nada más, esto es el lanzamiento |
Sigue un commit a través de todo esto. Un desarrollador sube una corrección al servicio de checkout de la lección pasada. La integración continua construye una nueva imagen de contenedor y corre la suite de pruebas contra ella; si una prueba falla, el pipeline se detiene justo ahí, y el cambio nunca llega a staging, mucho menos a producción. Si todas las pruebas pasan, la entrega continua toma el relevo, desplegando ese mismo build a staging automáticamente, y, una vez que las verificaciones ahí pasan, promoviendo ese build exacto a producción. Ninguna etapa se salta, y ningún humano copia un archivo a mano.
name: ci
on: [push]
jobs:
build-and-test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: docker build -t checkout-service:${{ github.sha }} .
- run: docker run checkout-service:${{ github.sha }} npm test
Infraestructura como código: la misma idea, apuntada a la infraestructura
CI/CD automatiza el envío del código de la aplicación. La infraestructura como código aplica la misma disciplina a los servidores, redes y servicios sobre los que corre ese código: aprovisionar y administrar infraestructura usando código en vez de procesos manuales y clics en consola. Un bucket de almacenamiento creado dando clics en una consola no deja registro de quién lo creó, por qué, ni cómo recrearlo. El mismo bucket declarado en un archivo sí lo deja.
resource "aws_s3_bucket" "uploads" {
bucket = "my-app-uploads"
}
Herramientas como Terraform funcionan en 3 pasos: escribir la configuración, plan (previsualizar exactamente qué se creará, cambiará o destruirá para igualarla), y apply (ejecutar esos cambios en el orden de dependencia correcto). Esa configuración es declarativa: describe el estado final que quieres, no los comandos individuales para llegar ahí, y la herramienta resuelve el resto.
El error de concepto: "una corrección manual rápida en la consola no tiene problema"
Es tentador pensar que una corrección rápida en la consola, subir la memoria de una instancia sobrecargada a las 2 a.m. durante un incidente, es inofensiva mientras resuelva el problema inmediato. No lo es: el archivo de infraestructura como código todavía describe la instancia vieja y más pequeña, así que el código y la infraestructura real se separaron en silencio. La próxima vez que alguien aplique ese código, puede revertir la corrección de emergencia sin que nadie lo quiera, o el equipo simplemente deja de confiar en que el código refleja lo que en verdad está corriendo. El drift de configuración es el nombre de esa brecha, y la solución es disciplina, no astucia: actualizar el código para que coincida con el cambio de emergencia de inmediato, o revertir el cambio manual y hacer esa misma corrección a través del código.
Pistas de examen: identificar el encaje en un escenario
| El escenario dice... | Apunta hacia |
|---|---|
| "Build, pruebas y despliegue automatizados en cada commit" | Pipeline de CI/CD |
| "Infraestructura definida en archivos versionados" | Infraestructura como código |
| "Un cambio manual hecho fuera del pipeline de despliegue" | Riesgo de drift de configuración |
| "Previsualizar cambios antes de aplicarlos" | Paso de plan de una herramienta declarativa de infraestructura como código |
Dónde te deja esto
DevOps, CI/CD e infraestructura como código son lo que hace sostenible a escala real todo lo que cubrieron las últimas 2 lecciones: una función sin servidor o una imagen de contenedor solo es tan confiable como el pipeline que la construye, la prueba y la envía, y la infraestructura sobre la que corre solo es tan consistente como el código que la describe. El siguiente dominio de este curso pasa a lo que mantiene los sistemas seguros y disponibles una vez que están corriendo, el modelo de responsabilidad compartida, identidad, cifrado y recuperación ante desastres, prácticas que la infraestructura como código hace mucho más fácil de aplicar de la misma forma en todos los entornos que tiene un equipo.