Estamos construyendo celld, un runtime para aplicaciones Cloudflare Workers y Durable Objects en tus propias máquinas. Puede ejecutarse con un almacén de objetos S3-compatible como única dependencia externa.
celld es un sistema distribuido. Hacer que los sistemas distribuidos sean confiables es difícil, parcialmente porque podemos depender involuntariamente de suposiciones que no se mantienen en la práctica, incluso cuando conocemos los peligros. La lista de Peter Deutsch los ocho errores del cómputo distribuido enumera ocho suposiciones tales como "The network is reliable" y "Latency is zero."
Un error puede depender de una secuencia particular de mensajes retrasados, escrituras fallidas y reinicios de nodos. Estos eventos pueden ocurrir en un orden diferente en la próxima ejecución de pruebas, lo que dificulta la reproducción del fallo. Necesitamos poder repetir la ejecución fallida para investigar la causa y comprobar si una propuesta de corrección realmente resuelve el problema. Por eso usamos simulación determinista (DST).
Nuestro simulador aún está en desarrollo y no está incluido en el repositorio público de celld, pero ya ha encontrado errores previamente desconocidos. En este artículo, recorreremos cómo funciona DST en celld y cómo nos ayudó a encontrar, reproducir y corregir uno de esos errores. DST en un entorno controlado por un simulador ejecuta el código de producción de celld. Una celda en celld ejecuta código de aplicación y tiene su propia base de datos SQLite. A medida que las celdas realizan su trabajo, celld maneja eventos como solicitudes entrantes, operaciones de almacenamiento completadas y disparos de temporizadores. El código que selecciona el siguiente evento está separado del código que lo maneja. Esto permite al simulador controlar el orden de los eventos mientras se ejecuta el mismo código de manejo de eventos que en producción.
Fuente: Hacker News · Resumido por HeadlinesBriefing