# 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í.
¿Hemos aumentado el estrés? Sí.
¿Hemos aumentado las posibilidades de tener problemas? También.
¿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`: 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.*