DevOps y Cloud Engineering en 2026: AWS, Terraform y el fin de los snowflakes

La mayoría de la infraestructura de startups en 2026 sigue viéndose así: una cuenta de AWS de producción que alguien bootstrappeó en 2022 por la consola, un staging que driftea de prod en 14 formas distintas, un repo de Terraform al que no se le ha hecho apply en 9 meses porque “el state file está jodido”, y un pipeline de CI que despliega vía un script bash que solo el CTO original entiende.

Después un ingeniero senior se va y todo se vuelve un misterio.

El punto del DevOps moderno no es Kubernetes. No es el póster del landscape de la CNCF. El punto es: cualquiera en el equipo puede hacer cambios a producción con confianza, y el sistema no te sorprende a las 3 AM. Eso es todo. La mayoría de proyectos de “modernización DevOps” fallan porque optimizan por las cosas equivocadas — verse sofisticados en vez de ser aburridos.

Esto es lo que sí hacemos.

El modelo de madurez cloud-native (y dónde están los equipos en realidad)

Hablamos con docenas de equipos de ingeniería al año. La distribución honesta se ve así:

• Nivel 0 — ClickOps. Infra provisionada por consolas web. Sin reproducibilidad. ~40% de las startups seed/Series A.
• Nivel 1 — Algo de IaC. Existe Terraform pero parcial. La mitad de los recursos siguen siendo manuales. El state file vive en la laptop de alguien. ~25%.
• Nivel 2 — IaC completo, deploys manuales. Toda la infra en Terraform/Pulumi, el CI corre tests, pero los deploys siguen siendo “merge and pray” o requieren intervención del SRE. ~20%.
• Nivel 3 — GitOps y deploys automatizados. Cada cambio pasa por review de PR, se aplica vía CI, el rollback es un botón. ~12%.
• Nivel 4 — Plataforma self-service. Los ingenieros pueden levantar nuevos servicios, bases de datos, secretos sin abrir tickets, dentro de guardrails. ~3%.

No necesitas ser Nivel 4. La mayoría de empresas de producto con menos de 50 ingenieros debería apuntar a Nivel 3 y parar ahí. El Nivel 4 es para equipos de plataforma de 10+ personas.

Greenfield vs migración legacy

Dos engagements que desde afuera se ven iguales pero son trabajos completamente distintos.

Greenfield es fácil. Decide AWS o GCP, escribe Terraform desde el día uno, configura GitHub Actions o GitLab CI con environments, configura state remoto en S3 + locking de DynamoDB, listo en una semana. La parte más difícil es la restraint: no sobre-ingeniar antes de tener product-market fit.

Migración legacy es donde está la plata y el dolor real. La empresa tiene 6 años de drift de ClickOps. La mitad de los recursos no tienen tags. Tres de los servicios son críticos y no están documentados. La migración a Terraform requiere:

1. Inventario e import. Usamos terraformer o escribimos imports a mano para meter los recursos existentes al state. Es tedioso. No hay atajos.
2. Drift detection. Corre terraform plan contra el state importado. Lo que muestre diff es o un bug del import o un cambio manual que alguien hizo el martes pasado. Ambos requieren investigación.
3. Refactor en pasadas. Primera pasada: solo dejar el state correcto. Segunda: extraer módulos. Tercera: estandarizar naming. No intentes hacer las tres a la vez — vas a perder la cordura.
4. Cerrar la consola. Una vez que Terraform es dueño de un recurso, revoca el acceso de escritura por consola para ese servicio. Si no, el drift regresa inmediatamente.

Timeline típico para una empresa Series B con 200-400 recursos AWS: 6-10 semanas. Hemos hecho más corto; hemos hecho mucho más largo. La variable es cuánta lógica de negocio sin documentar vive en la infra existente.

Terraform vs Pulumi vs CDK en 2026

Lectura honesta: Terraform sigue siendo el default. El drama de la licencia BSL de HashiCorp en 2023 generó OpenTofu, que ahora es production-ready y básicamente drop-in. La mayoría de nuestros engagements nuevos corren OpenTofu. La sintaxis HCL está bien. El ecosistema es enorme.

Pulumi es excelente si tus ingenieros ya escriben TypeScript o Python y quieres constructs reales de lenguaje de programación (loops, condicionales, testing de verdad). El downside: comunidad más pequeña, menos respuestas en Stack Overflow, contratar es más difícil.

AWS CDK es bueno para shops AWS-only que no anticipan multi-cloud. Compila a CloudFormation, así que obtienes la semántica de rollback nativa de AWS. El downside: locked a AWS, el modelo de state de CloudFormation tiene sus mañas.

Crossplane es interesante si ya estás profundo en Kubernetes y quieres manejar recursos cloud desde adentro del cluster. Nicho.

Nuestra recomendación default para un cliente nuevo: OpenTofu + Atlantis (para workflows de plan/apply basados en PR) + state remoto en S3 con locking de DynamoDB. Aburrido, probado, mercado de hiring amplio.

Cuándo Kubernetes sí vale la pena

Kubernetes es la tecnología más sobre-recetada de nuestra industria. También es genuinamente la respuesta correcta en casos específicos.

Kubernetes vale la pena cuando:

• Estás corriendo 20+ microservicios y el costo de orquestación de manejarlos en ECS o EC2 plano está superando lo que costaría K8s.
• Tienes requisitos multi-región o multi-cloud que se benefician de una abstracción unificada.
• Estás haciendo workloads serios de batch / ML que se benefician de scheduling sofisticado.
• Tu equipo genuinamente tiene expertise en Kubernetes — no “leímos un tutorial”, sino que opera clusters en producción con confianza.

Kubernetes es la respuesta equivocada cuando:

• Tienes 4 servicios y un app CRUD. AWS Lambda o ECS Fargate te llevan ahí con 1/10 del overhead operacional.
• No tienes un platform engineer dedicado. K8s sin un platform engineer es un part-time job para todos, todo el tiempo.
• Estás “future-proofing”. Future-proofing de infra es la forma más cara de optimización prematura.

Si eres una startup de 15 ingenieros y tu CTO está emocionado con K8s, nuestro consejo honesto es: corre Fargate o Lambda otro año. Si eres una scale-up de 100 ingenieros con 30 servicios, K8s probablemente tiene sentido. Ayudamos a equipos a elegir honestamente y no tenemos incentivo de oversell — cobramos igual de cualquier forma.

Para equipos que sí necesitan K8s, estandarizamos en EKS (control plane manejado), Karpenter (autoscaling de nodos, reemplazó al Cluster Autoscaler en la mayoría de nuestros deploys), ArgoCD (deploy GitOps), y External Secrets Operator (jalar secretos de AWS Secrets Manager / Vault hacia K8s). Ese stack cubre el 95% de las necesidades reales.

Serverless y el aburrido punto medio

Lambda + API Gateway + DynamoDB + S3 + EventBridge es un stack subestimado en 2026. No es glamoroso. Escala a cero y a mucho. Tiene aristas (cold starts, vendor lock-in, debugging es más difícil). Pero para la mayoría de herramientas internas y muchos workloads de producto, es la forma más barata de enviar algo que no te despierta.

Mezclamos patrones agresivamente. Arquitectura típica de cliente: ECS Fargate para servicios stateful long-running, Lambda para event handlers y jobs programados, RDS para la base de datos principal, DynamoDB para lookups de alta cardinalidad, CloudFront + S3 para assets estáticos. Sin Kubernetes en ningún lado. Duerme bien.

Patrones de optimización de costo que sí funcionan

La optimización de costo cloud se volvió una industria propia. La mayoría es teatro. Esto es lo que sí mueve la factura:

1. Rightsizing. La palanca más grande para la mayoría de clientes. Probablemente tienes instancias m5.2xlarge haciendo el trabajo de t3.medium. Usamos AWS Compute Optimizer + métricas de CloudWatch sobre 14 días para encontrarlas. Reducción fácil de 20-40% en gasto de EC2.

2. Savings Plans / Reserved Instances. Una vez que entiendas tu baseline, comprométete. Los Compute Savings Plans (1 año, sin upfront) típicamente ahorran 15-25% con flexibilidad completa. No vayas a 3 años a menos que estés seguro del workload.

3. Spot para workloads tolerantes a fallos. Jobs de batch, runners de CI, ambientes de dev, node groups de K8s para servicios stateless. 60-90% de descuento vs on-demand. Karpenter maneja interrupciones de spot limpiamente.

4. Lifecycle policies de S3. La mayoría de clientes tiene terabytes de logs de CloudWatch y backups viejos en S3 Standard. Mover a Glacier Deep Archive después de 90 días es un cambio de config que se paga solo en una semana.

5. Costos de NAT Gateway. El asesino silencioso. Si corres NAT Gateways multi-AZ y tus servicios charlan entre AZs hacia RDS o S3, estás pagando $0.045/GB por el privilegio. Los VPC endpoints para S3 / DynamoDB / ECR son gratis y ahorran miles al mes.

6. Recursos huérfanos sin tag. Snapshots viejos, volúmenes EBS no atachados, load balancers idle, Elastic IPs sin uso. Corremos aws-nuke (¡en dry-run!) contra cuentas de dev/staging y encontramos $500-3,000/mes de peso muerto en la mayoría de clientes.

Hemos entregado consistentemente reducciones de 30-50% en factura de AWS en engagements de primera vez. La matemática: una factura de $40K/mes bajada a $24K ahorra $192K anuales. Nuestro engagement para hacerlo: $8-15K una vez. Después un retainer para mantenerlo apretado.

SRE retainer: lo que sí cubre

Muchas empresas pequeñas no necesitan un SRE full-time. Necesitan a alguien confiable en retainer. Nuestro retainer estándar de SRE a $2,500/mes cubre:

• Rotación de on-call 24/7 para incidentes production-down. Cargamos el pager cuando estás fuera.
• Higiene de monitoreo y alerting. Afinamos tus alertas para que la persona de on-call realmente les crea. La alert fatigue mata el response time.
• Patching de dependencias. Review mensual y rollout de actualizaciones de seguridad de OS / runtime / framework. Hecho contigo, no a ti.
• Drills de backup y restore. Trimestralmente sí restauramos un backup. “Existe” no es lo mismo que “funciona”.
• Reviews de capacidad. Check mensual de headroom, trayectoria de crecimiento, cuándo upsize.
• Review de costos. Walkthrough trimestral de la factura con recomendaciones concretas de optimización.

Para engagements de mayor toque (K8s pesado, multi-región, workloads regulados), los retainers escalan desde ahí. Dimensionamos a tu carga ops real, no a un SLA genérico.

Lo que no hacemos

No hacemos workshops de “transformación DevOps”. No vendemos certificaciones. No escribimos un documento de estrategia de 60 páginas que termina con “recomendamos contratar 6 personas más”. Escribimos Terraform, enviamos pipelines, arreglamos el alerting, tomamos el shift de on-call este sábado para que tu equipo descanse.

Precio

• Engagement inicial: desde $8K, depende del scope. Setup greenfield típico es 2-3 semanas. Migración legacy típica es 6-10 semanas.
• SRE retainer: desde $2,500/mes. Incluye on-call, patching, monitoreo, review mensual de costos.
• Sprint de optimización de costo: flat $8-12K, 2 semanas, apuntando a una reducción específica de % con savings compartidos sobre resultados si quieres estructurarlo así.

Conclusión

La infraestructura aburrida es una ventaja competitiva. Las empresas que envían más rápido en 2026 son aquellas cuyos ingenieros pueden hacer deploy un viernes en la tarde y no pensarlo otra vez hasta el lunes. Eso no es Kubernetes. No son microservicios. Es disciplina aplicada a los fundamentos aburridos: IaC, CI/CD, monitoreo, on-call.

Si tu infra es el cuello de botella para shipping, podemos arrancar un engagement de DevOps la próxima semana. La discovery call es gratis.