La arquitectura serverless promete tres cosas: ningún servidor que gestionar, un escalado que ocurre sin ti y una factura que sigue el uso real en lugar de la capacidad ociosa. Para la carga de trabajo adecuada cumple las tres. Los equipos se meten en problemas cuando leen eso como permiso para construir un sistema entero así.
La arquitectura de computación serverless se ha vuelto habitual para una parte del stack y poco frecuente para todo él. La encuesta anual 2024 de la Cloud Native Computing Foundation encontró que el 44% de las organizaciones ejecutaba serverless en producción para unas pocas aplicaciones, seis puntos más que el año anterior, mientras que solo el 11% lo hacía para la mayoría o para todas sus aplicaciones, frente al 14% previo. En el mismo periodo, la proporción de organizaciones que no planean usar serverless a corto plazo subió al 23%.
El mayor coste oculto de una decisión serverless es lo que cuesta salir de ella. Una vez que la lógica principal se apoya en los servicios propietarios de un proveedor, moverla significa reconstruirla en torno a APIs que no tienen equivalente directo en ningún otro sitio, y ese es un presupuesto de reescritura que nadie había planificado.
Redwerk construye los dos tipos de sistemas. Nuestros servicios de desarrollo de aplicaciones cloud cubren los entornos multi-tenant, los motores de analítica y los procesadores de eventos que el serverless gestiona bien, y sabemos qué cargas de trabajo sacan más partido a ese modelo y cuáles se resuelven mejor de otra forma. En este artículo veremos cómo funciona el serverless, dónde compensa, dónde cuesta más de lo que ahorra y las cinco preguntas que hacemos antes de recomendarlo.
Qué es la arquitectura serverless y qué no es
La arquitectura serverless es un modelo cloud en el que el proveedor ejecuta tu código en contenedores sin estado, activados por eventos, y te cobra solo por el tiempo de ejecución. Encaja con el trabajo orientado a eventos, el tráfico con picos y los productos en fase temprana. Encaja mal con la lógica principal que necesita un registro de auditoría completo e inmutable, y rara vez es la elección correcta para un sistema entero.
El mecanismo que hay detrás es Function-as-a-Service, o FaaS. Subes una función, el proveedor la ejecuta en un contenedor de vida corta cuando un evento la activa y el contenedor desaparece después. Nunca eliges un tamaño de instancia, ni parcheas un sistema operativo, ni configuras un grupo de autoescalado. La mayoría de las arquitecturas cloud serverless reales combinan FaaS con Backend-as-a-Service, o BaaS: bases de datos gestionadas, autenticación, almacenamiento de ficheros y colas de mensajes que también opera el proveedor. Un stack típico se parece a esto: una función para la lógica, un almacén NoSQL gestionado para los datos, un servicio de autenticación alojado para la identidad y un bus de eventos que lo conecta todo.
El nombre provoca el único malentendido que merece la pena aclarar. Los servidores siguen existiendo. Alguien los sigue parcheando, planificando su capacidad y recibiendo una alerta cuando fallan. Ese alguien es el proveedor de cloud en lugar de tu equipo, lo que cambia quién carga con el peso operativo, no las leyes de la física. Hoy todos los grandes proveedores de cloud venden una de estas plataformas, incluidos Amazon Web Services con Lambda, Microsoft Azure con Azure Functions e IBM con Cloud Code Engine, así que el modelo está disponible allí donde ya vive tu infraestructura.
Las ventajas reales de la arquitectura serverless
Las ventajas de la arquitectura serverless son prácticas, y donde más se notan es en los equipos sin una función de plataforma o de DevOps dedicada. Cada una te ahorra dinero u horas de ingeniería. Los principales beneficios de la arquitectura serverless:
- Cero gestión de infraestructura. Sin aprovisionamiento, sin parchear sistemas operativos, sin planificar capacidad para el cómputo subyacente. El tiempo de ingeniería pasa de mantener servidores sanos a escribir lógica de negocio.
- Un escalado que no configuras. Una función que atiende diez peticiones por minuto atiende diez mil sin ningún cambio de configuración. Para un tráfico que de verdad no puedes predecir, esto elimina toda una categoría de incidentes.
- Precio de pago por uso. Se te factura el tiempo de ejecución, no la capacidad que se queda ociosa durante la noche. Un proceso batch que se ejecuta cuatro minutos al día cuesta aproximadamente cuatro minutos al día.
- Menor time to market en las cargas que le encajan. Saltarse la capa de infraestructura quita semanas reales a una construcción temprana, y eso vale más que nada cuando tienes fecha de lanzamiento y ningún equipo de plataforma.
Los datos de adopción dentro de los tres grandes clouds muestran hasta qué punto esto se ha vuelto rutinario. La telemetría de Datadog sobre clientes de cloud sitúa a Lambda en uso en el 65% de los clientes de AWS, Cloud Run en el 70% de los clientes de Google Cloud y App Service en el 56% de los clientes de Azure.
Las contrapartidas del serverless que nadie pone en la diapositiva
Todas las ventajas anteriores son reales. También lo es todo lo de esta sección, y las presentaciones de los proveedores suelen ir más ligeras en esta mitad. Estas cuatro contrapartidas son las que vemos causar problemas reales de presupuesto y de cumplimiento en proyectos reales.
Vendor lock-in. Cuando un sistema funciona sobre Lambda para el cómputo, DynamoDB para los datos, EventBridge para los eventos y Cognito para la identidad, salir de AWS no es una migración. Esos cuatro servicios no tienen equivalentes directos en Azure ni en Google Cloud, así que el trabajo consiste en reconstruir a la vez la capa de integración, el modelo de datos y el flujo de autenticación. Tomar esa decisión a sabiendas es razonable, pero descubrirlo dos años después, cuando una adquisición o una decisión de compras obliga a moverse, sale caro.
Los cold starts, que ahora cuestan dinero además de milisegundos. Si una función ha estado inactiva, el proveedor tiene que construir un entorno nuevo antes de que tu código pueda ejecutarse, y quien hizo la petición espera. Esa pausa suele ser una fracción de segundo, algo que nadie nota en un informe nocturno y que todo el mundo nota en una pantalla que está mirando.
Desde el 1 de agosto de 2025, la espera también aparece en la factura. AWS ahora cobra la fase de arranque de una función, y alinea así la configuración más habitual con la forma en que ya facturaba las demás. AWS afirma que la mayoría de sus clientes notará un impacto mínimo, porque los arranques ocurren en una parte pequeña del total de peticiones. Los equipos que sí lo notan son los que ejecutan muchas funciones de uso poco frecuente, donde los arranques suponen una parte grande del total. La misma contrapartida está apareciendo en la infraestructura de IA: AWS Bedrock AgentCore ejecuta agentes sobre un modelo serverless de Lambda que escala a cero cuando está inactivo y lo paga con retardo de arranque en cualquier cosa por la que una persona esté esperando.
La observabilidad se complica. Depurar una petición que tocó un único servicio bien delimitado es cuestión de leer un solo flujo de logs. Depurar una petición que se abrió en abanico por nueve funciones de vida corta implica correlacionar nueve flujos de logs de contenedores que ya no existen, y por eso el trazado distribuido deja de ser opcional. Es resoluble, y es trabajo que un monolito simplemente no genera.
La auditoría y el cumplimiento son el problema más difícil. Cuando una carga de trabajo necesita un registro completo e inmutable de cada operación que toca datos regulados o sensibles, la naturaleza efímera y distribuida de las funciones serverless hace que ese registro sea más difícil de garantizar de forma consistente que con un único pipeline de logging controlado.
Cuándo la arquitectura serverless es la decisión correcta
Saber cuándo usar arquitectura serverless es, sobre todo, una cuestión de dónde se sitúa la carga de trabajo respecto a tu producto principal. El patrón que funciona es serverless en los bordes del sistema, haciendo un trabajo que por naturaleza tiene forma de evento y tolera algo de latencia. Tres casos encajan lo bastante bien como para que lo recomendemos sin dudar.
Las tareas de fondo orientadas a eventos y las funciones auxiliares son el encaje más claro: procesar una imagen después de subirla, un informe nocturno, un handler de webhooks, un envío masivo de notificaciones. Ninguna de ellas es el núcleo de la aplicación, todas se activan en lugar de ser continuas y unos cientos de milisegundos de retardo de arranque no perjudican a nadie.
El tráfico con picos o impredecible es el segundo. Si tu carga es una línea plana, la capacidad reservada suele ser más barata. Si tu carga es una venta de entradas, un plazo fiscal o el pico de una campaña, pagar el pico todo el año es un desperdicio que el serverless elimina.
Los productos en fase temprana son el tercero. Un equipo que todavía no ha contratado a su primer ingeniero de plataforma consigue una capa operativa de nivel producción sin tener que construirla, lo que recupera las semanas que de otro modo se irían en infraestructura antes de la primera release.
Cuándo descartaríamos el serverless
Descarta el serverless para la lógica principal de la aplicación cuando la carga de trabajo exija un registro de auditoría completo e inmutable. La naturaleza efímera y distribuida de las funciones serverless hace que ese registro sea más difícil de garantizar que un único pipeline de logging controlado, y una conversación sobre cumplimiento es un mal sitio para usar las palabras “más difícil de garantizar”.
Esto surge en proyectos reales. Change & Innovation Agency es un SaaS de administración electrónica 100% conforme con la Americans with Disabilities Act (ADA), utilizado por departamentos de servicios sociales de todo Estados Unidos, con exigencias de cumplimiento que rivalizan con las del sector sanitario. Cada operación que toca datos de un expediente tiene que poder reconstruirse a demanda, años después y sin lagunas. Para un núcleo así elegimos una arquitectura convencional y controlada, que es el mismo razonamiento que hay detrás de el stack tecnológico para SaaS que elegiríamos de verdad.
La misma lógica se aplica mucho más allá de los sectores regulados. Siempre que tengas que poder demostrar exactamente qué le pasó a un registro concreto, una arquitectura que te da un único camino auditable vale más que una que escala a cero.
Arquitectura serverless vs microservicios vs arquitectura tradicional
La comparación entre arquitectura serverless y microservicios es la que más confusión genera, porque las dos palabras responden a preguntas distintas. El serverless trata de quién gestiona el entorno de ejecución. Los microservicios tratan de cómo descompones la aplicación en piezas desplegables. Son decisiones independientes, y puedes tener cualquier combinación de las dos, incluidos un monolito serverless y una flota de microservicios en contenedores.
La mayoría de los sistemas que merece la pena mantener acaban combinando elementos de las tres columnas de abajo, que es también cómo abordamos la arquitectura escalable en general. Los mismos datos de Datadog lo respaldan: el 66% de las organizaciones que usan funciones serverless ejecuta además al menos un servicio de orquestación de contenedores, así que la pregunta realista es qué partes van a dónde.
Quién gestiona el runtime
El proveedor de cloud
Tu equipo, mediante un orquestador
Tu equipo, de principio a fin
Cómo escala
Automáticamente, por petición
Reglas configuradas, por servicio
Manual o vertical
Qué se paga
Solo el tiempo de ejecución
Capacidad reservada o asignada
Capacidad aprovisionada
Latencia por cold start
Un factor real
Mínima una vez en marcha
Ninguna
Portabilidad entre clouds
La más baja
Alta, sobre todo con Kubernetes
La más alta
Esfuerzo del registro de auditoría
El más alto
Moderado
El más bajo
Mejor encaje
Trabajo orientado a eventos, con picos y auxiliar
Servicios core a escala
Núcleos estables, muy acoplados y regulados
Buenas prácticas de arquitectura serverless si eliges este camino
Las buenas prácticas de arquitectura serverless que importan son las que evitan que las contrapartidas anteriores se conviertan en incidentes. Las cuatro son baratas de adoptar al inicio de un proyecto y caras de meter con calzador en uno que ya está en producción. Las aplicamos en cada componente serverless que entregamos.
- Mantén las funciones pequeñas y con un solo propósito, y mantén con ellas pequeño el paquete de despliegue. El tiempo de arranque escala con lo que cargas, así que un paquete ligero es ahora una optimización tanto de latencia como de facturación.
- Diseña cada función para que sea idempotente. Las fuentes de eventos reintentan, y las entregas duplicadas son lo normal y no la excepción, así que ejecutar el mismo evento dos veces tiene que producir el mismo resultado que ejecutarlo una.
- Centraliza el logging y el trazado distribuido desde el primer día. Unos IDs de correlación propagados por todas las funciones y un único destino para los logs cuestan una tarde al inicio de un proyecto y semanas después de un incidente.
- Limita el acoplamiento propietario allí donde la portabilidad tenga valor de negocio. Mantener la lógica de negocio en código sencillo, con los servicios del proveedor detrás de una interfaz fina, conserva la opción de moverse sin renunciar al modelo.
Cómo decidir: un framework práctico
Cinco preguntas resuelven la mayoría de las decisiones sobre serverless, y son las mismas cinco que repasamos en una conversación de arquitectura antes de recomendar nada. Respóndelas para una carga de trabajo a la vez, porque el núcleo de tu producto y el trabajo que lo rodea suelen dar respuestas distintas.
- ¿Qué forma tiene el tráfico? Estable y predecible favorece la capacidad reservada. Con picos, estacional o desconocido favorece el serverless.
- ¿Cuáles son los requisitos de auditoría y cumplimiento? Si un registro completo e inmutable es obligatorio para esta carga de trabajo, déjala fuera del serverless.
- ¿Qué escala esperas dentro de dos o tres años? Un precio por petición que resulta barato con un millón de invocaciones al mes merece modelarse con cincuenta millones.
- ¿Qué capacidad DevOps tienes realmente en casa? No tener equipo de plataforma es un argumento fuerte a favor del serverless. Un equipo de plataforma maduro estrecha bastante la diferencia.
- ¿Hasta qué punto es central esta carga de trabajo para el producto? El trabajo auxiliar y orientado a eventos encaja de forma natural. El sistema de registro, normalmente no.
Si dos o tres de esas respuestas son inciertas, esa incertidumbre merece resolverse antes de construir. Nuestros servicios de especificación funcional existen para poner primero sobre el papel una revisión de arquitectura sin autoengaños.
Las arquitecturas más sólidas son híbridas
El serverless no es un compromiso de todo o nada, y tratarlo como tal es la forma en que los equipos acaban pagando capacidad ociosa que nunca necesitaron o explicando una laguna en un log de auditoría. Las arquitecturas más sólidas que hemos entregado en más de 250 plataformas desde 2005 ponen el serverless donde se gana su sitio, en el trabajo orientado a eventos y auxiliar, y mantienen la lógica principal y sensible al cumplimiento en servicios tradicionales o en contenedores.
Si estás valorando esto sobre un sistema real, habla con nosotros sobre tu arquitectura y te diremos qué cargas de trabajo deben ir en serverless, cuáles no y cuánto cuesta cada camino, antes de que dediques tiempo de ingeniería a la forma equivocada.
Preguntas frecuentes
¿Cuáles son los pros y los contras de la arquitectura serverless?
Los pros son cero gestión de infraestructura, escalado automático, precio de pago por uso y una entrega más rápida en las cargas que encajan. Los contras son el vendor lock-in a través de servicios propietarios, la latencia por cold start que AWS factura desde agosto de 2025, una depuración más difícil entre funciones distribuidas y la dificultad de garantizar un registro de auditoría completo e inmutable.
¿Cuándo no deberías usar arquitectura serverless?
Evítalo para la lógica principal de la aplicación que exija un registro de auditoría completo e inmutable, para el tráfico estable y predecible donde la capacidad reservada es más barata, y para las rutas de cara al usuario críticas en latencia donde los cold starts son inaceptables. Los requisitos de portabilidad son otra razón para ser prudente, ya que los servicios gestionados propietarios son la parte más difícil de cualquier salida del cloud.
¿Es el serverless más barato que ejecutar contenedores?
Depende por completo de la forma del tráfico. El serverless suele ser más barato en cargas con picos y bajo ciclo de trabajo, porque no pagas nada mientras está inactivo. Los contenedores suelen ser más baratos con carga estable y de alto volumen, donde el precio por petición se acumula más rápido que la capacidad reservada. Modela tus propios recuentos de invocaciones a la escala prevista en lugar de dar por hecha una dirección u otra.
¿Es la arquitectura serverless lo mismo que los microservicios?
No. El serverless describe quién gestiona el entorno de ejecución, y los microservicios describen cómo se descompone la aplicación en piezas desplegables de forma independiente. Puedes ejecutar un monolito sobre funciones serverless o microservicios en tus propios servidores, y la mayoría de los sistemas en producción mezcla ambos modelos.
¿Serverless significa que no hay servidores?
No. Los servidores siguen ejecutando tu código, pero es el proveedor de cloud quien los aprovisiona, parchea y escala, en lugar de tu equipo. El cambio está en quién carga con el peso operativo, no en si los servidores existen.
Descubra cómo ayudamos a AWE Learning a migrar de las instalaciones a la nube y a llegar a usuarios fuera de EE.UU. mediante la implantación de una solución SaaS escalable.
