Un programa ejecuta instrucciones. Un sistema debe conservar estado, coordinar componentes y seguir siendo comprensible cuando algo falla. Systems Lab explora esas decisiones mediante modelos, experimentos y lecciones de operación.
El punto de partida es seguir una petición desde que entra hasta que produce un resultado: qué componentes intervienen, qué compromisos asumen y cómo comprobamos que el trabajo terminó. Los cuatro ejes del lab permiten examinar ese recorrido desde distintos ángulos.
Tres recorridos para seguir una idea
-
System Design — decisiones de arquitectura sobre datos, capacidad, comunicación y recuperación. Parte de requisitos e invariantes y compara qué protege cada mecanismo.
-
Homelab — Kubernetes y operación de infraestructura: despliegue, redes, almacenamiento, seguridad y señales del sistema. Lleva las decisiones al terreno de la configuración, la verificación y los fallos reales.
-
Platform Engineering — infraestructura reproducible, entrega verificable, permisos acotados y costes con supuestos explícitos. Conecta los contratos del sistema con el trabajo de los equipos que construyen y operan su plataforma.
Los recorridos se complementan. Un modelo explica qué debe mantenerse cierto; operarlo exige saber dónde observarlo y cómo recuperarlo. Los cuatro ejes siguientes sirven para conectar estos recorridos.
Estado y persistencia
El estado registra lo que el sistema sabe y lo que ya ocurrió. Su ubicación y duración determinan qué puede recuperarse después de una interrupción y qué componentes pueden modificarlo.
Este eje abarca memoria y almacenamiento, transacciones, consistencia, aislamiento y evolución de los datos. La pregunta central es qué debe seguir siendo cierto cuando un proceso termina o varios componentes actúan al mismo tiempo.
Comunicación y coordinación
Los componentes necesitan intercambiar información y acordar quién hace cada trabajo. Al cruzar un límite de proceso o de red, una llamada introduce latencia, incertidumbre y nuevas formas de fallar.
Aquí entran contratos de API, llamadas síncronas, colas, eventos, orden de mensajes y garantías de entrega. El objetivo es entender qué conoce cada participante y qué puede asumir sobre los demás.
Fallos y recuperación
Un componente puede detenerse mientras otros siguen funcionando. Una petición puede haber producido un efecto aunque su respuesta nunca llegue. Recuperarse exige distinguir el trabajo pendiente del que ya ocurrió.
Este eje reúne límites de tiempo, reintentos, idempotencia, aislamiento de fallos, degradación y restauración. Cada mecanismo debe explicar qué fallo resuelve, qué coste introduce y cómo se verifica la recuperación.
Observabilidad
Operar un sistema requiere reconstruir su comportamiento a partir de señales. Los logs registran eventos, las métricas muestran tendencias y las trazas conectan el recorrido de una petición entre componentes.
Aquí se estudian instrumentación, latencia, errores, saturación y objetivos de servicio. La pregunta es cómo detectar un problema, localizarlo y comprobar su impacto sobre el resultado que espera el usuario. En Homelab, las notas de logs y métricas y salud permiten examinar las señales de la plataforma junto a ese resultado.
Lecturas para empezar
- Primero hazlo naive, después hazlo mejor — empezar con un proceso sencillo y aprender qué merece automatizarse.
- Agentes multi-tenant en Kubernetes — decisiones sobre estado, aislamiento y costes de arquitectura.
- ¿Usarías Tailscale en producción? — conectividad, acceso remoto y continuidad del homelab.
- Los flujos de trabajo agentes presuponen determinismo — una discusión sobre el comportamiento esperado de los agentes y la naturaleza probabilística de sus modelos.
Cómo trabajar en el lab
Cada nota o experimento parte de un problema concreto, explicita los límites del sistema y compara decisiones. Después introduce un fallo o una condición adversa y muestra cómo observar el resultado. El aprendizaje queda completo cuando podemos explicar qué ocurrió y comprobarlo de nuevo.