Serverless: la FaaS es solo el principio
Descubre hasta dónde llega Serverless: Functions-as-a-Service es solo el comienzo. Mostramos el siguiente paso en la arquitectura en la nube.
Lo esencial en resumen
- Serverless va más allá de Lambda/Functions: bases de datos, colas, almacenamiento, inferencia ML — todo disponible como servicio sin servidores
- El modelo pago por ejecución ahorra entre un 60 y un 80 por ciento en cargas de trabajo esporádicas, pero puede resultar más caro que instancias de cómputo bajo carga constante
- Los arranques en frío siguen siendo un problema para aplicaciones sensibles a la latencia — la concurrencia aprovisionada como solución temporal
- Bloqueo del proveedor mediante modelos de eventos propietarios (EventBridge, Cloud Events) — la portabilidad requiere capas de abstracción
- Serverless-first como principio arquitectónico: solo aquello que no puede ejecutarse sin servidores se despliega en instancias de cómputo
Serverless ha encontrado su lugar — aunque de forma distinta a la esperada. AWS Lambda, Azure Functions y Google Cloud Functions fueron el punto de partida. En 2026, serverless es un principio arquitectónico, no un servicio aislado: bases de datos sin servidores, contenedores sin servidores, inferencia ML sin servidores. La pregunta ya no es si usar serverless, sino hasta qué punto.
Más allá de las funciones: el ecosistema serverless en 2026
La primera ola serverless (2015-2020) se centró en funciones: fragmentos pequeños de código, activados por eventos y con facturación por invocación. El ecosistema de 2026 es mucho más amplio: DynamoDB y Aurora Serverless (bases de datos), SQS y EventBridge (mensajería), S3 y EFS (almacenamiento), SageMaker Serverless Inference (ML) — todo ello sin necesidad de planificación de capacidad.
El cambio de paradigma: en lugar de la pregunta «¿Qué servidor necesito?», ahora se plantea «¿Qué servicio ofrece la nube para mi caso de uso?». Y la respuesta cada vez más frecuente es: uno en el que no hay que preocuparse por la infraestructura.
Cuándo resulta más barato serverless — y cuándo no
La ecuación de costes es clara en cargas esporádicas: una función Lambda que se ejecuta 10.000 veces al día durante 200 ms cada vez cuesta menos de 1 EUR/mes. Un pequeño servidor EC2 para el mismo trabajo: entre 30 y 50 EUR/mes. Ahorro: hasta el 97 por ciento.
En cargas constantes, la situación se invierte: una función Lambda que se ejecuta las 24 horas del día con alta concurrencia resulta más cara que una instancia EC2 dedicada. El punto de equilibrio depende de la frecuencia de invocaciones, la duración de la ejecución y los requisitos de memoria. Regla general: por debajo del 50 por ciento de utilización, serverless es más económico.
Arranques en frío: el problema persistente
Cuando una función serverless se invoca por primera vez tras un período de inactividad, debe inicializarse su entorno de ejecución — esto es un arranque en frío. Python/Node.js: 100-500 ms. Java/.NET: 1-5 segundos. Para APIs que requieren latencias inferiores a 200 ms, esto supone un problema.
Soluciones: la concurrencia aprovisionada (AWS) mantiene las funciones «calientes» — elimina los arranques en frío, pero también el ahorro de costes. Snap Start (Java) y la compilación jerárquica reducen el tiempo de inicialización. La tendencia: los entornos de ejecución son cada vez más rápidos, los arranques en frío más breves — pero no desaparecen por completo.
Serverless-first como principio arquitectónico
Los arquitectos orientados al futuro comienzan con la pregunta: «¿Se puede hacer esto sin servidores?». Solo aquello que no sea viable en serverless (procesos de larga duración, cargas de trabajo con GPU, requisitos específicos de red) se despliega en instancias de cómputo o Kubernetes.
Este principio maximiza la proporción de infraestructura completamente gestionada. Menos esfuerzo operativo, escalado automático, pago por uso — las ventajas operativas superan en la mayoría de los casos las limitaciones. La arquitectura debe adaptarse (orientada a eventos, sin estado, idempotente), pero estas ya son buenas prácticas para sistemas escalables.
Preguntas frecuentes
¿El serverless solo es para pequeñas cargas de trabajo?
No. Netflix, Coca-Cola y LEGO operan grandes arquitecturas serverless. Serverless escala por diseño a millones de ejecuciones simultáneas. La limitación no está en la escala, sino en la arquitectura: Stateless, Event-Driven y procesos de corta duración.
¿Cómo manejo el estado en serverless?
El estado se externaliza: DynamoDB/Redis para el estado de sesión, S3 para archivos, Step Functions para el estado de flujo de trabajo. Esto es disciplina arquitectónica, pero fuerza buenas prácticas que también son útiles en arquitecturas no serverless.
¿Qué pasa con el Vendor Lock-in?
Es real, pero manejable. Los modelos de eventos y las configuraciones de disparadores son propietarios. La lógica de las funciones en sí (Python, Node.js, Go) es portable. Frameworks como Serverless Framework y SST abstraen algunas especificidades del proveedor.
¿Puedo migrar aplicaciones existentes a serverless?
Monolitos: difícil a imposible sin re-arquitectura. Microservicios: sí, gradualmente. Recomendación: Construir nuevas características serverless, migrar servicios existentes de manera gradual. Patrón Strangler Fig como estrategia de migración.
¿Qué son los contenedores serverless (Fargate, Cloud Run)?
Contenedores que se ejecutan sin gestión de clústeres. Combinan la flexibilidad de los contenedores (runtime propio, cargas útiles más grandes) con el modelo operativo de serverless (sin gestión de servidores, pago por uso). Para muchas cargas de trabajo, el punto intermedio ideal entre Lambda y Kubernetes.
Fuente de la imagen de portada: Pexels / Steve Johnson
Traducido del original en alemán con inteligencia artificial. La versión alemana es la de referencia.
Selección editorial
cloudmagazinLenovo ThinkCentre M75q Tiny Gen 5: Mini-PC empresarial con AMD PRO y 5 vatios en reposo para Edge y KioskcloudmagazinLa IA serverless está sobrevalorada – aquí está lo que realmente importacloudmagazinQNAP TS-464: NAS de 4 bahías con Docker, HDMI y ranura PCIe – lo que Synology no ofrece en esta clase
