Cloudflare Workers es la plataforma serverless edge más madura en 2023. Ejecuta tu código JavaScript o WebAssembly en 300+ datacenters globales, sin que tengas que gestionar regiones, contenedores ni cold starts perceptibles. La arquitectura difiere fundamentalmente de Lambda y similares — y esa diferencia define dónde brilla y dónde no llega.
La arquitectura: V8 isolates en lugar de contenedores
AWS Lambda y similares lanzan un contenedor (o microVM como Firecracker) para cada función. Tienen cold starts medibles — de 100ms a varios segundos.
Cloudflare Workers utilizan V8 isolates, la misma tecnología que aísla pestañas en Chrome. Cada Worker corre en un isolate dentro de un proceso Node.js compartido. Las consecuencias:
- Cold start de 0-5 ms. Crear un isolate es mucho más barato que un contenedor.
- Footprint de memoria muy bajo. Cientos de Workers pueden coexistir en el mismo proceso.
- Coste muy bajo por invocación. La free tier de Cloudflare es generosa precisamente porque cada invocación cuesta poquísimo en infraestructura.
- Limitaciones: no puedes usar APIs de sistema operativo, threads nativos o módulos npm que dependan de bindings nativos.
Para casos donde el modelo encaja, esto es transformador. Para casos donde no, es bloqueante.
Lo que se puede ejecutar
Workers acepta:
- JavaScript ES Modules moderno.
- TypeScript (compilado a JS antes del deploy).
- WebAssembly: Rust, Go (TinyGo), C, AssemblyScript compilados a Wasm. Ideal para lógica CPU-intensive donde JS sería lento.
Lo que no acepta:
- Módulos Node.js que dependan de bindings C nativos (sharp, bcrypt nativo, etc.).
- Acceso al filesystem local.
- Spawn de procesos.
- Listening de sockets TCP arbitrarios (excepto los outbound permitidos).
Storage: KV, Durable Objects, R2, D1
Workers no es solo cómputo — Cloudflare ha construido un stack de storage edge:
Workers KV
Almacén key-value distribuido globalmente, eventualmente consistente.
- Lectura: muy rápida y cacheada en cada datacenter.
- Escritura: propagación a todos los nodos en segundos a un minuto.
- Caso de uso: configuración, feature flags, cache de respuestas, lecturas frecuentes.
- Limitaciones: latencia de escritura, no apto para datos transaccionales.
Durable Objects
Objetos con estado consistente y único globalmente. Cada objeto vive en un datacenter (a menudo el más cercano al primer uso) y procesa todas las requests para esa instancia secuencialmente.
- Caso de uso: sesiones de usuario, salas de chat, contadores precisos, coordinación distribuida.
- Modelo mental: un actor con estado en ubicación fija pero accesible globalmente.
R2
Object storage compatible con S3, sin egress fees.
- Caso de uso: assets, vídeos, backups, contenido grande.
- Ventaja clave: precio sin penalización por servir datos a Internet (vs S3 con egress caro).
D1
Base de datos SQLite distribuida (en beta en 2023, GA pronto).
- Caso de uso: datos relacionales con queries SQL para apps edge.
- Modelo: lectura desde réplicas locales, escritura va a una región primaria.
Esta combinación cubre la mayoría de necesidades de aplicaciones edge sin tener que llamar a un origin tradicional.
Casos donde Workers brilla
Donde la arquitectura encaja perfectamente:
- Edge logic en frontend. Routing inteligente, A/B testing, redirects basados en geo o bot detection.
- API gateway personalizado. Validar tokens, rate limit, transformar requests antes de enviarlas al origin.
- APIs simples sin backend tradicional. CRUD ligero con KV o D1 sin desplegar servidores.
- Streaming y procesamiento de respuestas. Pasar el response del origin a través de Workers para aplicar transformaciones.
- Webhooks de alto throughput. Reciben muchísimas requests por segundo a coste mínimo.
- Proxies inteligentes. Workers en front de un origin tradicional, añadiendo cache, auth, telemetría.
Casos donde no es la herramienta
Honestidad: Workers no encaja en todo:
- APIs con dependencias pesadas npm. Workers no soporta gran parte del ecosistema Node nativo.
- Workloads CPU-intensivas largas. Hay límites de tiempo de CPU por request (ms-segundos).
- Long-running tasks. Workers no son contenedores — diseñados para responder rápido.
- Datos transaccionales fuertes. KV es eventually consistent; D1 está madurando; las garantías ACID son menos fuertes que un Postgres tradicional.
- Workloads con estado complejo. Durable Objects ayudan pero no resuelven todo.
Comparativa con Lambda y similares
| Aspecto | Workers | AWS Lambda | Vercel/Netlify |
|---|---|---|---|
| Cold start | ~0-5 ms | 100ms-2s | Similar a Lambda |
| Distribución global | 300+ datacenters | Por región AWS | Edge en algunos casos |
| Lenguajes | JS/TS/Wasm | Casi todos | Mayormente JS/TS |
| Storage edge integrado | Sí | No (DynamoDB regional) | Limitado |
| Coste por request | Muy bajo | Bajo, escala con uso | Variable |
| Soporte Node.js completo | Limitado | Completo | Completo |
Para JavaScript edge logic, Workers es la opción más sólida. Para workloads complejas con dependencias amplias, Lambda sigue siendo más flexible.
Workflow de desarrollo
Cloudflare ha invertido en developer experience:
wranglerCLI. Crear, desarrollar y deployar Workers desde local.wrangler dev. Desarrollo local con hot reload, simula KV/Durable Objects.- Deploy en segundos. Sin build complejo, deploy es prácticamente instantáneo.
- Logging integrado.
wrangler tailmuestra logs en vivo.
El loop de iteración es muy rápido comparado con desplegar Lambda + API Gateway + IAM + CloudFront.
Conclusión
Cloudflare Workers ha consolidado el edge serverless como categoría madura en 2023. Para casos que encajan con el modelo (JavaScript/Wasm, lógica corta, storage edge), es probablemente la mejor opción disponible — más rápido, más barato, más distribuido que las alternativas. Para casos que no encajan (workloads pesadas, dependencias Node nativas), no fuerces — usa Lambda o un servidor tradicional. Conocer ambas opciones expande tu repertorio.
Síguenos en jacar.es para más sobre edge computing, serverless y arquitecturas modernas distribuidas.
