Casos de terror de la tecnología serverless

 (serverlesshorrors.com)
2 puntos por GN⁺ 2024-03-01 | 1 comentarios | Compartir por WhatsApp
  • Es un sitio que reúne y muestra, con casos reales, el riesgo de explosión de costos oculto detrás de la comodidad de la facturación por uso
  • Permite comparar cobros inesperados ocurridos en Cloudflare, Vercel, AWS, Firebase, Netlify, BigQuery y otros, según el servicio y la causa
  • Incluso proyectos pequeños o servicios personales pueden terminar en cargos altísimos en un instante, como una factura de $36,000 en Cloudflare, $46,485.99 en Vercel o $100,000 en Firebase en un solo día
  • Las causas recurrentes son ancho de banda, DDoS/DoS, almacenamiento, implementaciones incorrectas, recursión, loops en colas y aumentos de uso relacionados con eventos, imágenes, documentación y AI
  • Al usar servicios serverless y de pago por consumo, hay que revisar antes y después del despliegue los límites de gasto, caché, patrones de solicitudes y loops de automatización

Naturaleza del sitio y cómo enviar casos

  • ServerlessHorrors es un blog sencillo donde se pueden leer casos de cobros excesivos o incidentes ocurridos durante el uso de servicios serverless
  • Su creador es Andras, y trabaja en varios proyectos open source como Coolify, Jean y otros relacionados con coolLabs
  • Reciben reportes de casos por dos vías

Casos representativos que terminaron en facturas enormes

  • $36,000: el side project RetainDB, con 81 usuarios, recibió una factura de $36k de Cloudflare
    • Las causas fueron 16B Durable Object writes, un runaway queue loop, Durable Object writes sin agrupar y un KV list scan ejecutado en cada request
    • Etiquetas: cloudflare, workers, durable-objects, kv, queues
  • $46,485.99: Jmail superó los 450M pageviews y, incluso después de varias mitigaciones de caché, la factura de Vercel subió a $46k
    • Etiquetas: vercel, bandwidth
  • $100,000.420: un sitio para subir juegos WebGL con cierta popularidad sufrió un DoS y su factura diaria de Firebase llegó a $100k
    • Etiquetas: google, storage, firebase
  • $120,000.420: caso en el que Cloudflare intentó exigir un pago de $120k en menos de 24 horas y luego bajó el sitio web
    • Etiquetas: cloudflare, bandwidth
  • $104,500.123: caso de alguien que recibió un email de Netlify por una factura vencida de $104,500.00
    • Etiquetas: netlify, bandwidth, ddos
  • $96,280.69: caso de una factura elevadísima relacionada con bandwidth en Vercel
    • Etiquetas: vercel, bandwidth, new
  • $72,000.999: un test con Firebase + Cloud Run quemó $72K y casi llevó a la quiebra a su autor
    • Etiquetas: google, firebase, cloudrun, wrong-implementation, recursion
  • $70,000.69: un proyecto que pagaba $50 al mes recibió un día una factura de $70,000
    • Etiquetas: google, storage, firebase, gcs

Casos adicionales recopilados por servicio

  • $23,000.420: EchoFox recibió spam, la factura de Vercel se disparó a $23k y se generaron 56k+ accounts and trials
    • Etiquetas: vercel, bandwidth, ddos
  • $22.639,69: solo por usar un dataset público en BigQuery playground, alguien recibió un cobro de 22k USD
    • Etiquetas: google, bigquery, sql
  • $11,000.69: durante un ataque DoS se enviaron emails por un valor de $11k y se perdió la base de datos
    • Etiquetas: ddos, mailgun
  • $4,241.69: caso de alguien que pausó su servicio, pero AWS lo bloqueó y exigió el pago
    • Etiquetas: aws
  • $3,000.69: un caso que advierte sobre tener cuidado al probar o desplegar en Vercel
    • Etiquetas: vercel, bandwidth, wrong-implementation
  • $1,300.69: se generaron costos tras crear un bucket privado y vacío de AWS S3 en la región deseada
    • Etiquetas: aws, s3, security, ddos
  • $1273.69: se generaron costos en PostHog después de pedirle a Devin AI que modificara el codebase
    • Etiquetas: posthog, devin, ai, cognition-labs, new
  • ~$1189.420/month: en un plan de $69/month, Webflow cobró $1189.420 en un solo mes
    • Etiquetas: webflow, bandwidth, image
  • $738.420: aunque alguien se suscribió a Vercel Pro por $20 al mes y agregó un spending limit de $120, igual recibió cargos
    • Etiquetas: vercel, bandwidth, vercels-mistake, spending-limit
  • $620.123: caso en Vercel donde sitemap.txt consumió cientos de GB/hours
    • Etiquetas: vercel, bandwidth
  • $530.19: caso de PostHog donde nunca se había pagado nada y de pronto llegaron cargos por $530
    • Etiquetas: posthog, events, new
  • $400.69: Cloudflare Images cobró $400 al mes en lugar de los $110 esperados, con facturación prepaga confusa y más de 8 meses sin soporte
    • Etiquetas: cloudflare, images, billing
  • $383.69: caso de Mintlify con un cobro de casi $400 por un sitio de documentación
    • Etiquetas: mintlify, ai, documentation
  • $250/month: 9,000 visitas de página terminaron requiriendo $250 al mes, o $3,000 al año
    • Etiquetas: framer, bandwidth, images and videos
  • $103.26: un caso de AWS donde un uso dentro del free tier terminó convertido en una historia de terror por $103
    • Etiquetas: aws, dark-pattern, free-tier

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-03-01
Opiniones en Hacker News

  • Es una verdadera lástima y, de hecho, se siente como un retroceso. Un archivo de 3.44 MB no debería ser un problema y, aunque lo fuera, “súbelo a otro lado” no debería ser la respuesta.
    Si hay algo que aprender aquí es que nada es gratis, y pérdidas grandes como esta deberían poder evitarse de alguna forma imponiendo límites. Un VPS es muy barato y fácil de administrar, y también tiene límites automáticos: https://lowendbox.com/blog/1-vps-1-usd-vps-per-month/

    • La gente se pregunta por qué ahora quedan tan pocos sitios web y desapareció la larga cola, y es porque en Facebook o Twitter puedes subir un audio de 3.44 MB sin tener que preocuparte jamás por que te cobren.
    • Decir que un VPS es “fácil de administrar” es una opción bastante fuerte que presupone muchas cosas.

  • No creo que el caso de Netlify haya ocurrido por la arquitectura serverless. Serverless tiene muchos problemas técnicos, pero el problema de recibir una factura enorme por el tráfico entrante es independiente de serverless.
    Si colocas tu propio equipo en colocation y pagas costos de tráfico, podría pasar lo mismo si el centro de datos no te protege contra DDoS y te cobra por TB. Claro que en colocation el precio por TB es mucho más barato que en Netlify, así que es menos probable terminar con una factura de 100 mil dólares, pero entonces el punto no debería ser el “terror serverless”, sino los costos de tráfico absurdamente caros y la falta de mitigación de DDoS.

    • Si el servicio escala infinitamente, la velocidad a la que se quema el dinero también escala infinitamente. En colocation, un solo servidor se satura, y el daño que puede hacerle a tu billetera también queda limitado.

  • Andres, quien creó este blog, también está creando coolify, una alternativa self-hosted a Heroku/Netlify. Tras usarlo durante varios meses, fue como ese ingrediente secreto que facilita hacer self-hosting de cosas como changedetector, jdownloader y vaultwarden.
    La comunidad también está creciendo bastante bien: la gente contribuye nuevas plantillas y se ayuda mutuamente a depurar. Yo también probé agregar una plantilla de Syncthing. Eso sí, cuando se llenó el disco en una instancia con 10 GB de almacenamiento, varias cosas empezaron a romperse; ojalá mejoren las alertas o la prevención en ese punto. Fuera de eso, es bastante estable.
    https://github.com/coollabsio/coolify

  • Tal vez sea una reacción exagerada, pero decidí mover mi sitio personal fuera de Netlify. No necesitaba más que un lugar donde dejar HTML, y pensaba que Netlify era “suficientemente bueno”, pero no sabía que existía este problema.
    El sitio afectado recientemente se parece al mío en visitas diarias, nivel de reconocimiento y carácter de nicho, así que se sintió más real. Prefiero compilar el HTML localmente y subirlo a algún lado, así que migrarlo debería bastar con actualizar el DNS. Lo raro fue que la mayoría de las opciones populares como Netlify, Vercel y Cloudflare no ofrecen realmente límites de gasto. Parece una función demasiado básica.

    • Cloudflare Pages tiene ancho de banda gratuito ilimitado, así que el tráfico es gratis y por eso no hace falta un límite.
    • Trabajo en Vercel, y Vercel tiene protección contra DDoS y límites de gasto. Estamos trabajando para anunciar pronto mejoras adicionales para ambas cosas.
      https://vercel.com/blog/introducing-spend-management-realtime...
    • Cloudflare tiene protección contra DDoS y se puede configurar a un nivel casi paranoico. Si empieza un DDoS, puedes hacer que a todos les aparezca un CAPTCHA, lo que limita el gasto de forma bastante efectiva.

  • También vale la pena ver el hilo de comentarios de Netlify enlazado en uno de los posts de Reddit: https://answers.netlify.com/t/limit-bandwidth-to-avoid-high-...
    Un representante de Netlify dice explícitamente que, aunque estés en el nivel gratuito, si sufres un DDoS no harán nada para evitar una factura absurda de ancho de banda.

    • Lo que menos me gusta de estos servicios es que no tienen una función equivalente a un stop loss. Si configuras alertas, te avisan, pero eso es todo, y en muchos casos la alerta llega bastante tiempo después de que el daño ya ocurrió.
      Algunas métricas de facturación incluso tienen reportes o alertas con varias horas de retraso. Los valores predeterminados deberían ser seguros, y aumentar los límites debería ser fácil.
    • Antes simplemente bajaban el servidor; ahora la estructura es que tu sitio serverless recibe un DDoS y te llega una factura de 100 mil dólares.
      No sé si este modelo de negocio es sostenible. En la época en que uno era dueño del servidor, podías desconectar el enchufe; ahora no hay forma de saber si alguien va a llamar a /api un millón de veces por minuto.
    • ¿No se podría usar el nivel gratuito con un nombre falso y dejar tirada una factura absurda? Me pregunto cómo verifican a los clientes.
    • Me pregunto si esto ocurre porque Netlify está teniendo problemas de financiamiento. Antes Netlify era un servicio muy bueno y único, pero ahora GitHub, GitLab y Cloudflare Pages ofrecen casi el mismo servicio por menos.
    • Si esto pasa en el nivel gratuito, ¿qué se supone que hay que hacer? ¿Simplemente no pagar la factura e irse? ¿De verdad vendrán a cobrarla?

  • Que un proveedor de nube cobre de más por algo que tiene derecho a facturar se siente parecido a que un mecánico, durante una revisión routine, diga que se rompió una pieza pequeña y que, por la misma razón, los repuestos también se siguen rompiendo, así que los cambia en un bucle infinito sin darme ninguna información durante 2 semanas, y al final, cuando voy al taller y le digo que pare, me cobra el costo de 999,999,999 piezas rotas.
    Como usuario pequeño, no una gran organización, no puedo leer toda la documentación de controles de cada rincón. Quiero un límite fijo que, al llegar a un tope de gasto definido, mate todo, incluso si eso implica perder datos si hace falta. Pero si los usuarios cuidan su presupuesto, eso perjudica los ingresos, y también hay casos en los que es difícil calcular de antemano el monto a facturar, así que parece que por eso no lo ofrecen.

    • Hay una diferencia. El mecánico del ejemplo creó la situación él mismo, pero Netlify no, y quizá sea difícil distinguir entre tráfico no deseado y un SaaS que tuvo éxito de la noche a la mañana.
      Una analogía más precisa sería que alguien le dijo al mecánico que hiciera cualquier cosa que le pidiera quien conociera el número de placa, y el mecánico simplemente lo hizo.

  • Hace poco creé una clave de la API de OpenAI, y por defecto impone una cuota y desactiva la clave cuando se alcanza el límite. Cuando el usuario está listo para procesar más solicitudes, aumenta manualmente la cuota.
    Me sorprende que más empresas no hagan esto por defecto para evitar estas facturas sorpresa. Pensándolo bien, quizá sea porque al final muchas veces el usuario simplemente paga.

    • La diferencia es que OpenAI sí incurre en costos reales de inferencia, así que tiene intereses en juego. Cuando Netlify cobra 1000 veces más por el ancho de banda, el costo de prestar el servicio es casi nulo, así que puede que realmente no le importe mucho si el usuario no paga.

  • Creo que el mayor horror de la nube quizá no sea lo serverless, sino que hayamos aceptado pagar costos de tráfico entre zonas de disponibilidad con el argumento de prepararnos por si el proveedor de nube falla.
    En otras palabras, el proveedor está cobrando bastante por mitigar problemas que él mismo podría tener.

  • En este hilo todos dicen que esto no es un problema de serverless sino de la nube, y es cierto, pero el punto central sigue en pie. El ancho de banda es casi margen puro, y cobrar tan caro por ancho de banda sin dar herramientas para responder a ataques fuera del control del cliente se ve bastante turbio.
    Según este hilo, Netlify ni siquiera ofrece la opción de bajar temporalmente un sitio durante un ataque DDoS: https://answers.netlify.com/t/limiting-bandwidth-traffic-to-...
    Netlify podría tener varias soluciones: controles de facturación, limitación de solicitudes, límites de ancho de banda, exención de excedentes si es un DDoS real, etc., pero parece no interesarle porque sería matar a la gallina de los huevos de oro. Basta ver las funciones que ofrece el CDN de bunny.net para comparar: https://support.bunny.net/hc/en-us/articles/360014190440-Und...
    Es decepcionante que aceptemos con tanta facilidad algo que, en las explicaciones de los proveedores de nube, cuesta explicar como algo que no sea codicia.

  • ¿Por qué que no haya un límite de gasto sería un problema de serverless? Eso es un problema de la nube.
    Dicho eso, si es un servidor cloud pequeño, puede caerse al recibir un ataque, y si, como AWS, solo cobra el tráfico saliente, eso juega a favor del usuario.

    • Porque serverless usa con más frecuencia facturación basada en uso que los modelos tradicionales, y escala mejor hasta volúmenes de uso masivos.
      Aunque hagan DDoS a mi VPS de DigitalOcean de 5 dólares al mes, el costo de cómputo no aumenta, y es muy probable que colapse por no soportar la carga antes de que los costos de transferencia se acumulen demasiado. La transferencia en DigitalOcean también se basa en uso, pero llegará a su límite antes de eso.
    • Esto no es un problema de la nube. La nube, al final, solo es la computadora de otra persona.
      Esto es un problema de facturación o de arquitectura. Deberían permitir limitar solicitudes para evitar sobrecargos, o cortar el servicio al llegar a un monto determinado.
    • Esto es una falla de arquitectura. Definir máximos es importante. Si eliges una plataforma que no admite esa función, también tienes parte de responsabilidad.
      En entornos tradicionales es implícitamente más fácil poner interruptores de circuito, pero aun así hay que considerarlo siempre. Hay que hacer pruebas de carga tanto para escenarios de éxito como de falla.
    • La razón por la que no tener un límite de gasto es un problema de serverless es que, si usas la nube, puedes mitigarlo, pero en serverless no.
      Yo uso instancias cloud y no tengo este problema ni lo tendré. Si hubiera usado serverless, sí lo habría tenido.