Cloud y DevOps para PyMEs: infraestructura escalable sin sobre-ingeniar

La conversación sobre infraestructura cloud suele empezar mal. Alguien dice "Kubernetes", alguien más dice "microservicios", y a la semana hay un diagrama con 17 cajas que nadie sabe cómo mantener. Mientras tanto, el negocio sigue con 50 clientes y un servidor que se cae los lunes.

Hablemos de infraestructura real para empresas reales.

La trampa de la pre-optimización

Donald Knuth lo dijo en los 70 y sigue siendo cierto: optimizar antes de tiempo es la raiz de todo mal en software. En infraestructura es peor, porque además te cobran por mes. Toda capacidad que aprovisionaste sin necesitarla es plata que ya gastaste y no recuperas.

La pregunta correcta al arrancar no es "como escalo a un millon de usuarios". Es "como hago para no caerme con los 100 primeros, y cómo hago para que escalar al millon sea posible cuando llegue ese momento, sin reescribir todo".

Lo que necesita una pyme real

Mirando los proyectos que llevamos adelante, el stack que usamos en la gran mayoría es bastante boring (en el buen sentido):

• Frontend y rendering server-side: Vercel para deploy, con Next.js. La razón es simple: cero configuración para empezar, escalado automático, edge en LATAM, y el costo arranca en USD 0 hasta cierto volumen.
• Base de datos y backend básico: Supabase. Postgres serio con interfaz amigable, auth incluida, storage, y row level security para multi-tenant. Es lo más cercano a "Firebase pero con SQL".
• Storage de archivos pesados: Cloudinary o S3 directo, dependiendo del caso.
• Observabilidad mínima: Vercel Analytics + Sentry para errores. Datadog y la familia entera vienen después.
• CI/CD: GitHub Actions. Gratis hasta volumenes que el 95% de las pymes no van a pasar nunca.

Eso es todo. Ningún cluster de Kubernetes, ninguna malla de servicios, ningún ingress controller. Y aguanta cientos de miles de requests sin transpirar.

El caso Tontin: cuándo si hace falta complejidad

Hay momentos donde la infraestructura simple no alcanza. Tontin, nuestra plataforma de coaching con IA, es uno. Ahí tenés problemas que un Vercel + Supabase no resuelven solos:

• Llamadas a múltiples proveedores de IA con fallback automático si uno se cae (Groq, Gemini, OpenAI, Anthropic). Eso requiere una capa propia de orquestación.
• Búsqueda semántica con embeddings. Resuelto con pgvector dentro del mismo Postgres de Supabase, lo que evita meter Pinecone o Weaviate y simplifica la infraestructura.
• Compresión de contexto entre sesiones para mantener memoria persistente sin disparar costos de tokens. Una capa intermedia que escribimos en TypeScript reduce el contexto un 50% antes de cada llamada.
• Más de 500 conversaciones completadas que se sirvieron desde esa arquitectura sin downtime.

El punto: la complejidad se agrega cuando el negocio la pide, no cuando el diagrama queda más lindo.

Cuándo si pasar a Kubernetes (la respuesta es: casi nunca todavía)

La regla operativa: si no sabes con certeza por qué necesitas Kubernetes, no lo necesitas. Las pocas razones legítimas:

• Tenés más de 10 servicios independientes que se actualizan a ritmos distintos.
• Tu volumen de tráfico justifica múltiples nodos y orquestación (estamos hablando de miles de requests por segundo sostenidos).
• Tu equipo de DevOps tiene experiencia probada operando clusters. Esto es lo más importante: un Kubernetes mal operado es peor que un servidor monolítico bien cuidado.

Para una pyme típica con 1-3 productos y tráfico medible en cientos de requests por minuto, Vercel + Supabase + un par de servicios serverless cubre todo, cuesta una fracción, y se mantiene con un solo developer.

Observabilidad: lo mínimo que no podés saltearte

Hay tres cosas que si o si tienen que estar desde el día uno, aunque el resto sea minimalista:

1. Logs accesibles. Si no podés ver qué pasó cuando algo falla, estás a ciegas. Vercel y Supabase los tienen incluidos.
2. Alertas de errores críticos. Sentry gratis cubre la mayoría de los casos. La regla: si un error afecta a un usuario en producción, alguien lo tiene que saber en menos de 5 minutos.
3. Métricas de uso. Cuantos usuarios activos, qué páginas, qué conversiones. GA4 + Vercel Analytics. Sin esto, cualquier decisión de optimización es a dedo.

La regla final

Empezas simple. Medis. Cuando algo no escala, lo optimizas. Cuando algo se cae mucho, lo refactorizas. Pero no agregas complejidad por anticipación. Cada caja extra en el diagrama es una caja más que se puede romper, y un costo más en el AWS bill.

Si estás armando infraestructura nueva o ya tenés algo que se cae cuando no debe, escribinos. Auditamos el setup actual y te decimos dónde estás pagando de más o dónde tenés un riesgo escondido.

---

Por Esteban Aleart, Founder & Lead Engineer de Pair Programming.