Historias sin servidor de Halloween — Parte 1
Halloween — La mayoría de nosotros, que trabajamos sin servidor, lo encontramos insustituible. Hay tantas ventajas en las que estamos enganchados hoy en día, que es difícil volver atrás.
Sin embargo, algunas personas, en su búsqueda de una aplicación Serverless exitosa, han visto su lado oscuro… 🎃
La creación de una aplicación sin servidor puede ser bastante ordenada y puede darnos la falsa impresión de una curva de aprendizaje muy baja. Pero recuerde, está desarrollando una aplicación que se implementa en la plataforma computacional/de almacenamiento más potente que jamás haya existido en el planeta.
Teniendo en cuenta que estás pagando por lo que usas, y si lo estás desperdiciando, puede ser extremadamente costoso…
Déjame contarte algunas historias muy propias de Halloween que basadas en hechos reales…
Algunos de ellos dan mucho miedo, así que asegúrate de no leerlos antes de dormir y menos en la noche de Halloween…
Es posible que se encuentre revisando la(s) cuenta(s) en medio de la noche.
Historia 1: Concienciación sobre los costos más caros
Un amigo mío y su equipo estaban trabajando en algunas aplicaciones Serverless para una startup. El cliente estaba muy preocupado por los costos, ya que están muy ajustados con el presupuesto.
Decidieron crear una herramienta de informes para que el cliente pueda saber en cualquier segundo cuánto costo se crea. El cliente estaba abrumado por la idea de tener un informe de los costos cada vez que revisa.
Saben que AWS Cost Explorer es el servicio que necesitan. Tiene la API adecuada y parece que tienen exactamente lo que necesitan. Junto con el cliente, decidieron que los informes de Slack serían muy fáciles de integrar y estarían disponibles tanto para las partes interesadas como para el equipo.
Así que… bastante fácil… ¡cualquiera podría hacerlo!
El equipo comenzó a desarrollar…
Todo salió tan bien que la API se explicaba por sí misma y funcionó como se esperaba. Slack también fue muy fácil de integrar, con solo una solicitud POST. Se va a hacer en un par de horas para que el equipo pueda pasar un fin de semana largo relajado ☀️🏖
Un desarrollador tuvo una idea increíble, informar solo cuando hay cambios en los costos, no molestar cada pocos minutos.
Llamaron a la API de Cost Explorer con mucha frecuencia (no digo que la hayan puesto en un bucle 🤣) y luego la compararon con el estado anterior.
Nadie necesitó ninguna documentación, todo fue muy fácil.
Lo desplegaron y se fueron a pasar un fin de semana largo para relajarse y disfrutar del hermoso verano…
Nadie comprobó la holgura durante unos días.
El cliente ni siquiera instaló Slack… 🤣
Cuando regresaron a la oficina, la voz un poco perturbada del cliente les notificó amablemente que la factura del fin de semana aumentó en 8000 $ y que sus facturas mensuales estaban en un promedio de 50 $ – 70 $. Eso los despertó mejor que cualquier película de terror anterior.
¡Después de algunas investigaciones, se dieron cuenta de que están usando servicios pagos! Cuando llama a una determinada API en AWS, tiene su precio.
El precio de API Cost Explorer es de 0,01 $ por solicitud.
Imagínate si llamas a ese servicio en bucle y lo dejas unos días, para darte cuenta de que ese servicio se actualiza una o dos veces al día 🤣
Afortunadamente, AWS redujo significativamente ese costo, por lo que, al final, todo salió bien. Pero quedó plantado en el cerebro del desarrollador para verificar los precios antes de que comenzaran a usar cualquier servicio de AWS sin cuidado.
Historia 2: Biblioteca maliciosa de terceros
Todos quieren hacer su trabajo lo más rápido posible. Entonces, nosotros, como desarrolladores, tendemos a usar bibliotecas para acortar nuestro tiempo de desarrollo. Sin embargo, además de que las bibliotecas tienen errores, también pueden ser maliciosas.
Esto no es realmente una historia, sino más bien un aviso. Entonces, supongamos que usa una biblioteca que envuelve algunas API y crea un SDK o algún algoritmo que, de lo contrario, tendría que implementar usted mismo.
Sin embargo, esa biblioteca podría hacer el trabajo perfectamente pero, por otro lado, también podría ser malicioso. Puede llevar algún código que, por ejemplo, extrae alguna criptomoneda.
Eso podría ser un problema muy grande en caso de que su aplicación se escale mucho. Puede proporcionar parte de su poder de procesamiento para el interés de alguien, pero es posible que no sea consciente de ello.
Aquí hay un ejemplo de lo fácil que esto puede suceder. Supongamos que usa nodejs y lo ha declarado en su package.json
"dependencies": { "some_dep": "^1.0.0", "another_dep": "~2.2.0" }
Entonces, digamos que revisó por completo some_dep 1.0.0 y está convencido de que hace exactamente lo que necesita que haga.
Pero…. Los chicos que desarrollaron some_dep 1.0.0 tienen intenciones maliciosas. Así que vieron que tienen tantas descargas y tanta gente está usando la biblioteca.
Deciden actualizar la versión con some_dep 1.0.1 indicando que es una corrección de errores en el registro de cambios. La próxima vez que cree una nueva versión de su aplicación, incluirá un código malicioso.
En el archivo package.json, indicó que está de acuerdo con la actualización para el lanzamiento del parche (^) o el lanzamiento menor (~). Eso puede dejar una puerta abierta para posibles ataques.
En esencia, debe conocer las bibliotecas que considere convenientes para su aplicación y asegurarse de que estén desarrolladas por algún editor confiable y conocido.
Continuará…
Habrá más historias hasta Halloween, así que prepárate para más cosas aterradoras… 👻
Gracias por llegar hasta aquí, si encuentras esto útil no olvides aplaudir 👍🏼suscribirse para recibir más contenido.
Si necesita ayuda adicional, por favor contácteme.
Si le interesa, puede echar un vistazo a algunos de los otros artículos que he escrito recientemente sobre AWS y Laravel: