El fin de Kubernetes?: los nuevos orquestadores serverless

Kubernetes lleva casi una década siendo la respuesta automática a cualquier pregunta sobre cómo desplegar contenedores en producción. Pero en 2026 está pasando algo curioso: una nueva generación de orquestadores serverless —AWS App Runner, Google Cloud Run, Azure Container Apps— está quitándole terreno a K8s en un número creciente de equipos, y no precisamente porque Kubernetes haya empezado a fallar.

La razón es mucho más prosaica: para una buena parte de los workloads que corren hoy en producción, Kubernetes es sencillamente más herramienta de la que se necesita. Los orquestadores serverless cubren ese mismo terreno con una fracción de la complejidad operacional, y eso está cambiando cómo muchos equipos toman esta decisión.

Qué ofrece realmente el mundo serverless

Lo que comparten App Runner, Cloud Run y Container Apps es que eliminan por completo la gestión de clusters: no hay nodes que configurar, no hay que hacer patching de sistema operativo, y el escalado ocurre solo, incluyendo el scale-to-zero cuando no hay tráfico. Pagas por lo que consumes, y todo llega integrado de forma nativa con el resto de servicios del proveedor cloud que ya usas.

Cómo ha madurado cada opción

App Runner, que AWS lanzó en 2021, ha crecido bastante desde entonces. Hoy soporta despliegues multi-contenedor, networking VPC con una configuración mucho más sencilla que antes, dominios personalizados con certificados que se gestionan solos, y deployments blue/green con rollback prácticamente instantáneo si algo sale mal.

Google Cloud Run sigue siendo, en términos de madurez, el más pulido de los tres. Permite un control muy fino sobre la concurrencia, límites de instancias para no llevarte sustos en la factura, entornos de ejecución con soporte para GPUs, y traffic splitting para hacer canary deployments sin complicarte la vida.

Azure Container Apps es el más joven del grupo —llegó en 2022— pero ha crecido rápido. Su punto fuerte es la integración con Dapr para patrones distribuidos, reglas de escalado basadas en Kafka o Redis, ingress interno para networking privado, y gestión de secretos ya conectada con Azure Key Vault.

Cuándo Kubernetes sigue siendo la respuesta correcta

Hay escenarios donde ningún orquestador serverless puede competir. Si necesitas correr el mismo workload en varios clouds a la vez, o en infraestructura on-premise, Kubernetes es prácticamente la única opción real. Lo mismo ocurre con workloads stateful complejos —bases de datos con requisitos de scheduling específicos, sistemas que necesitan storage classes a medida—, o cuando tu organización exige control total sobre cada capa de la infraestructura, desde la versión del kernel hasta el hardware específico. Y si tu escala es lo bastante grande y constante, la infraestructura reservada de un cluster propio puede acabar siendo más barata que pagar por uso.

Cuándo serverless gana claramente

Para APIs REST, GraphQL, webhooks o frontends renderizados en servidor —en general, cualquier cosa sin estado que reciba tráfico web— serverless es un ajuste casi perfecto. También es la opción lógica para prototipos y MVPs, donde no tiene sentido montar un equipo de DevOps solo para validar una idea, y para workloads con tráfico esporrádico, donde pagar por uso puede ser dramáticamente más barato que mantener infraestructura reservada las 24 horas.

El coste que no aparece en la factura del cloud

Es fácil olvidar que el coste de Kubernetes no se limita a lo que cobra el proveedor cloud. Hay que sumar el tiempo de los engineers que configuran y mantienen todo, el tooling adicional (Helm, ArgoCD, Prometheus, Grafana), la formación de cada persona que se incorpora al equipo, y los incidentes que inevitablemente surgen de una configuración mal hecha. Para muchas organizaciones, ese coste total termina siendo mayor que la propia factura de infraestructura.

La pregunta que de verdad importa

La discusión no debería ser "Kubernetes o serverless" como si fueran bandos irreconciliables, sino qué herramienta encaja mejor con cada workload concreto. Si tu carga de trabajo es stateless, orientada a web, y tu equipo no tiene expertise profunda en DevOps, serverless es probablemente la elección más sensata. Si necesitas multi-cloud, control absoluto, o workloads stateful complejos, Kubernetes sigue siendo insustituible.

Kubernetes no se está muriendo. Simplemente está volviendo a ocupar el lugar que le corresponde: el de la herramienta correcta para los casos complejos, no la respuesta por defecto para todo lo demás.