Kubernetes vs Cloudflare Workers: ¿Cuándo usar qué?

El dilema de la infraestructura moderna

Elegir entre Kubernetes y Cloudflare Workers no es una decisión de mejor o peor: es una decisión de adecuación al problema. Ambas tecnologías son extraordinariamente capaces dentro de sus dominios, pero tienen modelos de ejecución, casos de uso y compromisos radicalmente diferentes. Entender estas diferencias te ahorrará semanas de reingeniería costosa.

Modelo de ejecución: contenedores vs funciones

Kubernetes es un orquestador de contenedores. Tu aplicación corre en Pods —uno o más contenedores— que se ejecutan en nodos de cómputo bajo tu control o en un servicio gestionado como GKE, EKS o AKS. El modelo es stateful: los procesos persisten, pueden mantener conexiones de larga duración, acceder a memoria local y escribir en disco.

Cloudflare Workers opera en un paradigma completamente diferente: el Edge Computing. Cada request se despacha a uno de los más de 300 puntos de presencia de Cloudflare globalmente, donde se ejecuta un worker aislado basado en el motor V8 de Chrome. El runtime es extremadamente liviano (sin Node.js, sin sistema operativo completo), lo que permite arrancar en menos de 1 milisegundo.

La diferencia de latencia es dramática. Un Worker ejecutándose a 5ms del usuario final siempre ganará a un servidor Kubernetes ejecutándose en us-east-1 a 150ms de distancia, sin importar cuánto optimices el código.

Límites y restricciones técnicas

Cloudflare Workers impone restricciones importantes que debes conocer:

• Tiempo de ejecución máximo: 30 segundos por request en el plan pago (Workers Paid)
• Memoria: 128MB por worker
• Tamaño del bundle: 10MB comprimido
• Sin acceso a filesystem: No puedes escribir archivos locales
• APIs de Node.js limitadas: No todas las APIs de Node.js están disponibles; el runtime es un subconjunto del estándar web
• Sin WebSockets de larga duración sin Durable Objects (que tienen su propio costo)

Kubernetes no tiene estas restricciones. Un Pod puede ejecutar procesos de días de duración, consumir cientos de GB de RAM, acceder a GPUs, montar volúmenes persistentes y usar cualquier binario del sistema operativo.

Gestión de estado

Este es el punto donde más equipos se equivocan. Los Workers son fundamentalmente sin estado entre requests. Para persistir datos necesitas:

• KV Store: Almacenamiento clave-valor con consistencia eventual, ideal para configuración y caché
• R2: Almacenamiento de objetos compatible con S3 para archivos y blobs
• D1: Base de datos SQLite distribuida para datos estructurados (latencia variable)
• Durable Objects: Estado coordinado y con garantías de consistencia fuerte

Kubernetes puede conectarse a cualquier base de datos o sistema de almacenamiento: PostgreSQL, MySQL, Redis, Cassandra, sistemas de archivos NFS, etc. La gestión de estado con Kubernetes es más compleja de operar pero infinitamente más flexible.

Costos: ¿qué escala mejor?

El modelo de costos es radicalmente diferente. Cloudflare Workers en el plan gratuito ofrece 100.000 requests diarias sin costo alguno. El plan Workers Paid cuesta $5/mes e incluye 10 millones de requests adicionales a $0.30 por millón. Para la mayoría de aplicaciones de tráfico moderado, Workers es significativamente más económico.

Kubernetes requiere pagar por los nodos aunque no haya tráfico. Un clúster mínimo viable en GKE o EKS cuesta entre $150 y $400 mensuales solo en infraestructura de control plane y nodos básicos. El costo escala con el número de nodos, tipo de instancia, almacenamiento y transferencia de datos.

Sin embargo, a escala muy alta (millones de requests por hora con procesamiento intensivo), Kubernetes puede ser más económico porque pagas por cómputo fijo en lugar de por request.

Casos de uso donde gana Cloudflare Workers

1. **APIs de baja latencia globales**: Respuestas que deben ser ultrarrápidas para usuarios en todo el mundo
2. **Lógica de routing y middleware**: Modificar requests/responses antes de llegar al origen
3. **Generación de contenido dinámico simple**: HTML, JSON, redirecciones basadas en geolocalización
4. **Rate limiting y autenticación edge**: Filtrar tráfico malicioso antes de que llegue a tu infraestructura
5. **A/B testing y feature flags**: Servir variantes diferentes sin tocar el servidor de origen
6. **Bots y scrapers simples**: Tareas cortas de recolección de datos

Casos de uso donde gana Kubernetes

1. **Aplicaciones monolíticas o de microservicios complejos**: Sistemas con muchas dependencias entre servicios
2. **Procesamiento de largo tiempo**: Transcoding de video, análisis de datos, entrenamiento de modelos
3. **Aplicaciones con estado complejo**: Sistemas que requieren bases de datos con ACID y transacciones
4. **Workloads con GPUs**: Inferencia de IA, renderizado 3D, procesamiento de imágenes
5. **Aplicaciones legacy containerizadas**: Migración de aplicaciones existentes sin reescritura
6. **Control total sobre el stack**: Compliance estricto que requiere datos en regiones específicas

La arquitectura híbrida: lo mejor de ambos mundos

La decisión no tiene que ser excluyente. La arquitectura más sofisticada combina ambas: Cloudflare Workers actúa como capa de acceso global (autenticación, rate limiting, caché, enrutamiento geográfico) y redirige las solicitudes que requieren procesamiento complejo a un clúster Kubernetes en la región más apropiada.

Esta arquitectura reduce significativamente la carga en los servidores de origen, mejora la latencia para operaciones simples y mantiene la flexibilidad para workloads complejos. Empresas como Shopify, Discord y Cloudflare misma usan variaciones de este patrón.

Conclusión

Elige Cloudflare Workers cuando necesitas baja latencia global, simplicidad operacional y costos predecibles para workloads sin estado. Elige Kubernetes cuando necesitas flexibilidad máxima, gestión de estado compleja, procesamiento intensivo o control total sobre tu infraestructura. Y considera combinar ambos cuando tu escala y complejidad lo justifiquen.