Durante años he tenido la oportunidad de trabajar con serverless, y es por eso que en este nuevo giro de mi newsletter voy a hablar en profundidad de esta arquitectura.
Bien.
Lo primero es entender su definición, ¿Qué es serverless? Su nombre ya da una pista porque literalmente se traduce como "sin servidor" pero seamos un poco más rigurosos desde el punto de vista técnico y salgamos de la definición marketinezca.
Serverless significa que el equipo no administra el aprovisionamiento, escalado y operación de la infraestructura subyacente; es decir el proveedor la abstrae y cobra normalmente por uso.
Para dar un ejemplo Google lo define como un modelo donde los recursos se asignan "as-used basis", sin gestionar servidores, y Martin Fowler lo describe como arquitecturas que combinan BaaS (Backend as a Service) y/o código propio corriendo en una plataforma FaaS (Function as a Service) en contenedores efímeros administrados por terceros.
Hay dos ideas distintas metidas bajo la misma etiqueta. La primera es BaaS: usar servicios gestionados como autenticación, base de datos, colas, storage o mensajería.
La segunda es FaaS: ejecutar unidades de código disparadas por eventos, bajo demanda y con escalado automático. Fowler remarca justamente eso: serverless no es solo funciones; también incluye apoyarse en servicios administrados que eliminan la necesidad de un backend tradicional "always-on". Google también aclara que FaaS es un subconjunto de serverless, no el todo.
Ahora que entendemos mejor lo que serverless es, ahora debemos entender que NO es serverless.
Bien.
Lo primero es entender que serverless no implica la no existencia de servidores, Significa que el proveedor los oculta operativamente. Google lo dice de forma explícita: los servidores siguen existiendo; lo que cambia es la experiencia de desarrollo y operación.
Tampoco significa automáticamente arquitectura simple, coste bajo o ausencia de DevOps. Volviendo a referenciar a Fowler, este ya advertía que la reducción de complejidad operacional puede venir acompañada de dependencias más fuertes del proveedor y tooling todavía inmaduro en algunos frentes. En otras palabras: eliminas una clase de problemas, pero aparecen otros.
Trade-offs de toda la vida.
Y tampoco es sinónimo de Lambda. AWS Lambda, Azure Functions, Cloud Run / Cloud Functions, Cloudflare Workers, Logic Apps, bases de datos serverless y otros servicios forman parte del espectro. Microsoft, Google y Cloudflare lo presentan como una familia de servicios orientados a eventos y consumo bajo demanda, no como una sola pieza, de hecho no es común usarlos de forma independiente porque justamente no están diseñado para eso.
¿Y de dónde viene serverless? ¿Cuál es su historia?
Aunque mucha gente asocia serverless con AWS Lambda, la historia empieza antes. Google afirma que App Engine, lanzado en 2008, fue "the first serverless product" mucho antes de que el buzzword se popularizara. En 2017, Google volvió a describir a App Engine como un entorno "pioneering serverless runtime environment", de hecho Google constantemente se "vende" así mismos como los pioneros en tecnologías de Cloud Computing.
El término serverless parece haber empezado a circular hacia 2012, según el repaso de Martin Fowler sobre el origen del término. Luego vino el gran punto de inflexión comercial: AWS Lambda fue anunciado en noviembre de 2014, y AWS en 2024 lo describió como el inicio de "the first decade of serverless innovation".
Yo escuché de esto cerca del año 2016-2017 cuando la empresa donde estaba trabajando en ese momento empezó a moverse a cloud.
Serverless se vendía como el futuro de la infraestructura y se decía que nadie nunca más volvería a utilizar un servidor propio o un VPS ya que serverlees resolvía todo esto y lo hacía incluso más fácil. ¿No te suena familiar esa afirmación?
Después llegaron las demás grandes piezas del mercado: Azure Functions entró en preview en marzo de 2016 y GA en noviembre de 2016; Cloudflare Workers fue lanzado en 2017 para ejecutar código en el edge; Google amplió el ecosistema con Cloud Functions en 2017 y Cloud Run en 2019. En retrospectiva, la evolución fue: PaaS -> FaaS -> serverless
¿Por qué serverless se hizo tan popular?
La promesa fue muy poderosa: menos operación, más velocidad, pago por uso, escalado automático y time-to-market más corto. Google habla de mejor productividad, escalado "out-of-box" y despliegues más rápidos; Azure vende exactamente el mismo valor: enfocarte en código y no en infraestructura; AWS lo resume como moverse más rápido, bajar costos y adaptarse al pico de demanda sin sobreaprovisionar.
En términos arquitectónicos, serverless fue atractivo porque prometía bajar el costo de ciertos atributos:
operabilidad, capacidad de escalar, velocidad de entrega y, en muchos casos, costo de entrada. Eso lo volvió especialmente seductor para productos nuevos, automatizaciones, flujos por eventos, integraciones y equipos pequeños con poca capacidad de plataforma.
De hecho sigue siendo muy atractivo, sobre todo por su promesa de escalado automático y por requerir casi 0 conocimiento en servidores para poder crear un producto que pueda escalar rápidamente.
Yo he visto a serverless brillar en casos muy puntuales, casi siempre en productos que tienen un potencial de crecimiento alto pero que arrancan con poco dinero, quiero detallar algunos casos de uso donde tengo la certeza que puede ser una opción ideal.
La principal APIs y backends ligeros
Microsoft destaca HTTP-based API endpoints como uno de los escenarios naturales de Azure Functions, y AWS promueve Lambda + API Gateway para backends y APIs. Esto encaja muy bien cuando la carga es variable, el throughput inicial no es enorme y el equipo quiere enfocarse en lógica de negocio, por parte de Google, Firebase es una opción muy popular, Firebase incentiva por defecto la creación de tu backend a través de Firebase Functions.
Procesamiento por eventos
Aquí es donde conceptualmente serverless nació para brillar: eventos de storage, colas, streams, webhooks, cambios de estado, cron jobs o integración entre sistemas. En mi experiencia este es el caso más común ya que puede reducir la complejidad en la integración de terceros, acciones programadas, procesamiento de streaming, procesamiento de imágenes e incluso video.
Automatizaciones y workflows
Serverless funciona muy bien en pipelines, ETL livianos, aprobaciones, notificaciones, procesos batch ocasionales y orquestaciones event-driven. Por ejemplo imagina que vas a migrar una cantidad de información a un esquema determinado de base de datos, si no quieres configurar un componente complejo para ejecutar ese migración podrías hacerlo a través de una function de cualquier nube.
Picos impredecibles
Cuando el tráfico es altamente variable o estacional, el modelo pay-per-use y el escalado automático son muy valiosos. Google recalca que serverless puede escalar a cero y volver a subir sin fine-tuning complejo; AWS empuja el argumento de "never pay for over-provisioning", básicamente es elasticidad por defecto o en muy pocos pasos, algo que sin serverless puede requerir conocimiento muy profundo en diferentes areas.
Prototipos, MVPs y equipos pequeños
No es casual que muchas historias positivas de serverless estén ligadas a equipos que necesitaban salir rápido, con poca fricción operativa y sin construir una plataforma interna completa. CyberArk, por ejemplo, eligió un enfoque serverless-first por el bajo overhead operativo para acelerar time-to-market.
Si llevan algún tiempo siguiendo lo que hago o la arquitectura les gusta, ya saben que todo tiene sus trade-offs, y por eso quiero analizar los casos donde la arquitectura serverless no solo no brilla, si no que oscurece el panorama.
Latencia alta (Mi favorito personal)
Google reconoce como desventaja los cold starts, es decir, retrasos por arranque en frío. AWS ha ido agregando mitigaciones como SnapStart, pero el problema no desaparece mágicamente; simplemente cambia según runtime, patrón de tráfico y configuración. Para sistemas en el camino crítico donde "cada milisegundo importa", esto puede ser determinante, ya sabes tú decides si te vas por serverless la latencia en peticiones iniciales puede ser un problema serio.
Workloads sostenidos y previsibles
Cuando la carga es alta, constante y estable, el pay-per-invocation puede dejar de ser óptimo. El caso más famoso del que pude llegar a saber es Prime Video, que movió un sistema de monitoreo de video/audio desde un diseño distribuido con servicios serverless hacia ECS/EC2, reduciendo costos en 90% para ese caso concreto. No fue una refutación total de serverless, no es que serverlees no sirva; simplemente es una evidencia de que un workload equivocado en el modelo equivocado sale caro.
Acceso intensivo a bases relacionales
Aquí hay un clásico: funciones que escalan rápido contra una BD relacional que no escala igual. AWS literalmente recomienda RDS Proxy para producción cuando Lambda abre muchas conexiones cortas, precisamente para evitar agotamiento de conexiones. Ese solo hecho ya te dice que hay una fricción estructural entre autoescalado explosivo y connection pools finitos.
Actualmente en el proyecto principal en el que trabajo estamos explorando alternativas para resolver este futuro problema, sin embargo debo decir que para el caso de necesitar información en tiempo real, Realtime Database y Cloud Functions de Google pueden funcionar muy bien, ya que pueden escalar casi a la par.
Procesos largos, acoplados o síncronos
AWS y Google advierten contra usar Lambdas o Functions monolíticas grandes y contra flujos muy síncronos que terminan aumentando runtimes y costos. Si necesitas procesos de larga duración, fuerte coordinación, mucha transferencia intermedia o intercambio intensivo de datos entre pasos, el diseño puede degradarse rápido.
A pesar de que la sección anterior puede servir como una guía para sacar ciertos trade-offs voy a dejar explícitamente aquí los que considero sus trade-offs reales.
Ventajas
La ganancia más clara es velocidad de entrega. Menos tiempo en servidores, parches, capacity planning y autoscaling rules, más tiempo en lógica de negocio. Google, Azure y AWS son consistentes en ese punto.
También ganas mucho en elasticidad. Cuando el patrón de carga es intermitente o impredecible, serverless puede ser una forma elegantísima de no pagar por capacidad ociosa. Esto es especialmente útil en integraciones, ingestion por eventos, jobs programados y picos no lineales.
Otro beneficio fuerte es la composición con servicios administrados. El ecosistema de eventos, storage, auth, colas, observabilidad e integración hace que una arquitectura "service-full" pueda salir muy rápido sin montar demasiadas piezas propias.
Desventajas
El costo real puede ser engañoso. Serverless suele ser barato cuando hay poca carga o carga muy variable, pero puede encarecerse con invocaciones masivas, estado transitorio almacenado fuera del proceso, orquestaciones con muchas transiciones o dependencia excesiva de servicios por request. El caso Prime Video es el mejor ejemplo público de esto.
Hay además un trade-off claro de vendor lock-in. Fowler ya hablaba de una mayor dependencia del proveedor, y Google reconoce que parte del trabajo actual del ecosistema ha sido abrir más las plataformas y mejorar la portabilidad. Es decir: lock-in no es invento de los críticos; es una consecuencia frecuente del valor que te da el proveedor.
La observabilidad, el debugging y el testing local también suelen empeorar respecto a una app más tradicional, sobre todo si el sistema termina muy fragmentado y muy orientado a eventos. Fowler lista testing, debugging y startup latency entre los temas relevantes del modelo.
Finalmente, serverless no elimina la necesidad de diseño distribuido; a veces la empeora porque hace muy fácil crear un sistema con demasiados puntos de coordinación invisibles. Casi todos los proveedores advierten sobre funciones monolíticas, síncronas, código repetido, mal dimensionamiento de memoria y dependencia de servicios downstream menos escalables.
Para tratar de aportar más valor en esta primera entrega de este nuevo formato de newsletter quise encontrar algunos casos de éxito y fracaso que podrían darnos una mejor perspectiva para entender serverless en el mundo real.
Veamos primero los casos de éxito que pude encontrar valiosos y que quise compartir aquí:
CyberArk
CyberArk usó serverless en AWS para construir una internal development platform y reportó una reducción del tiempo para lanzar un nuevo servicio de 18 semanas a 3 horas. El punto interesante no es solo el número, sino el motivo: estandarizar gobernanza, seguridad y blueprints arquitectónicos con bajo overhead operativo. Este es un gran ejemplo de serverless usado como acelerador de plataforma interna, no solo como hosting barato.
Coca-Cola Freestyle
Coca-Cola Freestyle construyó una experiencia de touchless pouring con backend en AWS Lambda y API Gateway, y AWS reporta que la solución Mobile Pour fue construida en 100 días. El valor aquí no es "mira, usa Lambda"; el valor es que serverless les permitió responder rápido a una necesidad de negocio con experiencia casi instantánea.
Mi caso de éxito
Nosotros llevamos ya varios años trabajando con serverless y nos ha permitido responder a diferentes necesidades del cliente, una de ellas es contar con la metodología de pago por uso, de esa forma cuando empezamos el proyecto los costos eran muy bajos y a medida que fuimos creciendo y la app se expandió más nuestro cliente pudo cubrir los gastos.
Adicionalmente al ser un equipo pequeño serverless nos ha permitido no depender de conocimiento demasiado especializado en infraestructura para crecer.
Y los fracasos?... Pues bien
Aquí conviene ser muy preciso: hay menos postmortems públicos "puros" de serverless de los que la gente cree. Muchas historias en internet mezclan serverless con malas decisiones de diseño distribuido, mal uso de bases de datos, abuso de orquestadores o errores de modelado de costos. Aun así, sí hay casos muy valiosos.
Prime Video: reversión parcial por costo y escalabilidad
InfoQ resume el caso del sistema de monitoreo de audio/video de Prime Video: los costos altos venían del gran volumen de lecturas/escrituras a S3 para datos intermedios y del número enorme de transiciones en Step Functions. El equipo consolidó la lógica en un solo proceso corriendo en ECS/EC2, movió transferencia intermedia a memoria y redujo costos 90%, además de resolver límites de escalabilidad que impedían procesar todos los streams. Este caso es oro porque demuestra que serverless puede ser excelente para llegar rápido, pero no siempre para el "mantenerse" óptimo.
Unkey: reversión por latencia y estado
De nuevo en InfoQ cuentan que Unkey migró su servicio de autenticación de API desde Cloudflare Workers a servidores stateful en Go, reportando 6x de mejora. La razón fue simple: su servicio estaba en el request path de miles de aplicaciones y necesitaban responder por debajo de 10 ms; la cache distribuida y la naturaleza stateless del modelo no les daban lo que necesitaban. Esta historia muestra un límite claro: cuando el estado y la latencia local son la esencia del problema, serverless puede estorbar más de lo que ayuda.
Fallas de diseño comunes documentadas por AWS
AWS no lo presenta como "fracaso", pero sus propios anti-patterns son casi una colección de fracasos repetidos: Lambdas gigantes, arquitecturas síncronas, código compartido desordenado, memoria mal configurada. También alertan sobre recursive invocations, que pueden disparar costos inesperados, y sobre la necesidad de idempotencia para tolerar duplicados. Estas son historias tan frecuentes que AWS terminó documentándolas oficialmente y estos mismos anti-patrones son aplicables a los demás proveedores.
Si has llegado hasta aquí, wow, gracias.
Ha sido un camino un poco largo, incluso debo confesarte que lograr terminar esta primera entrega me tomó muchísimo más tiempo del que pensé.
Así que sin más no pretendo robarte más tiempo.
Hasta ahora parece una buena semana, ayer ganó el Barça así que debo ser agradecido.
Recuerda que puedes apoyarme siguiéndome en cualquier red social o si lo quieres llevar a otro nivel, puedes donar, hacerte miembro de mi canal de YouTube o ambas :)
Feliz resto de semana!