Pasarnos de AWS a bare metal nos ahorró 230.000 dólares al año
La afirmación de que trasladar un servicio de monitorización de uptime de AWS a servidores bare metal ahorró unos 230.000 dólares al año desató un debate más amplio sobre la economía de la infraestructura en la nube frente a la autogestionada. Los comentaristas discuten si esos ahorros se mantienen una vez que se contabilizan el esfuerzo de migración, el trabajo operativo continuo y la redundancia, señalando que la configuración previa en AWS de la empresa parecía sobredimensionada y poco optimizada. Muchos concluyen que las cargas de trabajo predecibles y estables pueden ser mucho más baratas en colo o hardware dedicado, mientras que las plataformas cloud siguen ganando para iterar rápido, usar servicios gestionados y atender demandas irregulares o inciertas.
Debate sobre costes y ahorro
- Muchos coinciden en que bare metal / colo es intrínsecamente más barato que AWS para cargas estables; algunos citan que la nube suele costar ~2–2,5× más que on-prem.
- Varios sostienen que el ahorro informado de 230.000 dólares/año está exagerado porque:
- Estaban en EC2 bajo demanda, sin Reserved Instances ni Savings Plans (podrían ahorrar ~35%+).
- Las instancias Spot y Graviton (m7g) podrían haber reducido mucho más el coste de cómputo para cargas adecuadas.
- Contraargumento: incluso tras optimizaciones razonables en AWS, los comentaristas siguen esperando ahorros significativos con bare metal, especialmente en ancho de banda y almacenamiento.
- Algunos señalan que el ahorro equivale aproximadamente a 1 ingeniero intermedio en EE. UU. al año; fuera de EE. UU. podría financiar a varios ingenieros.
Costes ocultos y operativos
- Los escépticos subrayan:
- El esfuerzo y el riesgo de la migración no están incluidos en el precio.
- Trabajo continuo de hardware: fallos, planificación de capacidad, plazos de aprovisionamiento, remote hands.
- Complejidad del almacenamiento HA (Ceph/Longhorn), redes (Cilium/eBPF), plano de control de Kubernetes y configuraciones serias de bases de datos con backups probados y PITR.
- Otros responden que:
- Los entornos en AWS también requieren especialistas (DevOps/SRE, finops, seguridad, trabajo YAML/IaC, gestión de proveedores).
- Para flotas pequeñas (1–2 racks), la sobrecarga operativa puede ser modesta, especialmente con colocation y automatización (PXE, Harvester, Proxmox, etc.).
Fiabilidad, HA y arquitectura
- Crítica fuerte de que una configuración de un solo rack / un solo DC es menos fiable que el AWS multi‑AZ; “monitorización de uptime en un rack” se ve como irónico.
- Quienes lo apoyan señalan que mantienen un clúster de failover en AWS que pueden levantar rápidamente, pero otros apuntan a que DNS, sincronización de datos y simulacros de failover no son triviales.
- Debate sobre si multi‑región/multi‑cloud en AWS es “Cloud 101” y si on‑prem puede igualar de forma realista esa resiliencia.
Cloud vs bare metal: cuándo encaja cada uno
- Argumentos a favor de la nube:
- Experimentación rápida con servicios gestionados (Fargate, S3, Aurora, etc.).
- Evita lidiar con hardware físico, instalaciones, generadores, HVAC.
- Permite escalar rápido y crecer muchísimo sin gran capex inicial.
- Argumentos a favor de bare metal/colo:
- Ahorros enormes en ancho de banda y cómputo predecible.
- Buen encaje para batch/ML, cargas de larga duración y productos maduros y estables.
- Potencialmente mejor rendimiento (NVMe directo, sin vecinos ruidosos) y menos bloqueo de proveedor si se evitan servicios específicos de la nube.
Meta y escepticismo sobre este caso
- Algunos creen que su huella original en AWS (K8s de 28 nodos para una app de uptime) estaba claramente sobredimensionada.
- Otros dicen que el blog aporta pocos detalles clave (volumen de datos, diseño HA, RTO/RPO, condiciones de colo), lo que dificulta juzgar la decisión por completo.
- Varios señalan que la nube seguía siendo útil para validar rápidamente el negocio; pasar a otra plataforma después se ve como una optimización razonable de “fase dos”.