Serverless es una estafa: simplemente usa un contenedor
(sliplane.io)- Serverless parece conveniente, pero en la práctica es una arquitectura que provoca complejidad, restricciones y costos altos
- Los contenedores ofrecen portabilidad, persistencia de estado y control claro, y son más adecuados para la mayoría de los casos de uso
- Serverless tiene una estructura de costos opaca e impredecible, y genera complejidad innecesaria entre componentes
- La escalabilidad y simplicidad de serverless solo encajan en casos de uso limitados
- En entornos reales de operación, el despliegue basado en contenedores es más simple, escalable y rentable
Serverless Is a Scam. Just Use a Container.
¿Qué es serverless?
- Serverless consiste en desplegar código a nivel de funciones individuales, mientras la plataforma en la nube se encarga automáticamente de la ejecución y el escalado
- Sin embargo, en la práctica existen los siguientes problemas
- Límite de tiempo de ejecución (por ejemplo, AWS Lambda tiene un límite de 15 minutos)
- Imposibilidad de mantener estado (se reinicializa en cada ejecución)
- Problema de cold start
- Entornos imposibles de depurar
- Configuración y ajustes específicos de cada plataforma
- Uso excesivo de YAML
- Aunque parece simple, no es adecuado para tareas complejas
Contenedores: simples, potentes y aburridos en el buen sentido
- Los contenedores tienen las siguientes ventajas
- Inicio rápido
- Pueden ejecutarse en cualquier entorno
- Permiten mantener estado (usando
Docker volume) - Sin límite de tiempo de ejecución
- Libertad para depurar, desarrollar localmente y cambiar entre entornos de operación
- Código de ejemplo:
docker run -v my-data:/data my-app - Como resultado, es posible ejecutar de forma consistente cargas de trabajo con estado en cualquier lugar
- Sin dependencia del proveedor, sin costos ocultos y sin cambios estructurales innecesarios
Precios de serverless: diseñados para confundir al usuario
- Los costos de serverless están compuestos de forma muy compleja
- Costo por invocación
- Uso de memoria
- Tiempo de ejecución
- Cantidad de datos transferidos
- Diferencias por región
- Costo de acceso a claves secretas, etc.
- Ejemplos de términos confusos:
- Provisioned Concurrency Units
- GB-seconds
- Requests Tier 1/2/3
- Debido a una estructura de cobro impredecible, pueden llegar facturas inesperadas
- Comparación: un VPS de $5 ofrece una tarifa fija predecible con control total sobre todos los recursos
Réplica a “serverless escala”
- Serverless es técnicamente escalable, pero en la práctica la mayoría de las apps no lo necesitan
- Lo que la mayoría de las aplicaciones realmente necesita es lo siguiente
- Predictibilidad
- Capacidad de monitoreo
- Límites adecuados de recursos
- Entornos de desarrollo y staging
- En un enfoque basado en contenedores, escalar también es simple
replicas: 5 - O bien, es posible escalar horizontalmente usando un balanceador de carga
El diseño sin estado crea problemas artificiales
- Serverless obliga a un diseño necesariamente sin estado
- No permite caché, sesiones, archivos temporales ni conexiones persistentes
- Como resultado, se necesitan estos elementos
- Base de datos externa
- Caché distribuido
- Almacenamiento de archivos
- Bus de eventos
- Máquina de estados
- Al final, una app serverless “simple” termina teniendo más de 6 dependencias SaaS
- En cambio, con contenedores es posible
- Caché en memoria
- Escritura en disco
- Mantener sesiones
- Ejecución sin límite
Respuesta a “no quiero administrar servidores”
- Existen formas de usar plataformas basadas en contenedores sin administrar servidores
- Usar plataformas como Sliplane, Railway o Coolify
- O simplemente usar Docker + systemd en un VPS
- Se garantiza comodidad operativa con despliegue basado en Git, rollback, logs, métricas, etc.
- También es posible entender y controlar todo el sistema
Réplica a la afirmación de que “serverless es más barato”
- Puede ser barato con una frecuencia de invocación extremadamente baja
- Pero en las siguientes situaciones, los costos se disparan
- Cuando el tráfico supera cierto nivel
- Cuando se necesita más memoria
- Cuando hay mucha computación real
- Cuando hay mucha transferencia de datos
- Como la plataforma oculta todo, en serverless es difícil optimizar
- En cambio, los contenedores
- Pueden ejecutarse de forma continua incluso en hardware barato
- Pueden combinarse con caché y almacenamiento
- Son fáciles de medir y ajustar
- No tienen cobro por milisegundo
Cuándo sí tiene sentido serverless
- Es adecuado para trabajos intermitentes y sin estado como los siguientes
- Funciones basadas en eventos (por ejemplo, redimensionar imágenes)
- Tareas que se ejecutan rara vez o webhooks
- Herramientas internas
- POC
- Casos donde se necesita escalar rápidamente hacia arriba o hacia abajo
- Sin embargo, en aplicaciones reales se topa con límites, y
- se termina pagando un precio alto en tiempo, costo y complejidad
Por qué los contenedores son una mejor opción
- Los contenedores ofrecen lo siguiente
- Portabilidad
- Control
- Simplicidad
- Transparencia
- Flexibilidad
- Permiten despliegue con uno o varios contenedores, escalado, mantenimiento de estado, trabajos en segundo plano e integración con bases de datos
- También es posible cambiar de plataforma sin reescribir el código
Resumen (TL;DR)
- Serverless se ve genial en teoría
- En la realidad es:
- Opaco
- Costoso
- Excesivamente complejo
- Sobrevendido
Antes de empezar, pregúntate:
“¿No podría hacer esto simplemente con un contenedor?”
- Si la respuesta es “sí”, empezar con contenedores es una mejor elección
Acciones recomendadas a continuación
- Se recomienda compartir casos en los que serverless haya provocado costos inesperados o flujos de trabajo ineficientes
- No compliques en exceso problemas simples
19 comentarios
Pero existe xfaas... y también están cf workers. Me parece que es un artículo sesgado.
Estaba pensando en ejecutar algo por un rato como una función serverless al alquilar una GPU.
¿Eso también se puede hacer con contenedores?
En los antiguos servicios de web hosting para PHP, si le quitas PHP y le metes bastante JS con mucho vendor lock-in....
no puedo evitar pensar que sería difícil distinguirlo de las plataformas FaaS serverless más representativas.
Claro, como yo soy un auténtico sibarita de porquerías que usa principalmente PHP y JS/TS, la verdad es que lo aprovecho con gusto,
pero aun así no termino de entender por qué tanta gente dice que esto sabe tan bien.
En mi opinión personal, usar servicios serverless de un proveedor es arriesgado, pero ofrecer internamente un entorno serverless en la propia empresa usando contenedores me parece una buena idea. Creo que sería bueno aprovechar lo serverless no como un servicio, sino como un concepto.
Hace un tiempo estuvieron muy en tendencia un tuit y un video sobre haber renunciado al Edge rendering de Vercel[1], y también un artículo sobre un serverless server (jajaja)[2]. Creo que comparto una postura parecida a la de los textos que salieron en ese momento.
Es una opinión personal, pero desde la perspectiva de un desarrollador frontend, creo que poner una serverless function en las solicitudes del usuario sigue siendo algo lejano por ahora (a menos que la aplicación que quieres hacer sea un MVP).
[1] https://youtu.be/lAGE-k1Zfrg
[2] https://vercel.com/blog/…
[2-1] https://bobaekang.com/blog/…
Claro, parece que, como también mencionaron en esta publicación, es un texto bastante provocador hecho para llamar demasiado la atención :(
Desde la perspectiva de alguien que ha trabajado tanto con entornos basados en contenedores (principalmente ECS Fargate y clústeres de Kubernetes) como con entornos serverless (AWS), no me resulta algo tan convincente.
Los puntos enumerados como ventajas de los entornos basados en contenedores son, a la vez, aspectos que también pueden convertirse en desventajas.
Todas esas partes mencionadas como “se pueden controlar directamente y pueden tener estado” terminan siendo puntos de gestión que elevan la dificultad operativa, por decirlo de alguna manera.
Yo recomendaría fuertemente serverless, sobre todo, a organizaciones pequeñas o a organizaciones que no cuentan con un equipo especializado en administración de servidores.
Ah, sí coincido en que el cálculo de costos es complicado o difícil de prever, y también en el problema del vendor lock-in.
Como alguien mencionó la experiencia de desarrollo y la observabilidad, quisiera agregar algo:
Si desde el inicio se configura bien el entorno de integración, se puede lograr una experiencia de desarrollo tan buena como la basada en contenedores, o incluso más cercana a lo nativo que una basada en contenedores. (Y hay varias herramientas para hacerlo)
En cuanto a la observabilidad, si se quiere hacer a fondo, ni el serverless ni el enfoque basado en contenedores son un problema fácil de resolver. Centralización de logs, visualización de distintas métricas, APM, visualización del uso de CPU/memoria y definición de estrategias de escalado en función de eso, etc.
Si no se está en ese nivel, la integración de métricas/logs que ofrece por defecto el proveedor de nube es bastante potente, así que al final es más o menos lo mismo.
Dicho de forma agresiva, me dan ganas de preguntar: "¿Hasta qué punto han usado serverless de verdad?" 😅
A veces también pienso que quizá sería mejor levantar en Lambda solo algunos endpoints necesarios. Desde el principio, yo no tengo experiencia desarrollando con serverless, así que no puedo opinar mucho, pero sí parece que podría ser bueno para algunos casos especiales.
¿No será que la empresa que escribió este artículo lo hizo desde una perspectiva sesgada porque es una compañía de plataformas de hosting de contenedores? jaja
Antes también hubo quienes dudaron del post de un desarrollador de Netlify (la competencia) que expresaba preocupaciones sobre nextjs (vercel) desde el lado del frontend, ¿no? Viendo los comentarios, no parece que esté sesgado.
Yo soy más del lado del frontend, así que... no estoy muy metido en esta área, pero sí siento que he visto seguido el meme de "serverless (sí hay servidores)" jaja.
La experiencia de desarrollo es notablemente peor que la nativa, y ese es un pain point demasiado grande; además, como el software mismo termina teniendo dependencia del proveedor de infraestructura, una vez que se asienta se vuelve difícil escapar. Ni hablar de que hay claramente menos referencias, y la observabilidad es demasiado baja.
Cloudflare parece ser, dentro de todo, la que más está intentando hacer bien el serverless en comparación con otras empresas. La base de datos también es serverless, el almacenamiento key-value también es serverless, e incluso hay colas de mensajes serverless...
(Por supuesto, cuando esto pasa, también da rechazo porque se siente como quedar completamente atado y restringido por la plataforma)
Aun así, si no mejoran la depuración, la observabilidad y la experiencia de desarrollo, seguirá siendo más de lo mismo.
usen Cloud Run
Operar un servicio con serverless es elegir la herramienta equivocada.
Hay problemas específicos para los que sí se necesita serverless. Es adecuado para usos esporádicos.
¿También pensarán lo mismo de los servicios de contenedores serverless?
Por los problemas de los servicios serverless tradicionales (como Lambda), AWS creó Fargate y luego incluso hizo App Runner para simplificarlo más 🤔
Incluso está Cloud Run de Google Cloud, un servicio de contenedores serverless buenísimo con
scale to zeroPersonalmente, de todos esos, Cloud Run fue el que me dio la mejor experiencia de desarrollo
Sin servidor (sí hay servidores)
Opiniones en Hacker News
libcDesde el principio no era Severless, sino Serverlease.
jajajaja