Servicios06 / 07

Infraestructura que no cuesta lo que costaba

La factura de la nube casi nunca es un problema de precios: es un problema de arquitectura que llega en forma de factura. Instancias dimensionadas para un pico que ocurre dos veces al año, datos que cruzan zonas de disponibilidad sin necesidad, entornos de prueba encendidos los fines de semana.

Por eso el trabajo empieza atribuyendo el costo a algo que el negocio entienda: cuánto cuesta procesar mil transacciones. Con esa unidad, una discusión sobre infraestructura deja de ser una pelea entre finanzas e ingeniería y pasa a ser una decisión de producto.

Todo lo que se construye queda como código. Nada de consolas: si el entorno no se puede recrear desde el repositorio, no existe como capacidad, existe como suerte. Terraform para la infraestructura, GitOps para el estado de los despliegues, y entornos efímeros para que probar deje de significar competir por el único servidor de staging.

He operado los tres grandes en producción y en contextos distintos: Azure y AWS sosteniendo pagos en Yummy y en Wompi, GCP y Firebase detrás de una app con más de un millón de transacciones mensuales en Sky Airline, y Redshift con Terraform para las cargas de conciliación de Cencosud. Esa variedad importa menos por el catálogo de servicios de cada proveedor que por lo contrario: deja claro cuánto de una buena infraestructura es independiente de quién la aloja.

Formato
Migración
Costo
−60%
Disponibilidad
99,99%
Nube
Azure · AWS · GCP
Escribirme
Alcance

¿Qué involucra?

  1. 01Arquitecturas multi-cloud
  2. 02Infraestructura como código
  3. 03Optimización de costos cloud
  4. 04Estrategias de migración
  5. 05Automatización de despliegues
Método

¿Cómo se aborda?

  1. Paso 01

    Costo por unidad de negocio

    Etiquetado consistente y atribución de cada recurso a un servicio y a un equipo, para llegar al costo por mil transacciones. A partir de ahí las decisiones se pueden justificar solas.

  2. Paso 02

    Infraestructura como código, sin excepciones

    Terraform con módulos revisados y estado remoto bloqueado. Los cambios pasan por pull request con plan visible, igual que el código de aplicación, porque un cambio de infraestructura puede tumbar el sistema tan rápido como uno de negocio.

  3. Paso 03

    Despliegues progresivos y reversibles

    Canary o blue-green con métricas de decisión definidas de antemano, y feature flags para separar el despliegue de la activación. El objetivo es que volver atrás sea aburrido: si el rollback da miedo, el sistema no está listo.

  4. Paso 04

    Migración por etapas con valor propio

    Nada de un corte único de fin de semana. Cada etapa mueve una parte, se mide en producción y puede revertirse. La estrategia —rehost, replatform o refactor— se elige por componente, no para todo el sistema a la vez.

Unidad

Cuánto cuesta procesar mil transacciones

Mientras el costo de la nube se discuta en dólares al mes, la conversación entre finanzas e ingeniería no tiene salida: uno pide reducir y el otro responde que no se puede sin arriesgar disponibilidad. Ninguno de los dos tiene los datos para cerrar la discusión.

Cambia entera cuando el costo se expresa por unidad de negocio. Cuánto cuesta procesar mil transacciones, o atender mil peticiones. Con esa cifra, subir la infraestructura deja de ser un gasto y pasa a ser una decisión de producto con margen conocido, y bajarla deja de ser un recorte a ciegas.

Llegar ahí es trabajo de etiquetado y atribución antes que de arquitectura: cada recurso asignado a un servicio y a un equipo. Después, lo habitual en sistemas nunca revisados es encontrar entre un 30% y un 50% de margen sin tocar el diseño — dimensionamiento, ciclo de vida de datos y entornos encendidos que nadie usa.

  • Etiquetado y atribución de cada recurso a un servicio
  • Costo por mil transacciones como métrica de producto
  • Todo como código: si no se recrea desde el repositorio, no existe
  • Despliegues progresivos con rollback aburrido de tan probado
  • Migración por etapas reversibles, nunca una ventana única
Evidencia

¿Dónde lo he hecho?

Yummy Inc. · Azure y AWS
Microservicios de pagos en producción con requisitos de disponibilidad continua
2M tx/día
Wompi (Grupo Bancolombia)
Pasarela de pagos e integraciones bancarias sobre Azure y AWS
99,9%
Cencosud S.A. · Datos y provisión
Amazon Redshift y Terraform sobre cargas de conciliación de retail
Terraform
Sky Airline · GCP y Firebase
Servicios y backend mobile sobre infraestructura gestionada
GCP

Las cifras vienen de sistemas en producción. La trayectoria completa está en Sobre mí.

Ejecución

Prácticas y entregables

Prácticas

  • Infraestructura como código
  • GitOps
  • FinOps
  • Despliegue canary y blue-green
  • Feature flags
  • Entornos efímeros
  • Autoescalado con presupuesto

Entregables

  • Módulos de Terraform revisados
  • Pipeline de despliegue con rollback probado
  • Modelo de costo por unidad de negocio
  • Runbooks de operación y recuperación
  • Plan de migración por etapas reversibles

Stack

  • Azure
  • AWS
  • GCP
  • Terraform
  • Docker
  • Kubernetes
Preguntas

Lo que suelen preguntarme

¿Azure, AWS o GCP?
El que ya use el equipo, salvo que haya una razón concreta para cambiar. He trabajado los tres —Azure y AWS en Yummy y en Wompi, GCP en Sky Airline— y la diferencia real rara vez está en el proveedor: está en cómo se provisiona, se despliega y se atribuye el costo. Multi-cloud de verdad cuesta mucho más de lo que la mayoría estima; portabilidad razonable sí vale la pena, y se consigue con contenedores y Terraform.
¿Serverless siempre sale más barato?
No. Sale barato con carga irregular y caro con carga alta y constante. La comparación honesta se hace con el perfil de tráfico real, no con el de la presentación del proveedor.
¿Se puede migrar sin parar el servicio?
Sí, con etapas reversibles y tráfico dividido. Las migraciones que fallan casi siempre son las que intentaron moverlo todo en una ventana de mantenimiento.
¿Cuánto se puede reducir la factura?
Depende del punto de partida. En sistemas que nunca han sido revisados es habitual encontrar entre un 30% y un 50% sin tocar la arquitectura, solo con dimensionamiento, ciclo de vida de datos y apagado de lo que nadie usa.
Catálogo
Ver todos

Otros frentes