FinOps: Gestión Financiera de la Nube

FinOps (Cloud Financial Operations) es la disciplina cultural y práctica que busca maximizar el valor de negocio del gasto en la nube. En HERA, FinOps es una responsabilidad compartida entre Finanzas, Tecnología y Negocio para tomar decisiones informadas sobre el gasto.

El Framework de FinOps: Informar, Optimizar, Operar

Nuestro enfoque sigue el ciclo de vida estándar de FinOps.

Framework FinOps en HERA

1

Informar

Visibilidad Total

• Tagging y Showback de costos
• Dashboards de Costos (Looker Studio)
• Allocation a Centros de Costo
• Reportes semanales a Tech Leads

2

Optimizar

Reducir Desperdicio

• Right-sizing de VMs y GKE
• Committed Use Discounts (CUDs)
• Limpieza de recursos ociosos
• Autoscaling optimizado

3

Operar

Controlar y Gobernar

• Budgets por Proyecto + Alertas
• Políticas de Gasto y aprobaciones
• Alertas de anomalías de gasto
• Revisiones trimestrales de presupuesto

Responsabilidad compartida: Finanzas · Tecnología · Negocio

Mensaje clave Informar → Optimizar → Operar. Cada equipo es responsable del costo de los recursos que consume.

---

1. Informar: Visibilidad Total del Gasto

El primer paso es entender dónde y por qué se gasta el dinero.

Asignación de Costos (Cost Allocation)

La correcta asignación de costos es la base de todo. Esto se logra a través de una política de etiquetado (tagging) estricta y obligatoria.

Tagging obligatorio

Todo recurso desplegable en HERA debe contener los tags definidos en la sección de Estándares de Tagging. Los recursos sin tags son considerados “sombra” y serán marcados para eliminación.

Dashboards y Reportes

• Dashboard FinOps en Looker Studio: Proporciona una vista en tiempo real del gasto por equipo, por proyecto y por servicio de GCP.
• Reportes Semanales: Se envían a los Tech Leads y Product Owners con el desglose de costos de sus aplicaciones y recomendaciones de optimización.
• Reporte Ejecutivo Mensual: Se presenta a la dirección con las tendencias de gasto, el ROI de la nube y el estado de las iniciativas de ahorro.

---

2. Optimizar: Reducir el Desperdicio

Una vez que tenemos visibilidad, podemos empezar a optimizar.

Estrategias de Optimización

Estrategia	Descripción	Responsable
Right-Sizing	Ajustar el tamaño de las VMs y GKE a su uso real. Si una máquina usa solo el 20% de su CPU, se debe reducir.	Equipo de Desarrollo (con ayuda de Recommender)
Committed Use Discounts (CUDs)	Comprometerse a usar una cantidad de recursos base (CPU/RAM) por 1 o 3 años a cambio de un gran descuento (hasta 57%).	Equipo FinOps/Plataforma
Limpieza de Recursos Ociosos	Identificar y eliminar recursos no utilizados (discos sin adjuntar, IPs estáticas sin uso, snapshots antiguos).	Equipo de Desarrollo
Autoscaling Optimizado	Configurar el autoescalado de GKE y VMs para que se ajuste dinámicamente a la demanda, apagando nodos cuando no se necesiten.	Equipo de Desarrollo
Políticas de Storage	Mover datos de acceso poco frecuente a clases de almacenamiento más baratas (Nearline, Coldline, Archive).	Equipo de Desarrollo

---

3. Operar: Controlar y Gobernar

Finalmente, establecemos controles para mantener el gasto alineado con los presupuestos.

Budgets y Alertas

• Budgets por Proyecto: Cada proyecto en GCP tiene un presupuesto mensual asignado.
• Alertas Automáticas: Se configuran alertas para notificar a los dueños del proyecto y al equipo de FinOps cuando el gasto alcanza el 50%, 80%, y 100% del presupuesto.
• Alerta de Anomalías: Se configuran alertas que se disparan si el gasto diario de un proyecto o servicio aumenta de forma anómala (ej. >30% con respecto al promedio), lo que podría indicar un bug o un abuso.

Proceso de Revisión de Costos

• Se realizan reuniones semanales entre el equipo de FinOps y los Tech Leads de los proyectos con mayor gasto para revisar las tendencias, analizar anomalías y planificar optimizaciones.
• Cada trimestre, se revisan y ajustan los presupuestos para el siguiente trimestre en conjunto con los líderes de negocio.

---

4. Costos por Ambiente

El gasto de HERA se distribuye entre los 3 ambientes principales. Entender esta distribución ayuda a identificar ineficiencias — DEV y QA no deberían consumir más del 20-25% del gasto total.

Distribución esperada de costos

Ambiente	% del gasto total	Justificación	Estrategia de optimización
PRD	65-75%	Workloads reales, tráfico de usuarios, HA regional, CUDs	CUDs para baseline, right-sizing continuo, spot para batch
QA	15-20%	Autopilot (paga por pod), pruebas de carga temporales	Autopilot elimina nodos ociosos, scale-to-zero fuera de horario
DEV	10-15%	Autopilot, desarrollo activo solo en horario laboral	Autopilot + scale-to-zero fuera de horario, recursos mínimos

Detección de anomalías por ambiente

Anomalía	Señal	Acción
DEV consume más del 20% del total	Recursos sobredimensionados o no apagados	Revisar pods sin HPA, reducir requests, habilitar scale-to-zero
QA consume más que PRD	Pruebas de carga sin cleanup o recursos persistentes	Verificar que pruebas de carga liberan recursos al terminar
PRD consume 30%+ más que el mes anterior	Growth legítimo o fuga de recursos	Investigar: ¿más tráfico? ¿más servicios? ¿recursos ociosos?

Etiquetado por ambiente

El tag environment es obligatorio en todos los recursos (ver Estándares de Tagging). Esto permite filtrar costos por ambiente en Looker Studio:

Tag environment	Valor	Proyectos GCP
dev	Desarrollo	hera-dev
qa	Quality Assurance	hera-qa
prd	Producción	hera-prd

---

5. Costos de API Management (Apigee)

Apigee es el API gateway enterprise de GCP. Su modelo de costos es diferente a los recursos de compute — se cobra por llamadas API y ambientes, no por CPU/memoria.

Modelo de costos de Apigee

Componente	Qué se cobra	Estimación
Ambientes	Por ambiente activo (dev, qa, prd)	Costo fijo mensual por ambiente
API calls	Por millón de llamadas API procesadas	Variable según tráfico
Analytics	Almacenamiento de datos de analytics	Proporcional al volumen de datos
Mediation/Policies	Incluido en el costo base de API calls	—

Cuándo aplica Apigee en HERA

Escenario	¿Usar Apigee?	Alternativa
APIs expuestas a partners externos	Sí — rate limiting, API keys, analytics, monetización	—
APIs internas entre microservicios	No — overhead innecesario	Service Mesh (ASM) para mTLS y observabilidad
APIs públicas con alto tráfico	Sí — throttling, caching, analytics	—
APIs internas de baja criticidad	No	Ingress con Cloud Armor es suficiente

Optimización de costos de Apigee

Estrategia	Impacto	Detalle
Solo usar Apigee donde agrega valor	Alto	No rutear APIs internas por Apigee — usar para APIs externas y de partners
Caching en Apigee	Medio	Responses cacheables reducen llamadas al backend y costos de compute
Rate limiting	Medio	Previene abuso que genera costos innecesarios de backend
Consolidar ambientes	Medio	Evaluar si DEV necesita un ambiente Apigee separado o puede compartir con QA
Monitoreo de tráfico	Continuo	Revisar mensualmente si hay APIs con tráfico anormalmente alto o bajo

Apigee no es para todo

Apigee aporta valor real cuando necesitas: gestión de API keys para consumidores externos, rate limiting por partner, analytics de uso de APIs, o monetización. Para comunicación interna entre microservicios, Anthos Service Mesh (ASM) provee las capacidades necesarias (mTLS, observabilidad, traffic management) sin el costo adicional de Apigee.

---

6. Gobierno Financiero de Plataforma

Ownership financiero

Nivel	Owner financiero	Responsabilidad
Recurso individual	Developer / Tech Lead (tag owner)	Justificar el sizing, optimizar requests/limits
Servicio	Tech Lead (tag application)	Costo mensual dentro del presupuesto del producto
Producto	Product Owner (tag cost-center)	Presupuesto total del producto, decisiones de inversión vs ahorro
Dominio	Engineering Manager	Presupuesto del dominio, distribución entre productos
Plataforma	VP de Ingeniería	Presupuesto total de cloud, CUDs, estrategia de largo plazo

Proceso de aprobación de gasto

Incremento de costo mensual	Aprobación requerida
Menos de $500 USD	Tech Lead (autónomo)
$500 - $2,000 USD	Product Owner
$2,000 - $10,000 USD	Engineering Manager
Mayor a $10,000 USD	VP de Ingeniería + justificación de negocio

Tu responsabilidad en FinOps

Como desarrollador o líder técnico, eres directamente responsable de la eficiencia de los recursos que consume tu aplicación. Revisa los reportes de costos, aplica las recomendaciones de right-sizing y diseña tus aplicaciones pensando en la eficiencia.