ontoref/assets/presentation/00_talk-structure.md

# Talk Structure: Why I Needed Rust

> Orientado a: `abstract_en.md`
> Fuente: `2026-02-17-notas_voz.md`

---

## Sistema de Medidores *(elemento visual persistente)*

Tres barras que aparecen en esquina de cada slide de transición.
Escala 0–5. Se actualizan en cada etapa clave.

```
🛡 Confianza   ●●●●● = máxima certeza sobre el sistema
😴 Descanso    ●●●●● = puedes dormir tranquilo
🔥 Estrés      ●●●●● = alarma permanente, pesadillas
```

**Estado inicial (apertura)**
```
🛡 ●●●○○   😴 ●●●○○   🔥 ●○○○○
```
*Se presenta como "¿Reconoces estos números? Sigamos..."*

**Progresión a lo largo de la charla:**

| Momento | 🛡 Confianza | 😴 Descanso | 🔥 Estrés |
|---|:---:|:---:|:---:|
| Etapa 1 — Local | ●●●●○ | ●●●●○ | ●○○○○ |
| Etapa 2 — Redes | ●●●○○ | ●●●○○ | ●●○○○ |
| Etapa 3 — Cloud/CI-CD | ●●○○○ | ●○○○○ | ●●●●○ |
| YAML hell / peak pain | ●○○○○ | ○○○○○ | ●●●●● |
| Rust — compilador | ●●●○○ | ●●○○○ | ●●●○○ |
| Rust — tipos + traits | ●●●●○ | ●●●●○ | ●●○○○ |
| Cierre | ●●●●● | ●●●●● | ●○○○○ |

> El título de la charla ES el último estado del medidor de sueño.

---

## 0. Hook de apertura

**Imagen concreta**: definir un host, un nodo, un puerto.
- Eso es todo. Queremos que algo corra en algún sitio y que algo pueda hablar con él.
- ¿Cómo de difícil puede ser?

**Promesa**: vamos a ver por qué eso, durante 30 años, nos ha dado pesadillas. Y por qué Rust cambió eso.

*→ Mostrar medidores en interrogante o en estado inicial neutro*

---

## 1. Evolución de los desafíos en infraestructura (2013-2025)

*Abstract: "The evolution of infrastructure challenges (2013-2025)"*

### Etapa 1 — Local (finales 80s / primeros 90s)
- Terminales tontos, desarrollo local
- Ciclos de despliegue largos, baja urgencia
- Un solo estado, fácil de observar y controlar
- IaC: scripts procedurales, lógica oculta en comandos o en la aplicación

> *Medidores fin Etapa 1:* `🛡 ●●●●○   😴 ●●●●○   🔥 ●○○○○`
> *"Tienes un servidor. Sabes lo que tiene. Puedes dormir."*

### Etapa 2 — Conectividad en red / Internet
- Los sistemas están cada vez más lejos — acceso remoto, redes distantes
- Seguridad empieza a importar; procesos críticos, coste de caída sube
- Más agentes participando (dev, ops, seguridad) — hay que armonizar
- Armonizar: instalación de paquetes, configuración de recursos, actualizaciones en paralelo
- IaC: procesos automatizables y reproducibles, primeros intentos declarativos, config-driven model

> *Medidores fin Etapa 2:* `🛡 ●●●○○   😴 ●●●○○   🔥 ●●○○○`
> *"Más piezas. Más personas. Empieza a ponerse interesante."*

### Etapa 3 — Contenedores / Cloud / CI-CD
- Monolítico → distribuido, 24×7×365, alta disponibilidad
- Cloud, híbrido, multi-cloud, on-prem — todo a la vez
- Rollback y rollforward: como transacciones de BD, pero en infraestructura
- Escalado horizontal **y** vertical, también **desescalado** — en ambas direcciones
- CI/CD continuo, ciclos cortos — nuevas funcionalidades, nuevos despliegues, permanente
- IaC: Helm, Ansible, Terraform — más herramientas, más complejidad
- Múltiples versiones de "lo que creemos que es válido" — la fuente de verdad se fragmenta
- **Resultado**: estados de alarma como norma, no como excepción

> *Medidores fin Etapa 3:* `🛡 ●●○○○   😴 ●○○○○   🔥 ●●●●○`

> *"¿Hemos aumentado la productividad? Sí.<br> ¿Hemos aumentado el estrés? Sí.<br> ¿Hemos aumentado las posibilidades de tener problemas? También.<br> ¿Tenemos más control y seguridad? No."*

---

## 2. Por qué el IaC tradicional falla a escala

*Abstract: "Why traditional approaches to IaC fall short at scale"*

### El ciclo del YAML hell
1. JSON entre máquinas funciona bien → pero es ilegible para humanos
2. Pasamos a YAML / TOML → sintaxis frágil, errores de indentación
3. Usamos gestores de plantillas (Helm, Jinja) → generan YAML a partir de variables en YAML
4. **¿Valida el contenido?** No. En absoluto.
5. Cruzamos los dedos.

> *Medidores — YAML hell peak:* `🛡 ●○○○○   😴 ○○○○○   🔥 ●●●●●`
> *"Esto es el suelo. A partir de aquí, o seguimos igual o buscamos algo mejor."*

### Las tres preguntas sin respuesta

**Pregunta 1: ¿Por qué esperamos a que se rompa?**
- "In my machine it works" — en producción, no lo sé
- Fail late = coste máximo
- Queremos: fail fast, fail cheap

**Pregunta 2: ¿Tenemos claro lo que queremos?**
- ¿La declaración es suficiente? ¿Consistente con lo que es posible?
- ¿Respeta los límites y reglas del sistema?
- ¿Cuál es la "fuente de verdad" y cuándo muta?

**Pregunta 3: ¿Tenemos herramientas que garanticen determinismo?**
- CI/CD continuo sin validación semántica = esperanza continua
- Queremos certeza, no aleatoriedad
- "En mi máquina funciona" no puede ser el estándar de producción

### Analogía del restaurante *(hilo conductor)*
| Restaurante | Infraestructura |
|---|---|
| Comensal declara lo que quiere | Config declarativa (YAML, HCL) |
| Camarero valida si es posible | Orchestrator (K8s, Ansible) |
| Cocina ejecuta y entrega | Runtime / provisioning |
| El plato llega o no llega | Deployment falla o no |

- El camarero no puede volver a cocina con un pedido imposible
- La cocina no puede asumir ingredientes que no están
- Cada actor en la cadena tiene una vista parcial de "la verdad"
- Un fallo en mesa ≠ un fallo en cocina ≠ un fallo en entrega → coste diferente en cada punto

---

## 3. Type safety y memory safety como fiabilidad en producción

*Abstract: "Type safety and memory safety as production reliability"*

### Lo que Rust introduce

**Tipado estático estricto**
- Un número no es un string. Un puerto no es cualquier entero.
- Tipos primarios ricos + tipos compuestos (structs, enums)
- Las conversiones (cast) son explícitas, no implícitas

**Inmutabilidad por defecto**
- "Quiero tomate. Puedes inventarte lo que quieras, pero sin tomate no es el plato que pedí."
- Lo que no puede cambiar, no cambia. Sin sorpresas en runtime.

**Options, no nulos**
- No `null`, no "asume que está". `Option<T>`: está o no está, y ambos casos son manejados.
- Ingrediente opcional: si no está, lo sé. Lo cobro o no. Pero lo controlo.

**Enums y rangos como restricciones**
- Un puerto válido es un rango entre 0 y 65535, no cualquier número
- Un cloud provider es `AWS | GCP | Azure | OnPrem`, no un string libre
- Las restricciones son parte del tipo, no de la documentación

**Traits como contratos**
- Composición en vez de herencia
- Implementaciones validadas contra interfaces definidas
- Diferentes "actores" en la cadena pueden tener diferentes implementaciones del mismo contrato

**El compilador como pre-validación**
- Valida *antes* de construir el binario
- No cuando lleva tiempo en ejecución
- No cuando se llama a una función que hace meses que nadie toca
- Binarios predecibles en comportamiento de memoria, recursos y flujos

> *"El compilador es el camarero que valida el pedido antes de que llegue a cocina."*

> *Medidores — Rust completo:* `🛡 ●●●●●   😴 ●●●●●   🔥 ●○○○○`

---

## 4. Orquestación segura multi-cloud y on-prem

*Abstract: "Building safe orchestration across multi-cloud and on-prem environments"*

*(Sección a desarrollar — no cubierta en las notas de voz actuales)*

Puntos a cubrir:
- Tipos como esquema de infraestructura → no YAML libre
- Traits para abstraer providers (AWS, GCP, on-prem, K8s)
- Compilador detecta configuraciones imposibles antes del despliegue
- Estado mutable explícito → sin configuration drift silencioso

---

## 5. Aplicaciones reales

*Abstract: "Real applications: Kubernetes, blockchain validators, disaster recovery"*

*(Sección a desarrollar — no cubierta en las notas de voz actuales)*

Casos concretos:
- Kubernetes: operadores en Rust, CRDs con tipos seguros
- Blockchain validators: disponibilidad crítica, configuración determinista
- Disaster recovery: reproducibilidad, sin "funciona en prod pero no en DR"

---

## Cierre

- No hemos inventado nada nuevo. Los problemas siempre han existido.
- Rust los reúne y los resuelve: tipos, traits, compiler, memory safety.
- El resultado: infraestructura predecible. Deployments sin pesadillas.
- **Duermes bien.**

> *Medidores — cierre:* `🛡 ●●●●●   😴 ●●●●●   🔥 ●○○○○`
>
> *Slide final: los tres medidores en verde. Título de la charla. Fin.*