15. Cuándo no usar Cloudflare

Después de catorce capítulos contando lo que me funciona, toca lo contrario. Cloudflare es mi opción por defecto para proyectos personales y de I+D, pero no para todo. Estos son los casos en los que elegiría otra cosa, con el porqué y la alternativa.

Para quién es

Para quien está decidiendo la plataforma de un proyecto nuevo o se pregunta si llevar uno existente a Cloudflare.

Al terminar tendrás los casos en los que yo elegiría otra cosa, cuánta dependencia del proveedor asumes con cada pieza y una lista de comprobación para pasar de la idea a producción.

Cuándo elegiría otra cosa

flowchart TD
    A[Proyecto nuevo] --> B{¿Más de 128 MB por petición<br/>o CPU constante?}
    B -->|Sí| C{¿Cabe en un contenedor<br/>pequeño y a ratos?}
    C -->|Sí| CT[Cloudflare Containers]
    C -->|No| VM[Servidor o PaaS<br/>con máquina dedicada]
    B -->|No| D{¿Todo lo demás<br/>ya está en AWS?}
    D -->|Sí| AWS[Lambda y servicios de AWS]
    D -->|No| E{¿Base relacional<br/>grande y única?}
    E -->|Sí| PG[Workers + Hyperdrive + Postgres]
    E -->|No| CF[Workers + D1 + R2]

Containers: la salida sin salir

Cloudflare Containers ejecuta una imagen de contenedor (con Linux, más memoria y cualquier binario) controlada desde un Worker y un Durable Object. Sirve para el caso “todo me cabe en Workers menos esta pieza”. Así encajan las piezas:

flowchart LR
    P[Petición] --> W[Worker]
    W --> DO[Durable Object<br/>arranca y controla el contenedor]
    DO --> C[Contenedor<br/>Linux, más memoria, cualquier binario]

Solo está en el plan de pago y se cobra por uso:

Workers, Lambda o un servidor: comparación rápida

La comparación detallada, con costes para el mismo tráfico, está en Workers frente a Lambda (próximamente).

Cuánta dependencia del proveedor asumes

No todas las piezas atan igual. Así lo veo yo:

Lista de comprobación: de la idea a producción

Lo que reviso antes de abrir una aplicación al público, con el capítulo de cada punto:

• Dominio propio con DNSSEC y SSL en modo estricto (cap. 2).
• tsc y pruebas antes de cada despliegue (cap. 3).
• Secretos con wrangler secret put; nada en el repositorio.
• Migraciones compatibles hacia atrás y una copia exportada antes de las arriesgadas (cap. 5).
• Autorización en cada consulta, también en R2 y Vectorize.
• Trabajo pesado en colas o Workflows, con cola de mensajes muertos (cap. 7).
• SPF, DKIM y DMARC si envías correo (cap. 8).
• Turnstile en formularios públicos y limitación en el login (cap. 11).
• Logs, Issues y alertas de errores y de facturación (cap. 12).
• Límites de gasto en el código: max_tokens, max_retries, tamaños máximos (cap. 13).
• Staging y previews protegidos con Access; vuelta atrás probada (cap. 14).

Resumen

• Cloudflare para proyectos nuevos, APIs, webs, SaaS pequeños y prototipos de I+D.
• Containers para la pieza que no cabe en un Worker; otra plataforma si es la mayor parte del sistema.
• La dependencia del proveedor se concentra en Durable Objects y Workflows: úsalos donde aporten.
• Con la lista de comprobación, la aplicación de la guía está lista para producción.

Recursos

• Containers
• Compatibilidad con Node.js en Workers
• Cómo elegir dónde guardar los datos
• Workers frente a Lambda para un proyecto pequeño (próximamente)