Kubernetes o PaaS: qué elegir para un producto SaaS
Kubernetes y PaaS resuelven problemas distintos. El error habitual es decidir por prestigio técnico antes de saber qué necesita realmente el producto SaaS.
Si Vercel, Render, Fly.io, Heroku o Cloud Run cubren el 80% del caso, operar menos puede ser una ventaja. Kubernetes empieza a compensar cuando la plataforma interna ya forma parte del producto.
La decisión que muchos equipos adelantan demasiado
Kubernetes es potente, pero no es gratis en terminos operativos. Un PaaS puede parecer menos flexible, pero permite concentrarse en producto cuando el equipo aun es pequeno.
PaaS si Vercel, Render o Heroku resuelven el 80%
- Equipo reducido sin plataforma interna.
- Producto en validación o crecimiento inicial.
- Necesidad de despliegues simples y soporte rapido.
- Cargas web convencionales.
- Poca necesidad de control profundo de red o runtime.
Kubernetes cuando la plataforma ya es producto interno
- Multiples servicios con patrones de despliegue distintos.
- Necesidad de portabilidad o control de infraestructura.
- Equipo con experiencia real en operación.
- Requisitos avanzados de red, autoscaling o aislamiento.
- Costes PaaS ya justifican invertir en plataforma propia.
Costes ocultos
Kubernetes implica observabilidad, seguridad, upgrades, gestión de secretos, politicas, networking y guardias. EKS, AKS y GKE reducen parte del trabajo, pero no eliminan decisiones sobre ingress, Helm, backups, permisos y costes. Si nadie posee esas tareas, el cluster se convierte en deuda operativa.
Ejemplo real: Vercel para web, Kubernetes para servicios internos
Un SaaS puede mantener el frontend en Vercel y mover workers o servicios internos a Kubernetes solo cuando aparecen necesidades claras de colas, jobs, networking o control de runtime. Elegir todo Kubernetes desde el primer dia puede retrasar producto sin mejorar al usuario.
La decisión de compra no debe depender de la demo
La compra deberia avanzar solo si el equipo puede defender tres puntos: que problema economico resuelve, que coste operativo introduce y que salida existe si la herramienta o arquitectura deja de encajar. En devops, una comparativa util no busca un ganador absoluto; busca reducir arrepentimiento despues de firmar.
Cuándo la complejidad empieza a compensar
Kubernetes empieza a tener sentido cuando el equipo necesita control fino de red, jobs, servicios internos, despliegues multi-tenant o portabilidad entre entornos. Si el problema principal sigue siendo validar producto, un PaaS suele comprar tiempo.
La señal de alerta aparece cuando nadie quiere ser dueño del clúster. Sin guardias, actualizaciones, políticas, observabilidad y seguridad, Kubernetes deja de ser plataforma y se convierte en deuda operativa.
- Elige PaaS si el equipo necesita velocidad y operación baja.
- Elige Kubernetes si la plataforma requiere control sostenido y hay equipo para mantenerlo.
- No migres por moda: migra cuando el límite actual sea claro y medible.
Criterios de decisión para un SaaS real
La pregunta no es si Kubernetes es “mejor” que un PaaS. La pregunta es qué problema operativo tienes hoy y qué coste estás dispuesto a asumir para resolverlo. Un SaaS temprano suele necesitar velocidad, despliegues simples y poca carga de infraestructura. Un SaaS maduro puede necesitar aislamiento por cliente, jobs pesados, red interna compleja, cumplimiento o control fino de costes.
| Situación | PaaS suele encajar | Kubernetes empieza a compensar |
| --- | --- | --- |
| Equipo | 2-6 ingenieros sin plataforma dedicada | Equipo con experiencia SRE o plataforma |
| Producto | Web app, API y workers sencillos | Muchos servicios, colas, jobs y tenants |
| Operación | Prioridad en desplegar rápido | Prioridad en control, políticas y portabilidad |
| Coste | Se acepta pagar margen por simplicidad | El volumen permite optimizar infraestructura |
| Riesgo | La caída se gestiona con proveedor y rollback | Se necesitan controles internos avanzados |
Vercel, Render, Fly.io, Heroku o Google Cloud Run pueden ser decisiones excelentes cuando reducen operación. Kubernetes aporta valor cuando el equipo ya sufre límites concretos: despliegues multi-servicio, configuración repetida, aislamiento entre clientes, requisitos de red, jobs programados o entornos complejos.
Ejemplo concreto: SaaS B2B con API, web y workers
Imagina un SaaS B2B con frontend en Next.js, API en Node, PostgreSQL, Redis, workers de BullMQ y tareas programadas. En una fase inicial, Vercel para frontend, Render o Fly.io para API y workers, y una base gestionada pueden cubrir el caso con menos fricción. El equipo se concentra en producto, soporte y ventas.
El salto a Kubernetes tendría sentido si aparecen señales claras: clientes enterprise piden entornos aislados, los workers necesitan escalado fino por cola, hay servicios internos con dependencias específicas, se requiere una política de red avanzada o el gasto en PaaS ya supera el coste de operar plataforma propia. Sin esas señales, el cambio puede ser una distracción cara.
Errores comunes
El primer error es adoptar Kubernetes para parecer más serio. Un clúster no mejora el producto si nadie quiere ser responsable de upgrades, ingress, certificados, políticas, observabilidad, backups y seguridad.
El segundo error es quedarse demasiado tiempo en un PaaS sin mirar límites. Si cada despliegue exige workarounds, si los logs no bastan, si las colas se quedan cortas o si el proveedor no permite aislar clientes como exige ventas enterprise, la simplicidad inicial puede volverse bloqueo.
El tercero es no calcular el coste humano. Kubernetes no es solo nodos. Incluye tiempo de guardia, incidentes, actualizaciones, hardening, Helm charts, secretos, monitorización y documentación interna. Si ese trabajo cae sobre el mismo equipo que debe construir producto, el coste real sube rápido.
Señales para migrar sin precipitarse
Una migración a Kubernetes debería tener una razón escrita y medible. Por ejemplo: reducir coste de ejecución un 30% con cargas estables, aislar tenants regulados, unificar despliegues de diez servicios o controlar tráfico interno con políticas claras. “Nos queda pequeño el PaaS” es una intuición; hay que convertirla en evidencia.
Antes de migrar todo, prueba una carga no crítica: un worker intensivo, un servicio interno o un entorno de staging. Mide tiempo de despliegue, complejidad de observabilidad, coste mensual, calidad de rollback y carga del equipo. Si el piloto empeora velocidad sin resolver un problema fuerte, la migración no está madura.
Decisión práctica
Elige PaaS si el negocio necesita iterar, el equipo es pequeño y las cargas son estándar. Elige Kubernetes si ya hay complejidad operativa que el PaaS no puede absorber y existe capacidad real para mantener plataforma.
La opción intermedia también existe: frontend en Vercel, bases gestionadas, workers en Cloud Run o ECS Fargate, y Kubernetes solo para servicios que lo justifican. En SaaS, una arquitectura híbrida prudente suele ganar a una migración total hecha por orgullo técnico.
Coste operativo que suele olvidarse
El coste visible de Kubernetes son nodos, almacenamiento, balanceadores y tráfico. El coste menos visible es la plataforma humana: guardias, actualización del clúster, revisión de imágenes, políticas de red, gestión de secretos, backups de configuración, dashboards y documentación para que el resto del equipo despliegue sin depender de una persona.
En un PaaS, parte de ese coste está incluido en el margen del proveedor. En Kubernetes, vuelve al equipo. Eso puede ser positivo si hay escala y experiencia; puede ser destructivo si el equipo aún está buscando encaje de producto.
Una forma práctica de decidir en comité técnico
Lleva a la reunión tres escenarios con números: mantener PaaS seis meses, migrar solo workers o migrar toda la plataforma. Para cada escenario, estima coste mensual, tiempo de migración, riesgo de interrupción, impacto en velocidad de producto y quién lo operará.
Si nadie puede comprometerse a operar Kubernetes durante los próximos doce meses, la respuesta todavía no es Kubernetes. Si el PaaS bloquea contratos enterprise o dispara costes con cargas estables, entonces merece una prueba limitada y medible.
Preguntas para cerrar la decisión
Antes de cerrar arquitectura, conviene responder quién mantiene despliegues fuera de horario, cómo se gestionan secretos, qué ocurre si falla una migración y cuánto tarda un rollback completo. Si esas respuestas dependen de una sola persona, la plataforma elegida todavía tiene riesgo operativo.
