From c2eff947e17b35a0c54c6667d5cebf5d7163cbd5 Mon Sep 17 00:00:00 2001 From: Joel Alvarez Date: Tue, 21 Jul 2026 11:48:32 -0700 Subject: [PATCH] docs: specify finops foundations Closes #29 Co-authored-by: Joel Alvarez D. <124008575+joelalvarezduenas@users.noreply.github.com> --- README.md | 2 +- ROADMAP.md | 7 +- course.manifest.json | 2 +- docs/08-costos-y-finops.md | 139 ++++++++++++++++++++++++++++++++++++- src/lib.rs | 5 +- 5 files changed, 145 insertions(+), 10 deletions(-) diff --git a/README.md b/README.md index 8ad5575..54c3e67 100644 --- a/README.md +++ b/README.md @@ -41,7 +41,7 @@ complementarios como `rust-devops`, `rust-api-design` y | 05 | Identidad y accesos | `src/iam.rs` | implemented | | 06 | Servicios manejados | `src/managed_services.rs` | implemented | | 07 | Serverless | `src/serverless.rs` | implemented | -| 08 | Costos y FinOps | `src/finops.rs` | planned | +| 08 | Costos y FinOps | `src/finops.rs` | draft | | 09 | AWS en la práctica | `src/aws_practice.rs` | planned | | 10 | GCP en la práctica | `src/gcp_practice.rs` | planned | diff --git a/ROADMAP.md b/ROADMAP.md index 5919da8..8ddba36 100644 --- a/ROADMAP.md +++ b/ROADMAP.md @@ -49,7 +49,7 @@ esperada es: | 05 | Identidad y accesos | implemented | | 06 | Servicios manejados | implemented | | 07 | Serverless | implemented | -| 08 | Costos y FinOps | planned | +| 08 | Costos y FinOps | draft | | 09 | AWS en la práctica | planned | | 10 | GCP en la práctica | planned | @@ -74,5 +74,6 @@ esperada es: ## Siguiente paso natural -Iniciar el milestone `08. Costos y FinOps` con concepto, problema, alternativas -e invariantes antes de escribir el modelo Rust mínimo. +Completar el milestone `08. Costos y FinOps` con el flujo restante: modelo Rust +mínimo, capítulo narrativo, diagrama Mermaid, ejemplos progresivos, ejercicios, +soluciones y análisis de costos. diff --git a/course.manifest.json b/course.manifest.json index 253dc40..cc7ebd8 100644 --- a/course.manifest.json +++ b/course.manifest.json @@ -112,7 +112,7 @@ "number": 8, "title": "Costos y FinOps", "slug": "costos-y-finops", - "status": "planned", + "status": "draft", "milestone": "08. Costos y FinOps", "document": "docs/08-costos-y-finops.md", "module": "src/finops.rs", diff --git a/docs/08-costos-y-finops.md b/docs/08-costos-y-finops.md index 3c26ea0..ab230d2 100644 --- a/docs/08-costos-y-finops.md +++ b/docs/08-costos-y-finops.md @@ -2,10 +2,143 @@ - **Curso:** rust-cloud - **Semestre:** 5 -- **Estado:** planned +- **Estado:** draft - **Milestone:** 08. Costos y FinOps +- **Issues:** #29 - **Módulo Rust:** `src/finops.rs` -## Nota editorial +## Concepto -Capítulo planeado. No está marcado como `reviewed` ni `published`. +Costos y FinOps es la disciplina que convierte el gasto cloud en una decisión +visible de ingeniería, producto y operación. No se limita a ahorrar dinero: busca +entender qué uso genera costo, qué valor produce, qué señales permiten corregir +rumbo y qué responsabilidades tiene cada equipo. + +En este curso, FinOps se estudia como un ciclo de **visibilidad, atribución, +decisión y ajuste**. La pregunta central no es "¿cuánto cuesta AWS o GCP?", +sino "¿qué decisión técnica generó este costo, qué valor sostiene y qué cambio +responsable podemos hacer sin romper el sistema?". + +## Imagen mental + +Piensa en una cocina profesional que vende comidas por pedido. + +- El **ticket promedio** dice cuánto valor entra por venta. +- La **receta** define qué ingredientes, equipo y pasos consume cada plato. +- La **merma** muestra desperdicio de insumos. +- El **horno encendido** cuesta aunque no haya pedidos. +- El **reparto** agrega costo por distancia, urgencia y volumen. +- El **tablero diario** permite corregir antes de cerrar el mes. + +Cloud funciona de forma parecida. Una arquitectura no solo debe responder bien; +debe explicar qué consume, por qué lo consume y cuándo ese consumo deja de +comprar valor real. + +## Problema + +Cloud permite crear recursos elásticos, pagar por uso, probar rápido y delegar +operación. Esa misma flexibilidad puede convertir el costo en sorpresa: recursos +olvidados, logs sin retención, tráfico entre regiones, bases sobredimensionadas, +concurrencia sin límite, almacenamiento acumulado, entornos duplicados y +servicios que nadie siente propios. + +La enseñanza de costos suele caer en tres errores: + +- reducir FinOps a "apagar recursos"; +- presentar precios de proveedor sin explicar las decisiones que los producen; +- tratar costo y arquitectura como conversaciones separadas. + +Sin una base clara, el estudiante puede creer que optimizar costo es un acto +contable posterior, no una parte del diseño de sistemas. También puede creer que +una arquitectura barata es automáticamente buena, o que una factura alta siempre +es mala, sin distinguir desperdicio, inversión deliberada y riesgo aceptado. + +## Alternativas consideradas + +1. **Empezar por calculadoras de proveedor.** Son útiles para estimaciones, pero + cambian rápido y pueden ocultar el modelo de consumo. +2. **Empezar por reglas de ahorro.** Es práctico, pero vuelve el capítulo una + lista de consejos sin criterio transferible. +3. **Empezar por unidad de costo, atribución y tradeoff operativo.** Permite + razonar sobre recursos, tráfico, datos, observabilidad y capacidad antes de + aterrizar precios fechados. + +## Justificación + +Este capítulo adopta la tercera alternativa. Primero se modela el costo como una +relación entre unidad técnica, uso, dueño, criticidad, valor, señales y decisión +de optimización. Después se podrán usar precios de proveedor como material vivo, +fechado y revisado. + +La decisión conserva RFC-0001 §2: concepto antes de implementación, problema +antes de herramienta, alternativas antes de elección. También mantiene +RFC-0001 §10: proveedor después de fundamentos. + +## Invariantes del capítulo + +- Todo costo cloud debe tener dueño operativo o de producto. +- Un costo no atribuido es una deuda de observabilidad y gobierno. +- Optimizar costo sin entender valor puede degradar el sistema. +- El costo se diseña: capacidad, datos, red, logs, reintentos y regiones importan. +- La unidad de costo debe poder nombrarse: invocación, GiB, petición, hora, + transferencia, índice, transición o retención. +- La elasticidad necesita límites; sin límites, el costo también escala. +- Los ambientes no productivos también tienen costo y ciclo de vida. +- Los ahorros deben medirse contra riesgo, latencia, operación y experiencia. +- FinOps no reemplaza arquitectura; la vuelve económicamente observable. +- Los precios de proveedor son material vivo y deben fecharse cuando se usen. + +## Comparación educativa + +| Elemento | Qué decide | Qué no decide por sí solo | Riesgo común | +|----------|------------|----------------------------|--------------| +| Unidad de costo | Qué recurso explica el gasto | Valor producido | Medir consumo sin contexto | +| Atribución | Quién entiende el gasto | Optimización automática | Facturas huérfanas | +| Propósito | Qué valor compra el consumo | Precio correcto | Defender gasto inútil | +| Límite | Hasta dónde puede crecer | Uso saludable | Confundir elasticidad con infinito | +| Señal de uso | Cuándo investigar | Acción adecuada | Alertar tarde o sin dueño | +| Tradeoff | Qué riesgo se acepta | Ahorro garantizado | Romper confiabilidad por ahorrar | + +## Requisitos para `src/finops.rs` + +El módulo Rust mínimo deberá modelar, sin dependencias externas: + +- unidades educativas de costo: cómputo, almacenamiento, red, observabilidad, + invocaciones y servicios manejados; +- dueño, propósito y ambiente del gasto; +- frecuencia o intensidad de uso; +- criticidad y elasticidad; +- hallazgos cuando falten dueño, propósito, límite, señal de uso o ambiente; +- evaluación de riesgos por gasto no atribuido, elasticidad sin límite, + observabilidad excesiva o recursos constantes sobredimensionados. + +El módulo no debe intentar calcular precios reales. Su función es pedagógica: +hacer visibles las variables que explican por qué aparece un costo. + +## Decisiones pendientes + +- Definir si la unidad de costo será enum cerrado o perfil extensible. +- Definir cómo representar intensidad de uso sin prometer estimaciones reales. +- Nombrar hallazgos públicos antes de escribir ejemplos. +- Decidir qué umbrales educativos son suficientes sin depender de proveedor. + +## Práctica sugerida + +Antes de optimizar una arquitectura cloud, escribe: + +1. Unidad económica: por estudiante, transacción, curso, documento, minuto o + evento. +2. Recurso dominante: cómputo, almacenamiento, red, base de datos, + observabilidad u operación humana. +3. Dueño: quién puede interpretar y corregir la señal. +4. Valor: qué capacidad legítima compra ese gasto. +5. Desperdicio probable: qué consumo no compra valor. +6. Riesgo: qué se puede romper al optimizar. +7. Control: presupuesto, alerta, reporte o revisión periódica. + +Si no puedes explicar qué valor compra un costo, todavía no deberías +optimizarlo: primero debes entenderlo. + +## Estado editorial + +Este capítulo queda en `draft`. No está marcado como `reviewed` ni `published`. diff --git a/src/lib.rs b/src/lib.rs index 7401d5b..ae0caa8 100644 --- a/src/lib.rs +++ b/src/lib.rs @@ -92,7 +92,7 @@ const PLANNED_CHAPTERS: [Chapter; 10] = [ Chapter { number: 8, title: "Costos y FinOps", - status: ChapterStatus::Planned, + status: ChapterStatus::Draft, }, Chapter { number: 9, @@ -125,7 +125,7 @@ mod tests { assert!( chapters .iter() - .skip(7) + .skip(8) .all(|chapter| chapter.status == ChapterStatus::Planned) ); assert_eq!(chapters[0].status, ChapterStatus::Implemented); @@ -135,5 +135,6 @@ mod tests { assert_eq!(chapters[4].status, ChapterStatus::Implemented); assert_eq!(chapters[5].status, ChapterStatus::Implemented); assert_eq!(chapters[6].status, ChapterStatus::Implemented); + assert_eq!(chapters[7].status, ChapterStatus::Draft); } }