{"id":507,"date":"2026-03-09T20:19:12","date_gmt":"2026-03-09T20:19:12","guid":{"rendered":"https:\/\/blog.rebalai.com\/es\/2026\/03\/09\/serverless-vs-containers-in-2026-a-practical-decis\/"},"modified":"2026-03-18T22:31:11","modified_gmt":"2026-03-18T22:31:11","slug":"serverless-vs-containers-in-2026-a-practical-decis","status":"publish","type":"post","link":"https:\/\/blog.rebalai.com\/es\/2026\/03\/09\/serverless-vs-containers-in-2026-a-practical-decis\/","title":{"rendered":"Serverless vs Contenedores en 2026: Gu\u00eda Pr\u00e1ctica de Decisi\u00f3n para Equipos de Backend"},"content":{"rendered":"

El a\u00f1o pasado mi equipo \u2014 \u00e9ramos cinco ingenieros en ese momento \u2014 llevaba casi dos a\u00f1os con toda la infraestructura de backend en AWS Lambda. Funciones Python para procesar eventos, APIs s\u00edncronas, pipelines de<\/a> datos. Todo serverless. Est\u00e1bamos orgullosos de eso.<\/p>\n

Entonces empezamos a integrar modelos de ML propios. Y todo empez\u00f3 a crujir.<\/p>\n

Este post no es un benchmark neutral. Es c\u00f3mo tomamos la decisi\u00f3n, qu\u00e9 nos sorprendi\u00f3 en el<\/a> camino, y qu\u00e9<\/a> har\u00eda diferente si empezara desde cero en 2026<\/a>.<\/p>\n

Dos A\u00f1os en Lambda: Lo que<\/a> Funcion\u00f3 y el L\u00edmite que No Vi Venir<\/h2>\n

Antes de hablar de contenedores<\/a>, tengo que ser honesto sobre lo bueno. Lambda funcion\u00f3 muy bien durante bastante tiempo. Proces\u00e1bamos unos 2-3 millones de eventos diarios provenientes de webhooks de tiendas \u2014 Shopify principalmente \u2014 y el modelo de<\/a> pago por ejecuci\u00f3n nos ahorraba mucho comparado con servidores corriendo 24\/7 con cargas variables. En los meses de baja temporada, la factura de compute ca\u00eda casi a cero. Eso es real y no hay que subestimarlo.<\/p>\n

El problema lleg\u00f3 cuando empezamos a correr modelos de embeddings para recomendaciones de producto. Nuestro primer modelo de<\/a> sentence-transformers pesaba unos 420MB solo el checkpoint. Lambda tiene un l\u00edmite de 250MB para el paquete de deployment sin comprimir, y aunque pod\u00e9s cargar modelos desde S3 al iniciar, eso disparaba los cold starts a entre 8 y 12 segundos. Para una API<\/a> s\u00edncrona, eso es inaceptable.<\/p>\n

Intent\u00e9 workarounds. Cargu\u00e9 el modelo de<\/a> forma lazy, explor\u00e9 Lambda SnapStart (tuvimos que reescribir parte del pipeline, no vali\u00f3 la pena<\/a>), prob\u00e9 contenedores de Lambda que permiten hasta 10GB de imagen. Eso \u00faltimo ayud\u00f3 un poco, pero el cold start segu\u00eda siendo entre 3 y 5 segundos para el modelo grande. Ninguna de las tres opciones era satisfactoria \u2014 y lo peor era que cada workaround generaba su propia deuda t\u00e9cnica.<\/p>\n

El patr\u00f3n que me tard\u00f3 en ver:<\/strong> Lambda sigue siendo excelente para cargas event-driven con dependencias ligeras. En cuanto met\u00e9s ML o cualquier proceso que requiera estado caliente persistente en memoria, empez\u00e1s a pelear contra la plataforma en lugar de con ella.<\/p>\n

Donde los Contenedores Ganaron la Discusi\u00f3n Interna<\/h2>\n

La migraci\u00f3n a ECS Fargate para las cargas de ML no fue una decisi\u00f3n feliz. Fue una decisi\u00f3n forzada.<\/p>\n

Lo primero que not\u00e9 al mover los pipelines de<\/a> inferencia a Fargate fue el control. Aunque \u2014 d\u00e9jame retroceder un segundo, porque Fargate no es simple. Tuve que escribir task definitions, ajustar los l\u00edmites de CPU y memoria, configurar IAM roles espec\u00edficos, y entender c\u00f3mo funcionan los scaling policies en detalle. Eso tom\u00f3 tiempo. Pero una vez listo, tener un contenedor con Python 3.12, CUDA, y todas las dependencias ML corriendo sin restricciones artificiales de tama\u00f1o era… alivio, honestamente.<\/p>\n

Ac\u00e1 va un ejemplo simplificado de c\u00f3mo pasamos de una Lambda con carga de modelo a un servicio en Fargate:<\/p>\n

# Antes: Lambda handler con cold start doloroso en cada invocaci\u00f3n fr\u00eda\nimport json\nfrom sentence_transformers import SentenceTransformer\n\n# Se ejecuta en cada cold start \u2014 entre 8-12s con el modelo grande\nmodel = SentenceTransformer('all-mpnet-base-v2')  # 420MB en disco\n\ndef handler(event, context):\n    texts = [record['body'] for record in event['Records']]\n    embeddings = model.encode(texts)\n    # guardar embeddings en DynamoDB...\n    return {'statusCode': 200}\n<\/code><\/pre>\n
# Despu\u00e9s: servicio FastAPI en Fargate \u2014 modelo cargado una vez, persiste en memoria\nfrom fastapi import FastAPI\nfrom sentence_transformers import SentenceTransformer\nimport uvicorn\n\napp = FastAPI()\n\n# Se carga una vez cuando arranca el contenedor, no en cada request\nmodel = SentenceTransformer('all-mpnet-base-v2')\n\n@app.post("\/embeddings")\nasync def generate_embeddings(texts: list[str]):\n    # batch_size=32 para aprovechar paralelismo del modelo en memoria\n    embeddings = model.encode(texts, batch_size=32)\n    return {"embeddings": embeddings.tolist()}\n\nif __name__ == "__main__":\n    uvicorn.run(app, host="0.0.0.0", port=8080)\n<\/code><\/pre>\n
La diferencia en latencia fue brutal. P99 baj\u00f3 de ~9s a ~180ms para el mismo modelo en los mismos requests. El modelo cargado una vez en memoria versus recargado en cada cold start es una diferencia que parece obvia en retrospectiva, pero cuesta verla cuando llev\u00e1s a\u00f1os pensando en t\u00e9rminos de funciones stateless.<\/p>\n
Lo que no me gust\u00f3 de Fargate: el costo base. Con Lambda pag\u00e1s exactamente lo que<\/a> us\u00e1s. Con Fargate, si ten\u00e9s un task corriendo 24\/7 para mantener el modelo caliente en memoria, pag\u00e1s por esas horas aunque el tr\u00e1fico sea m\u00ednimo a las<\/a> 3am. Para nuestro workload procesando unos 50k requests por d\u00eda con picos horarios marcados, el costo mensual en Fargate fue entre 3x y 4x m\u00e1s caro que lo que<\/a> habr\u00edamos pagado con Lambda sin el problema del cold start.<\/p>\n
Right, so \u2014 \u00bfc\u00f3mo justificamos el gasto? Rendimiento medible. Nuestros clientes notaban la diferencia y los datos lo confirmaron: conversion rate en las p\u00e1ginas de recomendaciones subi\u00f3 un 12% cuando la latencia baj\u00f3 a menos de 200ms. Eso cerr\u00f3 la discusi\u00f3n interna.<\/p>\n
Takeaway pr\u00e1ctico:<\/strong> Fargate tiene sentido<\/a> cuando necesit\u00e1s estado caliente en memoria, dependencias pesadas, o procesos de m\u00e1s de 15 minutos. El costo base es real \u2014 hay que justificarlo con impacto concreto de negocio, no con argumentos t\u00e9cnicos.<\/p>\n
El Hallazgo que Me Confundi\u00f3 Durante Semanas: Cloud Run<\/h2>\n
Un colega me recomend\u00f3 Google Cloud Run para un servicio nuevo \u2014 una API<\/a> de procesamiento de im\u00e1genes que necesitaba OpenCV y algo de l\u00f3gica custom. Cloud Run b\u00e1sicamente te permite correr contenedores Docker de forma serverless: escala a cero cuando no hay tr\u00e1fico, pero al llegar requests escala contenedores completos.<\/p>\n
Mi primera reacci\u00f3n fue: “\u00bfesto no es simplemente Lambda pero con Docker?” Y parcialmente s\u00ed. Pero la diferencia pr\u00e1ctica me tom\u00f3 tiempo entender, y creo que la confusi\u00f3n viene de que la distinci\u00f3n no es obvia en la documentaci\u00f3n.<\/p>\n
Con Lambda container images, vos defin\u00eds tu imagen pero Lambda gestiona el runtime con sus propias restricciones: timeouts m\u00e1ximos de 15 minutos, el modelo de<\/a> ejecuci\u00f3n de funciones, limitaciones de concurrencia que requieren configuraci\u00f3n expl\u00edcita. Con Cloud Run, el contrato es distinto: vos expon\u00e9s un servidor HTTP y Cloud Run gestiona cu\u00e1ntas instancias corren. Tu c\u00f3digo puede tener estado dentro de una instancia mientras est\u00e9 viva. Pod\u00e9s usar WebSockets. No existe l\u00edmite de 15 minutos por request.<\/p>\n
Prob\u00e9 Cloud Run para ese servicio de im\u00e1genes y el cold start fue de aproximadamente 600-900ms con una imagen de ~1.2GB. No tan r\u00e1pido como un contenedor siempre encendido, pero mucho m\u00e1s barato en cargas variables. Lo que<\/a> m\u00e1s me sorprendi\u00f3 fue el pricing model: Cloud Run cobra por tiempo de CPU y memoria durante el procesamiento de requests, no por tiempo de instancia activa (a menos que configures min-instances > 0<\/code>). Para cargas intermitentes medianas, eso puede ser significativamente m\u00e1s barato que Fargate.<\/p>\n
No lo prob\u00e9 a m\u00e1s de 800-1000 requests por segundo concurrentes, as\u00ed que no puedo hablar de ese rango con seguridad. Pero para nuestro caso, Cloud Run resolvi\u00f3 el equilibrio entre costo y performance de una forma que ni Lambda pura ni Fargate pod\u00edan ofrecer por separado.<\/p>\n
Takeaway pr\u00e1ctico:<\/strong> Si est\u00e1s viendo serverless y contenedores como dos mundos completamente separados, te est\u00e1s<\/a> perdiendo opciones intermedias que en 2026<\/a> est\u00e1n bastante maduras. Cloud Run y AWS App Runner son probablemente el punto de partida correcto para m\u00e1s proyectos de los que la gente considera.<\/p>\n
Los N\u00fameros Reales Comparados (el Ejercicio que Me Pidi\u00f3 el CFO)<\/h2>\n
Arm\u00e9 esto despu\u00e9s de<\/a> que me pidieran justificar una factura de AWS que hab\u00eda subido un 40% en tres meses. Empuj\u00e9 esa migraci\u00f3n de infra un viernes<\/a> por la tarde \u2014 error cl\u00e1sico \u2014 y el proceso de validaci\u00f3n de costos dur\u00f3 dos semanas<\/a>. En retrospectiva, deber\u00eda haberlo hecho con m\u00e1s datos antes de mover nada.<\/p>\n
Tres workloads representativos, costos aproximados mensuales en us-east-1:<\/p>\n
Workload A: Procesamiento de webhooks (2M eventos\/d\u00eda, avg 200ms de ejecuci\u00f3n)<\/strong>
\nLambda: ~$45\/mes. Fargate (1 task 0.5 vCPU, 1GB RAM, 24\/7): ~$22\/mes. Cloud Run: ~$31\/mes.
\nFargate gan\u00f3. Carga constante y predecible significa que el compute dedicado sale m\u00e1s barato que pagar por invocaci\u00f3n.<\/p>\n
Workload B: API de inferencia ML (50k requests\/d\u00eda, distribuci\u00f3n horaria con picos)<\/strong>
\nLambda con cold starts: t\u00e9cnicamente no viable para nuestro SLA de latencia bajo 500ms. Fargate (1 task caliente, 2 vCPU, 4GB RAM): ~$110\/mes. Cloud Run (1 vCPU, 2GB RAM, min-instances=1<\/code> para evitar cold starts): ~$62\/mes.
\nCloud Run con una instancia m\u00ednima gan\u00f3. Manten\u00e9s el modelo caliente sin pagar por N contenedores inactivos.<\/p>\n
Workload C: ETL nocturno (30 minutos por noche, procesamiento intensivo)<\/strong>
\nLambda: ~$2\/mes. Fargate on-demand: ~$8\/mes. Cloud Run: ~$3.50\/mes.
\nLambda gan\u00f3 f\u00e1cil. Para trabajos cortos e infrecuentes, el modelo de<\/a> pago por ejecuci\u00f3n es imbatible.<\/p>\n
Lo que estos n\u00fameros muestran, m\u00e1s all\u00e1 de los valores espec\u00edficos: el patr\u00f3n de tr\u00e1fico importa tanto como el tipo de workload. No existe una respuesta universal.<\/p>\n
Mi Recomendaci\u00f3n Real Seg\u00fan el Tipo de Proyecto<\/h2>\n
Voy a ser directo porque “depende de tu caso de uso” no le sirve a nadie cuando est\u00e1 tomando una decisi\u00f3n concreta con fecha l\u00edmite.<\/p>\n
Serverless puro (Lambda, Cloud Functions)<\/strong> es la elecci\u00f3n correcta si tu equipo tiene menos de 5 ingenieros de backend, tus workloads son principalmente event-driven con dependencias ligeras (menos de 100MB), y la variabilidad de tr\u00e1fico es alta o impredecible. El overhead operativo de gestionar contenedores no vale la pena<\/a> si pod\u00e9s evitarlo.<\/p>\n
Contenedores dedicados (Fargate, GKE, EKS)<\/strong> cuando ten\u00e9s ML en producci\u00f3n con<\/a> modelos que pesan m\u00e1s de 500MB, procesos que corren por m\u00e1s de 15 minutos, o carga base predecible y sostenida que justifique instancias dedicadas. Tambi\u00e9n si tu equipo ya tiene expertise s\u00f3lido en Docker y Kubernetes \u2014 la curva de aprendizaje ya est\u00e1 amortizada y el beneficio operativo compensa.<\/p>\n
La opci\u00f3n intermedia (Cloud Run, App Runner, Azure Container Apps)<\/strong> es donde yo comenzar\u00eda hoy para la mayor\u00eda de APIs medianas nuevas. Contenedores con billing serverless. La limitaci\u00f3n principal es el vendor lock-in a la plataforma de cloud, que puede o no importarte seg\u00fan tu estrategia \u2014 aunque honestamente, para equipos de menos de 10 personas construyendo en un solo cloud, ese lock-in raramente es el problema real.<\/p>\n
Kubernetes gestionado lo dejar\u00eda para equipos con platform engineering dedicado. Con cinco personas, no pod\u00edamos darnos ese lujo. Aprendimos eso de la manera cara, no de un post.<\/p>\n
Mi veredicto despu\u00e9s de<\/a> este a\u00f1o: para un equipo de 4-6 personas en 2026<\/a>, el punto de partida deber\u00eda ser Cloud Run o App Runner, con Lambda reservado para event processing liviano y contenedores dedicados \u00fanicamente para workloads de ML con estado o procesamiento intensivo. La arquitectura puramente serverless que ten\u00edamos era elegante, pero nos limit\u00f3 cuando escalamos en complejidad \u2014 no en tr\u00e1fico. Esa es una distinci\u00f3n que no aparece en ning\u00fan comparison chart.<\/p>\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
El a\u00f1o pasado mi equipo \u2014 \u00e9ramos cinco ingenieros en ese momento \u2014 llevaba casi dos a\u00f1os con toda la infraestructura de backend en AWS Lambda.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[1],"tags":[],"class_list":["post-507","post","type-post","status-publish","format-standard","hentry","category-general"],"_links":{"self":[{"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts\/507","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/comments?post=507"}],"version-history":[{"count":11,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts\/507\/revisions"}],"predecessor-version":[{"id":762,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts\/507\/revisions\/762"}],"wp:attachment":[{"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/media?parent=507"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/categories?post=507"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/tags?post=507"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}