Fastly Compute: edge de alto rendimiento con WebAssembly

javi
Abstracción geométrica de red de datos en tonos azul oscuro

Fastly Compute (antes Compute@Edge) es la apuesta de Fastly por el edge computing serio. Mientras Cloudflare Workers usa isolates V8 y Workers KV, Fastly escogió WebAssembly puro sobre su propio runtime Lucet/Wasmtime. Dos filosofías distintas con implicaciones de rendimiento, portabilidad y ergonomía. Este artículo compara honestamente ambas y explica cuándo Fastly es la opción correcta.

La apuesta técnica de Fastly

Fastly decidió no construir un runtime JavaScript propio ni apoyarse en Node. Optó por WebAssembly como target:

  • Tu código (Rust, Go, AssemblyScript, JS vía Javy) compila a .wasm.
  • Fastly despliega el binary a sus ~70 PoPs globalmente.
  • Cada request invoca una instancia efímera del módulo Wasm.
  • Cold start: 35 microsegundos (μs, no ms) — Fastly se apoya en esto.

El número es real pero merece contexto: Workers también tiene cold start sub-5ms. La diferencia de 1ms→35μs no es visible para el usuario; pero sí permite ejecutar miles de funciones por request sin overhead.

Lenguajes soportados

Oficialmente:

  • Rust: el ciudadano de primera clase. Tooling más maduro (fastly crate), documentación mejor.
  • JavaScript: soporta subset de JS + TypeScript. Se ejecuta vía Javy — JS → Wasm ahead-of-time.
  • Go: soportado via TinyGo. Limitaciones respecto a Go estándar.
  • AssemblyScript: subset de TypeScript que compila directo a Wasm.

Para proyectos nuevos, Rust es la recomendación. Para equipos JS puros, el soporte es bueno pero no alcanza la ergonomía de Workers.

Modelo de ejecución

Cada request:

  1. Llega al PoP más cercano al usuario.
  2. Se instancia el módulo Wasm (35μs de cold start).
  3. Se ejecuta el handler.
  4. Se destruye la instancia (ejecución stateless por defecto).
  5. Responde.

No hay estado compartido entre requests dentro del mismo proceso — Fastly prioriza determinismo y aislamiento.

Hello world en Rust

use fastly::http::{Method, StatusCode};
use fastly::{Error, Request, Response};

#[fastly::main]
fn main(req: Request) -> Result<Response, Error> {
    match (req.get_method(), req.get_path()) {
        (&Method::GET, "/") => Ok(Response::from_status(StatusCode::OK)
            .with_body("Hola desde Fastly Compute")),
        _ => Ok(Response::from_status(StatusCode::NOT_FOUND)),
    }
}

Deploy:

fastly compute publish

El workflow CLI es pulido. Builds locales, preview deployments, rollback — todo con fastly.

Fastly Compute vs Cloudflare Workers

Comparación honesta:

Aspecto Fastly Compute Cloudflare Workers
Runtime WebAssembly (Wasmtime) V8 isolates
Cold start 35μs ~1-5ms
Lenguaje principal Rust, JS JS, TypeScript
PoPs ~70 ~300+
KV/store KV Store (simple) Workers KV (sofisticado), D1, R2
Precio entry $50/mes $5/mes
DX Bueno (Rust) Excelente (JS)
Portabilidad Wasm estándar Vinculado a CF

Para edge código intensivo en cómputo en Rust/Go, Fastly rinde mejor. Para apps JS/TS con ecosystem grande, Workers es más productivo. Cloudflare tiene ventaja en número de PoPs y pricing entry.

Donde Fastly brilla

Escenarios donde Fastly gana:

  • Código Rust portable. Si ya tienes lógica crítica en Rust, portarla es natural.
  • Compliance y control. Fastly es percibido como más “enterprise-grade”, con compliance maduro.
  • Integración con Fastly CDN. Para clientes ya en Fastly, Compute es evolución natural.
  • Performance predecible. Cold start sub-millisecond importa para workloads de alta concurrencia.
  • Edge personalizado serio. A/B tests complejos, rewriting, transformaciones de imagen.

Donde Workers brilla

Por contra:

  • Ecosystem JS. Packages de npm directamente (con algunas adaptaciones) funcionan.
  • Durable Objects + KV + D1: Workers tiene más piezas gratis.
  • Precio entry: empezar es más barato.
  • More PoPs: mejor cobertura en algunas regiones.
  • Community: más ejemplos, más tutoriales públicos.

Casos reales

Patrón común con Fastly:

  • API gateway: validar auth, transformar requests, rutear según features flags.
  • Image optimization: redimensionar y optimizar imágenes on-the-fly.
  • Rewriting HTML: inyectar banners, personalizar contenido.
  • AB testing: split traffic con lógica determinística.
  • Geo-based routing: servir contenido distinto según país/ciudad.

Para contenido estático puro, un CDN normal basta. Compute es para lógica en el borde.

Costes realistas

Fastly Compute:

  • Plan Essential: $50/mes incluye 1M requests.
  • Requests adicionales: $0.50 / 1M.
  • Compute time: separate charge según ms usados.

Cloudflare Workers:

  • Free: 100k requests/día.
  • Paid: $5/mes incluye 10M requests.
  • Adicionales: $0.30 / 1M.

Para cargas bajas, Workers es claramente más barato. Para cargas altas con lógica compleja, Fastly puede ser competitivo por eficiencia del runtime Wasm.

Limitaciones actuales

Ser honesto:

  • Tamaño del binary limitado (~100MB). Para apps grandes compiladas a Wasm, puede quedarse corto.
  • Tiempo máximo por request: ~60s.
  • Sin WebSockets nativo persistente (Workers Durable Objects gana aquí).
  • Debugging limitado: stack traces Wasm no son tan claros como JS devtools.
  • Menor contexto y ejemplos comunitarios que Workers.

WebAssembly en edge: la tendencia

Más allá de Fastly:

  • Cloudflare tiene Workers for Platforms con soporte Wasm opcional.
  • wasmer-edge apuesta por edge wasm distribuido.
  • shuttle.rs — Rust full-stack con deploy edge.
  • Suborbital (ahora adquirido) — edge functions vía Wasm.

El patrón “Wasm + edge” está consolidándose. Fastly fue pionero; otros siguen.

Migración desde Workers

Si consideras pasar de Workers a Fastly:

  • Código JavaScript: re-trabajo moderado. Runtime distinto (no Node, no V8 específico).
  • Features CF-específicas (Durable Objects, D1, KV): reemplazar por patrones externos (Redis, PostgreSQL, S3).
  • Deploy pipelines: wrangler → fastly (similar conceptualmente).
  • Performance testing: validar que los 35μs de cold start se notan en tu caso real.

Para la mayoría no merece la pena migrar solo por Fastly; pero es buena opción para proyectos nuevos donde Rust/Wasm es la elección natural.

Conclusión

Fastly Compute es una apuesta técnica seria por WebAssembly en el edge. Para workloads intensivos en cómputo, lógica compleja en Rust, o equipos ya en Fastly CDN, es la opción más rendidora. Para el caso medio de “edge lógica JS con ecosystem npm y simplicidad”, Cloudflare Workers sigue siendo más práctica. La elección no es ideológica — es de contexto. Lo que ambas representan es la convergencia real de “función serverless en el borde”, cada vez más capaz de reemplazar bricks de infraestructura tradicional.

Síguenos en jacar.es para más sobre edge computing, WebAssembly y arquitecturas distribuidas.

Entradas relacionadas