d59644b96f
The full scope across this batch: POST /sessions key→token exchange, SessionStore dual-index with revoke_by_id, CLI Bearer injection (ONTOREF_TOKEN), ontoref setup --gen-keys, install scripts, daemon config form roundtrip, ADR-004/005, on+re self-description update (fully-self-described), and landing page refresh.
216 lines
8.6 KiB
Markdown
216 lines
8.6 KiB
Markdown
# 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.*
|