Serverless o contenedores: cómo elegir en 2026

Cada trimestre un fundador nos hace la misma pregunta: ¿deberíamos ir con serverless o ejecutar contenedores? La respuesta honesta es que el debate ha cambiado en silencio. En 2026 rara vez es una decisión de lo uno o lo otro, y los equipos que ganan tratan ambos como herramientas con bordes afilados en lugar de como identidades tribales.

Esta guía es lo que les contamos a los clientes antes de escribir una sola línea de infraestructura. Cubre los compromisos reales, dónde brilla cada modelo y una lista de verificación paso a paso que puede aplicar a su propia carga de trabajo.

El panorama de 2026 ha cambiado

Hace unos años, «serverless» significaba funciones de vida corta y «contenedores» significaba que usted gestionaba un clúster. Ambos estereotipos están ya desfasados.

• El serverless ha madurado. Las plataformas de funciones gestionadas ya admiten de forma habitual ventanas de ejecución más largas, límites de memoria mayores, streaming de respuestas y contenedores como formato de empaquetado. Puede desplegar un framework HTTP completo en un runtime de función y simplemente funciona.
• Los contenedores se volvieron más fáciles. Los runtimes de contenedores gestionados y las plataformas de contenedores serverless eliminaron la mayor parte del cuidado del clúster. Usted entrega una imagen, fija un objetivo de concurrencia y la plataforma la escala, incluido el escalado hasta cero.
• El terreno intermedio está saturado. Los runtimes edge, los motores de ejecución duradera y los workers dirigidos por colas difuminan las viejas fronteras. La etiqueta importa menos que el contrato operativo que hay debajo.

Así que la pregunta útil no es «cuál está más de moda» sino «qué modelo operativo encaja con esta carga de trabajo, este equipo y este presupuesto en concreto».

En qué es genuinamente bueno cada modelo

Dónde gana serverless

Las funciones serverless y las plataformas de contenedores serverless son fuertes cuando el tráfico es irregular o impredecible, cuando quiere pagar casi cero mientras está inactivo y cuando quiere reducir al mínimo la superficie operativa.

• Trabajo dirigido por eventos: webhooks, procesamiento de imágenes, trabajos programados y unión entre servicios gestionados.
• Tráfico en ráfagas o estacional, donde pagar por capacidad inactiva duele.
• Equipos pequeños que prefieren desplegar funcionalidades antes que ajustar autoescaladores.
• Experimentos rápidos y herramientas internas donde la velocidad hasta producción supera al control detallado.

Los compromisos son reales. Los arranques en frío todavía existen en muchos runtimes, aunque la concurrencia aprovisionada y los runtimes ligeros los han reducido. La tarificación por solicitud puede volverse cara con un volumen alto y sostenido. Las primitivas profundas del proveedor (su cola, su autenticación, su bus de eventos) crean una gravedad de la que es difícil salir.

Dónde ganan los contenedores

Los contenedores, ya sea en un servicio de contenedores serverless gestionado o en un clúster orquestado, son fuertes cuando necesita un rendimiento predecible, conexiones de larga duración o un control fino del runtime.

• Tráfico constante y de alto volumen, donde la capacidad reservada es más barata que la facturación por invocación.
• Servicios sensibles a la latencia que no pueden tolerar arranques en frío.
• WebSockets, flujos gRPC y otras conexiones de larga duración.
• Cargas de trabajo con dependencias nativas pesadas, GPU o bibliotecas de sistema personalizadas.
• Requisitos de portabilidad, ya que una imagen se ejecuta casi en cualquier lugar.

El coste es operativo. Incluso las plataformas gestionadas le piden pensar en imágenes, comprobaciones de salud, estrategia de despliegue y política de escalado. Un orquestador completo añade una profundidad real que un equipo de tres personas quizá no quiera asumir. Si al mismo tiempo está sopesando un cambio estructural mayor, nuestra guía sobre pasar de un monolito a microservicios combina bien con esta decisión.

Los cinco compromisos que realmente lo deciden

Ignore el marketing y puntúe su carga de trabajo según estas cinco dimensiones.

1. La forma del coste, no el nivel del coste

El serverless factura por solicitud y por unidad de tiempo de cómputo, así que es barato con volumen bajo e irregular y puede encarecerse cuando funciona a pleno rendimiento las 24 horas. Los contenedores facturan por capacidad aprovisionada, así que son más baratos con carga alta y constante y derrochadores cuando están sobre todo inactivos. No compare una sola cifra. Modele su curva de tráfico a lo largo de una semana completa y compare las formas. Recorremos este ejercicio en detalle en nuestro manual de optimización de costes en la nube.

2. Latencia y arranques en frío

Si una primera respuesta lenta rompiera la experiencia, mantenga instancias calientes (concurrencia aprovisionada, instancias mínimas) o elija contenedores con un suelo caliente. Según nuestra experiencia, los arranques en frío importan sobre todo en las rutas síncronas de cara al usuario y apenas importan en los trabajos en segundo plano.

3. El modelo de concurrencia

Muchas plataformas de funciones gestionan una solicitud por instancia por defecto, lo cual es sencillo pero puede multiplicar el coste bajo carga. Las plataformas de contenedores permiten que una instancia atienda muchas solicitudes concurrentes, lo cual es más eficiente para las API limitadas por entrada/salida. Ajuste el modelo de concurrencia a cómo gasta el tiempo realmente su código.

4. Estado y conexiones

El serverless favorece las interacciones sin estado y cortas. Las conexiones de larga duración, las cachés en memoria y el pooling de conexiones a bases de datos son todos más fáciles en contenedores. Si opta por serverless con una base de datos tradicional, planifique un pooler de conexiones o una capa de datos adaptada a serverless desde el primer día.

5. Dependencia del proveedor y portabilidad

El código de función que se apoya en las primitivas de eventos e identidad de un solo proveedor es más difícil de mover. Una imagen de contenedor es portable por construcción. Ninguna de las dos opciones es errónea, pero sea honesto sobre el coste de cambio que está asumiendo.

Una lista de verificación de decisión que puede aplicar hoy

Recorra estos pasos en orden. Deténgase en cuanto una restricción firme imponga la respuesta.

1. Trace la curva de tráfico. ¿La carga es irregular e impredecible, o constante y alta? Lo irregular se inclina hacia serverless, lo constante y alto se inclina hacia contenedores.
2. Fije un presupuesto de latencia. Anote el tiempo de primera respuesta aceptable. Si los arranques en frío lo reventarían y mantener caliente no es deseable, inclínese hacia contenedores.
3. Compruebe las necesidades de conexión. ¿Requiere WebSockets, streaming o un pooling de base de datos importante? Si es así, inclínese hacia contenedores.
4. Inspeccione las dependencias. ¿Necesita GPU, bibliotecas nativas grandes o un runtime personalizado? Si es así, inclínese hacia contenedores o contenedores serverless.
5. Sopese la capacidad del equipo. ¿Puede el equipo asumir la política de escalado y los despliegues, o necesita minimizar las operaciones? Un equipo pequeño se inclina hacia serverless.
6. Modele la factura. Estime el coste mensual con picos e inactividad realistas. Compare las formas, no solo las tarifas de titular.
7. Valore su tolerancia a la dependencia del proveedor. ¿Cuánto dolería una migración futura? Una menor tolerancia se inclina hacia contenedores o una imagen de contenedor serverless portable.
8. Planifique la salida. Elija lo que elija, documente cómo se marcharía de ahí. Si no puede describir la salida, reconsidere.

Si sus respuestas apuntan en direcciones distintas, es una señal para dividir el sistema en lugar de forzar un solo modelo sobre todo.

El patrón al que la mayoría de los equipos realmente llega

En la práctica, las arquitecturas más sólidas de 2026 son híbridas. Una forma común se ve así:

• Contenedores para la API central que soporta el tráfico constante, las conexiones de larga duración y las necesidades estrictas de latencia.
• Funciones serverless para los bordes irregulares: webhooks, procesamiento de medios, tareas programadas, notificaciones e integraciones.
• Una cola de mensajes o un bus de eventos compartido para que las dos mitades permanezcan débilmente acopladas y puedan escalar de forma independiente.

Esta división le permite pagar por la previsibilidad donde la necesita y pagar por uso donde no. También mantiene pequeño el radio de impacto, porque un pico en una función no amenaza su servicio central.

Se incline por donde se incline, las fronteras entre servicios importan tanto como el runtime. Unas interfaces limpias y bien versionadas facilitan mucho mover más adelante un componente de una función a un contenedor sin una reescritura. Si las API están en el centro de su sistema, nuestras notas de campo sobre diseñar API que los desarrolladores adoran le ahorrarán dolores aquí.

Errores comunes que vemos

• Elegir serverless para ahorrar dinero y luego ejecutarlo con tanta intensidad que los contenedores habrían costado menos.
• Elegir contenedores por el control y luego no usar nunca ese control y pagar por capacidad inactiva.
• Ignorar las conexiones a la base de datos hasta que un pico de tráfico agota el pool.
• Tratar la elección como permanente. Es una decisión reversible si mantiene limpias las interfaces.

Cómo puede ayudar Innovation T

En Innovation T diseñamos arquitecturas cloud que encajan con la carga de trabajo que tenemos delante, no con la tendencia del mes. Nuestros equipos de ingeniería de software y cloud empiezan modelando su tráfico, su presupuesto de latencia y su curva de coste, y después recomiendan serverless, contenedores o un híbrido deliberado, con los compromisos puestos por escrito para que su equipo pueda defender la decisión más adelante.

A partir de ahí lo construimos: infraestructura como código, autoescalado sensato, observabilidad y un camino de salida documentado para que nunca quede atrapado. También realizamos revisiones de coste y arquitectura para equipos que ya han desplegado y quieren una segunda opinión antes de escalar.

Si está sopesando serverless frente a contenedores para un producto nuevo o un sistema existente bajo carga, explore nuestros servicios o póngase en contacto y le ayudaremos a elegir con confianza, y luego a construirlo bien.