Jesús Pérez d59644b96f

feat: unified auth model, project onboarding, install pipeline, config management

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.

2026-03-13 20:56:31 +00:00

8.6 KiB

Raw Blame History

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

JSON entre máquinas funciona bien → pero es ilegible para humanos
Pasamos a YAML / TOML → sintaxis frágil, errores de indentación
Usamos gestores de plantillas (Helm, Jinja) → generan YAML a partir de variables en YAML
¿Valida el contenido? No. En absoluto.
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"