Cloud, DevOps & IaC
La infraestructura queda descrita en código y el despliegue, automatizado, para que subir a producción sea rutina y cualquiera del equipo pueda hacerlo.
La señal es fácil de reconocer: nadie se atreve a desplegar un viernes, el entorno de staging no se parece al de producción, y hay pasos que solo sabe hacer una persona.
El objetivo no es tener la infraestructura más moderna, sino que cualquiera del equipo pueda desplegar, revertir y entender qué está corriendo.
Frentes de trabajo
Infraestructura en el repositorio
Todo lo que existe en la nube está descrito en código y se revisa como cualquier otro cambio. Eso quita el miedo a tocar: se ve el diff antes de aplicarlo y se puede recrear el entorno desde cero.
El pipeline como red de seguridad
Las comprobaciones que hoy hace alguien a mano acaban en el pipeline: pruebas, linters, migraciones, escaneo de dependencias. Si pasa, se despliega solo; si no, no llega a producción.
Poder volver atrás
Un despliegue sin vuelta atrás es una apuesta. De ahí las versiones inmutables, las migraciones compatibles con la versión anterior y un camino de rollback que se ha probado, no uno que se supone que funciona.
Cómo encaja
De un commit a producción
Cada etapa tiene una condición para dejar pasar la siguiente. Si no se cumple, el cambio se queda donde está.
- 01
Commit
Lint y tests unitarios en menos de cinco minutos, o nadie los espera.
- 02
Imagen
Build reproducible, escaneo de vulnerabilidades y etiqueta con el sha del commit.
- 03
Staging
Migraciones primero, luego smoke tests contra datos parecidos a los reales.
- 04
Aprobación
Un humano mira qué cambia y qué se puede deshacer. Solo donde hace falta.
- 05
Producción
Despliegue progresivo: primero un 10% del tráfico, con las métricas al lado.
Si el canario empeora la latencia o los errores, se vuelve a la versión anterior con un comando. Ensayado, no improvisado.
Qué hay dentro de la cuenta
Todo esto está descrito en código. Lo que se toca a mano en la consola se pierde en el siguiente apply.
Cuenta o proyecto cloud
Red
VPC · Subredes privadas · Salida controlada
Clúster
Namespace por entorno · Límites de CPU y memoria · Autoescalado
Datos
PostgreSQL gestionado · Réplica de lectura · Backups con restauración probada
Estado de Terraform
Workspace por entorno · Bloqueo remoto · Plan en cada pull request
Qué incluye
- Infraestructura como código con Terraform o Pulumi, revisable en un pull request.
- Pipelines CI/CD (GitHub Actions, Jenkins, Bitbucket) que construyen, prueban y despliegan sin pasos manuales.
- Contenedores y orquestación en Kubernetes, con límites de recursos, health checks y autoescalado.
- Entornos separados creados con la misma definición, para que staging se parezca a producción de verdad.
- Despliegues sin downtime, con vuelta atrás rápida y migraciones de base de datos compatibles hacia atrás.
- Gestión de secretos y de variables por entorno, fuera del repositorio.
- Métricas, logs y alertas que apuntan a algo accionable en lugar de avisar de todo.
- Control de coste: qué se está pagando y qué se puede apagar.
Cómo avanza el proyecto
- 01Se empieza reproduciendo el entorno actual en código, sin cambiar el comportamiento de nada.
- 02Se automatiza el despliegue de un servicio y ese queda como plantilla para todos los demás.
- 03Las comprobaciones que hoy alguien hace a mano se mudan al pipeline.
- 04La operación termina en manos de tu equipo: una infraestructura que solo entiende quien la montó es un problema, no un servicio.
Qué te llevas
- El repositorio de infraestructura y los pipelines funcionando.
- Entornos reproducibles desde cero.
- Paneles de métricas y alertas con dueño.
- Documento de operación y de recuperación.
Stack habitual
- IaC
- TerraformPulumiHelm
- Contenedores
- DockerKubernetesCompose
- CI/CD
- GitHub ActionsJenkinsBitbucket Pipelines
- Nube
- AWSGoogle CloudCoolifyCloudflare
- Observabilidad
- PrometheusGrafanaSentryUptime Kuma
Dónde se ha hecho esto
Preguntas frecuentes
¿Se puede hacer sin equipo de infraestructura?
Sí, y es parte del objetivo: que desplegar y revertir no dependa de un especialista. La infraestructura queda descrita en código y revisable en un pull request, y la operación se entrega documentada al equipo de producto.
¿Qué pasa con lo que ya está montado a mano?
Se reproduce en código tal como está, sin cambiar comportamiento, y solo después se toca. Empezar por rediseñarlo todo es la forma más rápida de romper algo que funcionaba y no saber por qué.
¿AWS o Google Cloud?
La que ya se esté pagando, salvo que haya una razón concreta para mudarse. Las dos cubren lo mismo para la mayoría de los productos, y una migración de nube consume el presupuesto que le hacía falta al producto.
¿Kubernetes siempre?
No. Kubernetes paga la pena cuando hay varios servicios, varios entornos y necesidad de escalar por partes. Para un producto con dos servicios, una plataforma más simple cuesta menos de operar y se despliega igual de rápido.