Computación Edge y Arquitectura Serverless: Lo Que Funciona y Lo Que No

Cada vez que veo a alguien migrar su stack completo a edge functions solo porque "es lo nuevo", me pregunto cuánto tiempo pasará antes de que se topen con un límite de ejecución, un cold start inesperado o una pesadilla de debugging. Las arquitecturas serverless y edge no son magia — son herramientas con trade-offs específicos, y en 2026 el mercado está lo suficientemente maduro para tener opiniones informadas.

El mercado en números

El mercado de plataformas serverless llegó a $16.42 mil millones en 2026, con un CAGR de 20.4% según The Business Research Company. No es una burbuja — es adopción real de empresas que cambiaron su infraestructura porque los números cerraban.

Lo que impulsa este crecimiento no es solo "es más barato" (que a veces lo es) sino el cambio de paradigma: en lugar de aprovisionar servidores y preocuparse por capacidad, escalas desde cero hasta global sin pensar en ello. Pero hay una diferencia enorme entre serverless tradicional (AWS Lambda) y edge computing (Cloudflare Workers, Deno Deploy), y confundirlos es un error costoso.

Serverless vs Edge: no son lo mismo

La distinción clave es dónde se ejecuta el código.

Serverless tradicional (AWS Lambda, Google Cloud Functions): tu código corre en regiones específicas de la nube. El proveedor escala los contenedores por ti. Cold starts de 200ms-1s. Límite de 15 minutos de ejecución. Ideal para APIs, procesamiento por lotes, tareas asíncronas.

Edge computing (Cloudflare Workers, Vercel Edge Functions, Deno Deploy): tu código corre en decenas o cientos de data centers distribuidos geográficamente, cerca del usuario. Cold starts de microsegundos a milisegundos. Límite de 10-50ms de CPU por request. Ideal para personalización, redirecciones, renderizado en edge, A/B testing.

La confusión nace de que Vercel y Netlify ofrecen ambas cosas bajo el mismo techo y las llaman "Edge Functions", pero el runtime y los límites son diferentes. No es lo mismo una Vercel Edge Function (corre en V8, límite de 30s, cold start ~50ms) que una Serverless Function (corre en Node.js, límite de 900s, cold start ~500ms).

Marco de decisión rápido

Pregúntate esto:

1. ¿Dónde están tus usuarios? Si están concentrados en una región, una función serverless tradicional en esa región funciona bien. Si son globales, el edge importa.
2. ¿Qué hace tu función? Si lee/escribe en una base de datos, necesitas serverless (o una base de datos cerca del edge, que añade complejidad). Si transforma datos en tránsito o hace llamadas a APIs, el edge funciona.
3. ¿Cuánto tiempo ejecuta? ¿Más de 50ms de CPU? Necesitas serverless. ¿Menos? Edge puede funcionar.
4. ¿Qué tan sensible es tu app a la latencia? El comercio electrónico, dashboards en tiempo real y contenido personalizado se benefician del edge. Los paneles de administración y herramientas internas no.

Benchmarks reales de 2026

Gracias a varias comparativas publicadas este año (ProPicked, daily.dev, Zylos Research), tenemos datos concretos para comparar plataformas edge en 2026:

Cloudflare Workers:

• Tiempo de respuesta promedio (p50): ~5ms
• Cold starts: sub-milisegundo (usan isolate reuse)
• Costo: $0.11 por 1,000 solicitudes (plan gratuito: 100,000 solicitudes/día)
• Ideal para: middleware global, rewrites, personalización, APIs de alto throughput

Deno Deploy:

• Tiempo de respuesta promedio: ~15ms
• Cold starts: ~5ms
• Ideal para: aplicaciones TypeScript/ESM nativas, WebSocket, compatibilidad con APIs web

Vercel Edge Functions:

• Tiempo de respuesta promedio: ~25ms (con cold start ~50ms)
• Límite: 30s de ejecución, 4MB de memoria
• Ideal para: renderizado de páginas en edge, data fetching, middleware de Next.js

La ventaja de rendimiento de Cloudflare Workers en cold starts no es marginal — es dramática. Mientras que Lambda@Edge puede tardar 500ms-1s en un cold start, Cloudflare Workers lo hace en menos de 1ms. En una aplicación que recibe tráfico global con patrones impredecibles, esa diferencia transforma la experiencia del usuario.

Pero aquí está el trade-off que nadie menciona: los Workers de Cloudflare no tienen acceso al sistema de archivos, no pueden abrir sockets TCP directos, y el límite de CPU por solicitud es de 50ms. Si necesitas hacer una conexión a una base de datos SQL o procesar un archivo pesado, no puedes hacerlo en un Worker. Necesitas Lambda o una función serverless tradicional.

Comparativa de costos a escala

Son estimaciones aproximadas solo de costo de cómputo. La transferencia de datos, almacenamiento y otros servicios se suman a la factura. Pero el patrón es claro: Cloudflare Workers es lo más barato y rápido para cargas de trabajo edge, mientras que Lambda te da la mayor flexibilidad a un costo de latencia más alto.

Casos de uso reales

Lo que funciona excelente en edge:

• Redirecciones y rewrites condicionales (geo-IP, A/B testing, feature flags)
• Autenticación y autorización en el borde de la red
• Personalización de contenido basada en ubicación o dispositivo
• API Gateway con rate limiting y caching inteligente
• Renderizado parcial de páginas (partial hydration, streaming SSR)

Lo que NO funciona bien en edge:

• Conexiones largas a bases de datos
• Procesamiento intensivo de CPU (transformación de imágenes, PDFs)
• Operaciones que requieren más de 50ms de CPU
• Dependencias con bindings nativos (compilados para Linux x86_64)

Arquitectura híbrida (la que realmente funciona): Muchos equipos en 2026 están adoptando un modelo híbrido: edge para el middleware (enrutamiento, autenticación, personalización) y serverless tradicional para la lógica de negocio pesada (APIs, procesamiento, escritura en base de datos). No es elegante ni "puro edge", pero funciona y escala.

Caso práctico: migración de un e-commerce

Una empresa de comercio electrónico mediana migró de VPS tradicional a una arquitectura híbrida a principios de 2026:

• Edge (Cloudflare Workers): Caching de páginas de producto, precios basados en geolocalización, A/B testing en flujos de checkout, verificación de autenticación
• Serverless (Lambda): Procesamiento de pedidos, actualización de inventario, integración con pasarela de pago, notificaciones por email

Los resultados después de tres meses: 40% de reducción en Time to First Byte (TTFB) para usuarios internacionales, 25% de ahorro en costos de infraestructura, y cero caídas durante un pico de tráfico similar al Black Friday. La migración no fue trivial — el equipo dedicó unas 3 semanas a reescribir middleware y ajustarse a las limitaciones de Workers — pero el ROI se materializó dentro del primer trimestre.

WebAssembly y el futuro del edge computing

WebAssembly (Wasm) es la tecnología que más me emociona en este espacio. Zylos Research reporta que los runtimes Wasm ya logran cold starts sub-milisegundo, y plataformas como Fastly Compute y Fermyon Spinoff están compitiendo directamente con Cloudflare Workers usando Wasm.

La promesa: escribir en Rust, Go, C, Python o TypeScript, compilar a Wasm y ejecutar en edge con rendimiento nativo y cold starts imperceptibles. En 2026, esto ya no es experimental — es producción.

Cloudflare anunció soporte mejorado para Wasm en Workers. Deno Deploy usa V8 que también ejecuta Wasm. La convergencia hacia un runtime universal basado en Wasm es la dirección más probable para los próximos años. Esto importa porque resuelve el problema de "¿puedo ejecutar mi lenguaje favorito en el edge?" Ya no estarás limitado a JavaScript para funciones edge.

Lo que aún necesita mejorar

Wasm en el edge es prometedor pero no perfecto. Debugging es más difícil — pierdes source maps y stack traces. Las herramientas están mejorando pero todavía están detrás del desarrollo nativo en JavaScript/V8. Y el ecosistema de librerías Wasm para tareas comunes (clientes HTTP, parsing JSON, criptografía) todavía es escaso comparado con npm.

Si estás construyendo un proyecto nuevo y tu equipo se siente cómodo con Rust o Go, Wasm en el edge vale la pena explorarlo. Si necesitas moverte rápido con JavaScript, quédate con Workers o Edge Functions por ahora.

El cambio hacia cero-infraestructura

El objetivo final tanto del serverless como del edge computing es lo que llamo "cero-infraestructura" — escribes código, lo despliegas, y la plataforma se encarga de todo lo demás. En 2026, estamos más cerca de esa visión que nunca. Functions as a Service (FaaS) ha madurado, los runtimes edge se han vuelto mainstream, y los vacíos restantes (persistencia de estado, tareas de larga duración, debugging) se están resolviendo activamente.

La conclusión práctica: no pienses demasiado la decisión de arquitectura. Empieza con lo que te lleve más rápido al mercado. Si lo superas, el camino de migración a un modelo diferente está bien documentado. El costo de migrar después es menor que el costo de sobre-ingenierizar tu arquitectura inicial para un caso extremo que quizás nunca enfrentes.

Entonces, ¿serverless, edge o ambos?

La respuesta aburrida es "depende", pero aquí hay heurísticas prácticas:

• Si tu aplicación es una API REST o GraphQL: usa serverless tradicional (Lambda, Fly.io, Render). El edge no te da ventajas significativas y te limita.
• Si tu aplicación es un sitio público con contenido dinámico: edge functions para el renderizado y middleware, serverless para las APIs internas.
• Si tu aplicación es global con usuarios en múltiples continentes: edge es casi obligatorio para mantener tiempos de respuesta aceptables sin replicar tu backend.
• Si estás en el ecosistema Next.js: las Vercel Edge Functions son la opción natural, pero revisa si realmente necesitas edge o te alcanza con ISR y serverless functions.

El mercado sigue convergiendo. AWS anunció mejoras en Lambda@Edge que reducen cold starts. Cloudflare agregó Workers AI para inferencia en edge. Vercel está invirtiendo en su Edge Runtime. En 2027, la distinción entre edge y serverless probablemente sea irrelevante porque ambas serán parte del mismo espectro. Escribirás código y la plataforma decidirá dónde ejecutarlo según latencia, costo y capacidad.

Si estás evaluando una migración de infraestructura, te recomiendo empezar por medir tu tráfico actual, identificar dónde están los cuellos de botella, y elegir la herramienta para el problema específico — no la tecnología de moda. Las empresas que obtienen los mejores resultados del edge computing son las que empezaron con un problema claro, no las que lo adoptaron porque sonaba cool.

Para profundizar, lee sobre arquitectura web componible, Core Web Vitals en 2026, y conoce nuestros servicios de diseño y desarrollo web.