De CDN a plataforma
La historia de Cloudflare: de una red que aceleraba y protegia sitios web a una plataforma que ejecuta aplicaciones enteras en el borde. Por que la red vino primero y el compute despues.
Cloudflare no nació como una plataforma de cómputo: nació como una CDN que aceleraba y protegía páginas web. Entender ese origen no es una curiosidad histórica, es la clave para comprender por qué hoy puedes ejecutar una aplicación entera en su red. El compute llegó al final de un camino que empezó con caché, DNS y defensa contra ataques. La plataforma que vas a aprender es la consecuencia lógica —casi inevitable— de esa historia, y conocerla te ahorra memorizar decisiones que en realidad se explican solas.
- Reconstruir la evolución de Cloudflare, de CDN a plataforma de aplicaciones.
- Entender por qué la red global tuvo que existir antes que el compute.
- Situar el momento en que aparecen los Workers y qué cambió con ellos.
- Ver la plataforma actual como el desenlace natural de su origen.
El origen: acelerar y proteger
Cloudflare arrancó en 2010 con una idea simple y poderosa: colocar una red de proxies inversos entre los visitantes y los servidores de origen. En lugar de que cada usuario del planeta hablara directamente con tu servidor —a menudo lejano y frágil—, hablaba con la ubicación de Cloudflare más cercana, que cacheaba, filtraba y reenviaba lo necesario.
La propuesta de valor era que un sitio fuera más rápido y más seguro sin tocar su código. Bastaba apuntar el DNS a Cloudflare y, de golpe, tu web viajaba por una red optimizada. Sobre ese proxy se construyeron los primeros productos:
CDN y caché
Servir imágenes, CSS y HTML estático desde la ubicación más próxima al usuario, descargando al origen y recortando el tiempo de respuesta.
DNS
Un DNS autoritativo rapidísimo; en 2018 llegó el resolver público 1.1.1.1, uno de los más veloces del mundo.
DDoS y WAF
Absorber ataques de denegación de servicio y filtrar tráfico malicioso antes de que tocara tu servidor de origen.
TLS gratis
Cifrado HTTPS universal y gratuito, cuando aún era caro y engorroso de configurar a mano.
El detalle decisivo: para ofrecer todo esto, Cloudflare tuvo que desplegar máquinas en cientos de ciudades y mantenerlas siempre encendidas y coordinadas. Sin saberlo todavía, estaba construyendo el sustrato físico de una plataforma de cómputo global.
Una capa gratuita generosa no era caridad: era la forma de conseguir millones de dominios y, con ellos, tráfico en todas las regiones del planeta. Ese tráfico justificaba instalar máquinas en cada vez más ciudades, y esa densidad —imposible de replicar deprisa— es hoy el activo sobre el que corre todo el compute. La estrategia comercial y la arquitectura crecieron juntas.
El giro: de servir a ejecutar
Durante años, esa red solo hacía dos cosas con una petición: responder desde la caché o reenviarla al origen. Era un proxy potente, pero pasivo. En 2017 llegó el salto conceptual con Cloudflare Workers: en lugar de servir bytes guardados, la red pasó a ejecutar tu propio código en cada ubicación.
La decisión técnica que lo hizo viable fue no usar contenedores ni funciones tipo lambda, sino isolates de V8: espacios aislados dentro de un proceso ya en marcha, que arrancan en cero milisegundos.
// El primer tipo de codigo que Cloudflare dejo ejecutar en su red:
// una funcion que intercepta cada peticion en el PoP mas cercano.
export default {
async fetch(request) {
return new Response("Hola desde el edge");
},
};Ese fetch es el mismo modelo que usará toda la plataforma: recibe una Request, devuelve una Response, y corre allí donde esté el usuario. La red dejó de ser un cartero para convertirse en un ordenador programable repartido por el mundo.
El salto se resume en qué podía hacer la red al recibir una petición:
- Antes (CDN): responder desde la caché, o reenviar al origen. Dos opciones, ambas pasivas.
- Después (Workers): ejecutar tu código y decidir la respuesta —autenticar, transformar, componer, llamar a datos o a IA— en el propio PoP, sin ida y vuelta al origen.
La red ya corría un proceso compartido en miles de máquinas para hacer de proxy. Meter un contenedor o una máquina virtual por cliente habría sido carísimo en memoria y en arranque. Un isolate, en cambio, es barato: miles caben en el mismo proceso y arrancan al instante. La herencia de CDN —una flota siempre caliente— es justo lo que hizo posible un compute sin cold starts. La historia condicionó la arquitectura, no al revés.
Workers toma su nombre de los Web Workers del navegador, la API que ejecuta JavaScript en segundo plano. La elección delata la filosofía: en vez de inventar un entorno propietario, Cloudflare abrazó las APIs web estándar —fetch, Request, Response, streams— para que el mismo modelo mental del navegador valiera en el servidor. Esa decisión, tomada al principio, es la razón de que hoy portar código entre el navegador y el edge sea tan natural.
La plataforma completa
Una vez que el código corría en el borde, faltaba lo demás. Poco a poco, Cloudflare llevó cada pieza de una aplicación a esa misma red, hasta que una app full-stack entera cupo en un solo proyecto:
flowchart LR A[2010 CDN y DNS] --> B[2014 TLS y DDoS] B --> C[2017 Workers] C --> D[2021 R2 y Pages] D --> E[2023 Workers AI] E --> F[2026 Workers como centro] style A fill:#89b4fa,color:#11111b style C fill:#fab387,color:#11111b style F fill:#a6e3a1,color:#11111b
- Almacenamiento que vive junto al compute: KV para lecturas globales, R2 para objetos sin cargos de egress, D1 como base SQLite, y Durable Objects para estado coordinado.
- Colas y orquestación con Queues y Workflows, para trabajo asíncrono sin un servidor que lo lance.
- Inteligencia artificial en la propia red con Workers AI y Vectorize, para inferencia y búsqueda semántica cerca del usuario.
Visto en conjunto, las cuatro patas de cualquier aplicación moderna encontraron su sitio en el edge:
Frontend
Los assets estáticos y el SSR se sirven desde el propio Worker, sin un hosting aparte.
Backend
La lógica corre en Workers, cerca del usuario, sin servidor que aprovisionar ni mantener.
Datos
KV, R2, D1 y Durable Objects ponen el almacenamiento en la misma red, accesible por bindings.
IA
Workers AI y Vectorize añaden inferencia y búsqueda semántica sin salir de la plataforma.
Que compute, datos e IA compartan runtime, despliegue y facturación no es un detalle: es lo que separa una plataforma de un catálogo de servicios sueltos. No pegas piezas de proveedores distintos con credenciales y colas de red entre ellas; declaras bindings y todo se habla dentro de la misma red. Esa cohesión nació de tenerlo todo en la misma flota de máquinas.
Puestas en el tiempo, las incorporaciones dibujan una lógica clara, no una lista de productos al azar:
- 2017 a 2019: compute con Workers y las primeras piezas de estado, KV y Durable Objects.
- 2021: almacenamiento serio con R2 sin egress y despliegue de sitios con Pages.
- 2022 a 2023: datos relacionales con D1, colas con Queues e IA con Workers AI y Vectorize.
- 2024 a 2026: consolidación, con la paridad de Workers y Pages y todo bajo un mismo modelo.
Por qué el orden importa
La lección profunda de esta historia es que el compute en el edge no se diseñó desde cero: se injertó sobre una red que ya existía. Cloudflare pasó una década construyendo una flota global de máquinas siempre encendidas para acelerar y proteger sitios. Cuando decidió ejecutar código, no tuvo que levantar centros de datos ni pagar arranques en frío: ya tenía procesos calientes en cientos de ciudades, esperando peticiones. Por eso pudo elegir isolates —baratos y sin cold start— en lugar de contenedores, y por eso desplegar un Worker significa colocarlo en toda la red a la vez, no en una región. Otras nubes hicieron el camino inverso: primero regiones de servidores enormes, y luego intentaron acercarse al usuario con capas de caché encima. Cloudflare partía ya de estar cerca de todo el mundo, y solo tuvo que enseñarle a esa cercanía a ejecutar tu lógica. Comprender esto explica casi todas las decisiones de la plataforma que verás más adelante: el modelo de precios sin cargos por arranque, la ausencia de cold starts, los bindings en vez de cadenas de conexión con secretos, y la obsesión por que los datos también vivan en el borde. Ninguna de esas piezas es arbitraria; todas descienden del mismo hecho fundacional. El edge de Cloudflare no es una nube que se acercó al usuario: es una red cercana al usuario que aprendió a computar. Si retienes una sola idea de esta lección, que sea esa, porque desde ella se deduce casi todo lo demás.
Con este mapa histórico en la cabeza, las próximas lecciones dejan de ser una lista de novedades y se vuelven un solo relato: qué es esa red, por qué la cercanía importa tanto, y en qué se diferencia de la nube que ya conoces.
Y todo ese recorrido de quince años desemboca en algo que hoy cabe en tres líneas: crear, desarrollar y desplegar sobre la red global que tardó una década en construirse.
npm create cloudflare@latest mi-worker
cd mi-worker
npx wrangler deploy- Ordena mentalmente los hitos: CDN, TLS, Workers, R2, Workers AI. Fíjate en qué es red y qué es compute.
- Piensa en un producto clásico de Cloudflare que uses o conozcas (caché, DNS, DDoS) y razona cómo prepara el terreno para ejecutar código.
- Explica en una frase por qué la herencia de CDN permite que los Workers no tengan cold start.
- Anota una pregunta que te haya surgido sobre el edge; la resolverás en las próximas lecciones del nivel.