amazon-web-services - home - aws lambda pricing

¿Es posible(o eficiente) ejecutar un back-end completo con AWS Lambda(frente a decir, Elastic Beanstalk)? (4)

Soy relativamente nuevo en el mundo de los servidores, así que discúlpame si algo de esto es básico (y el primer fragmento de texto será para explicar mi lógica para asegurarme de que no tenga fallas). Todas mis preguntas serán en negrita, para que su ayuda sea más fácil :).

He estado investigando y enseñándome algunas de las tecnologías de AWS, y he notado en su Mobile Hub, si quieres lógica en la nube, que solo permiten la configuración "automática" de las funciones de Lambda. Después de leer e investigar, encontré algunos recursos que apuntan a una arquitectura "sin servidor" (que admite la introducción de Lambda). En el pasado, tengo entendido que Elastic Beanstalk se introdujo para ayudar a que la administración del servidor (especialmente para dispositivos móviles) sea significativamente más simple.

Para el desarrollo móvil, hay 2 opciones (obviamente más, pero por simplicidad, aceptaremos):

Configure un Elastic Beanstalk que tendrá al menos 1 instancia ejecutándose las 24 horas del día, los 7 días de la semana y tiene múltiples puntos finales para cada url
Con API Gateway, podemos enrutar fácilmente urls a funciones específicas de Lambda. Con esto, podemos manejar cualquier solicitud (muy parecido a la configuración de una aplicación Elastic Beanstalk).

Todo esto me lleva a creer que un servidor completo de Lambda sería completamente posible y fácil de crear a una fracción del costo de tener un servidor funcionando 24/7. ¿Es eso correcto?

Ahora, suponiendo que lo anterior es correcto, debemos determinar si el uso de Lambda es realmente beneficioso sobre Elastic Beanstalk.

Para servidores simples, podríamos configurar algunas funciones de Lambda y llamarlo un día (y probablemente sea mucho más simple y más barato (al menos para proyectos pequeños) que usar Elastic Beanstalk).

Sin embargo, para servidores más complejos con más URL y conexiones de bases de datos, las cosas se vuelven más interesantes.

Estos son los problemas que veo con el uso de Lambda en la situación anterior

Cada url tendría su propia API Gateway con su propia función Lambda. Si se usa un código o módulos en múltiples funciones, tendríamos que copiar y pegar eso en cada función.
Administrar múltiples funciones de Lambda (y API Gateways) es simplemente más trabajo que administrar un solo proyecto / repositorio / lo que sea que quieras llamar a tu base de código.
Cada función que requiere una conexión DB, tiene que conectarse dentro de la función (es decir, tener una conexión constante dentro de una aplicación Node.js).

La única forma (podría pensar) de evitar los primeros 2 problemas es hacer una función robusta que actúe como un despacho (la función principal toma un parámetro de la API Gateway y determina qué archivo ejecutar dentro de la función Lambda).

¿Hay algún punto importante que me falta para determinar si vale la pena usar Lambda sobre Elastic Beanstalk?

Como ya se señaló por otros, hay algunos beneficios en la ejecución de Lambda vs Elastic Beanstalk o sus instancias autogestionadas EC2.

Costos

Mientras que AWS admite Auto-Scaling para Elastic Beanstalk y EC2. Uno siempre debería ejecutar al menos dos instancias para el comportamiento de failover. Ejecutar dos instancias "nano" como mínimo para conmutación por error cada instancia le cuesta (sin descuentos de instancias reservadas): $ 0.0059 * 24 * 30.5 = $ 4.31 para la VM y $ 0.05 * 8 GB = $ 0.40. Entonces una instancia es $ 4.81 y dos instancias son $ 9.62. Sin embargo, para que AutoScaling funcione, necesita una configuración de Load-Balancer de al menos $ 0.0225 * 24 * 30.5 = $ 16.47 además de eso (ignorando las tarifas de LCU). Load-Balancer puede ser compartido por múltiples servicios. Para este cálculo, simplemente lo dividí artificialmente entre 10 y llegué a la conclusión de que un microservicio con Eleastic Beanstalk o EC2 te costará $ 9.62 + $ 1.65 = $ 11.27.

Entonces, ¿cómo se compara eso con Lambda? Con Lambda paga por llamada y por segundo de Gigabyte. Estoy ignorando los costos de las llamadas ya que son $ 0.20 por cada millón de solicitudes. 1 millón de solicitudes son 0.4 solicitudes por segundo en un mes. Si tiene cargas más altas, también deberá pagar los costos de LCU de Load Balancer. Lambda tiene un precio de $ 0.00001667 por GB-segundo. Elastic Beanstalk y EC2 consumirán partes de los nanos 512 MB de memoria para el sistema operativo y el contenedor. Solo supongo que 256 MB son realmente utilizables. Teniendo dos instancias esto sería 2 * 256 MB / 1024MB * 60 * 60 * 24 * 30.5 = 1317600 GB-segundos. Esta cantidad de GB-segundos le costaría 1317600 * $ 0.00001667 = $ 21.96 dólares. Si bien esto suena más caro, tenga en cuenta que su tráfico probablemente no se distribuye de manera uniforme, por lo que es probable que necesite más instancias, lo que aumenta los costos. Con Lambda solo paga lo que realmente usa.

Escalada

Lambda escala según demanda y como ya dijimos, solo paga lo que realmente necesita en lugar de la línea de base infrautilizada.

Rendimiento impredecible

Una trampa de Lambda es el rendimiento impredecible. Mientras que los contenedores serán reutilizados, necesitan un poco de calentamiento con cada nueva instancia. Las primeras solicitudes generalmente serán lentas especialmente cuando se usa Java. Se supone que Node.js es más ligero durante el inicio, pero más lento durante la ejecución. Por ejemplo, cuando se crea una nueva instancia Java de baja memoria de 128 MB y su Lambda tiene algunas bibliotecas, la primera llamada puede tomar 30 segundos o más. Las instancias se freezed entre las solicitudes. Si la instancia no se usa durante un tiempo, demorará más en reactivarse. El aumento de la memoria puede reducir el tiempo de calentamiento y despertar. Sin embargo, un problema principal puede ser el acceso a fuentes de datos externas. Como las instancias se congelan entre solicitudes, no se admite la agrupación de conexiones adecuada. Si lo haces de todos modos la conexión puede terminar obteniendo conexiones obsoletas. Según la base de datos y la apertura y cierre del controlador, una conexión puede ser bastante costosa.

Otros límites

Como se mencionó anteriormente, la agrupación de conexiones no se admite directamente, lo que puede ser un problema para el acceso a la base de datos o el acceso a otros sistemas en general. Si está utilizando frameworks para acelerar su desarrollo, podrían no ser adecuados para su uso dentro de Lambda.

Los límites que Mark B mencionó ahora se han ido. Hoy en día Lambdas puede funcionar dentro de una VPC. Aunque no conozco una forma oficial de limitar el número de instancias simultáneas, si usa una VPC, puede restringir la subred de direcciones IP disponibles y cada Lambda requerirá una dirección IP para que pueda limitar el número de instancias de Lambda indirectamente.

Buenos casos de uso

Si a uno no le importa demasiado el rendimiento constante, Lambda es barato y escalable. Un ajuste muy bueno es el procesamiento de lotes pequeños.

Consulte el DynamoDB DAX Client para sus funciones lambda. Reduce la latencia de milisegundos a microsegundos si le preocupa la velocidad de conexión a la base de datos.

La pregunta es en realidad FAAS vs PAAS. La arquitectura Lambda / Serverless puede considerarse como una función como un servicio , mientras que Beanstalk cae bajo la plataforma como un servicio .

Ha habido mucha confusión entre FAAS y PAAS. Muchos dicen que FAAS también es un PAAS. Me gustaría señalar las características distintivas entre FAAS y PAAS.

Diga, tengo una aplicación CRUD que tiene operaciones Crear, Leer, Actualizar y Eliminar . Por lo general, una aplicación web recibe más tráfico en la operación de lectura .

+---------------------------------------------+--------------------------------------------------------+ | FAAS | PAAS | +---------------------------------------------+--------------------------------------------------------+ | In case of traffic, it scales that specific | But it scales the whole application, | | function handling the read operation. | a separate auto-scaled instance in case of bean stalk. | +---------------------------------------------+--------------------------------------------------------+ | Pay one and only when your function | Have to pay for atleast a single instance, | | is invoked. | even though there is no traffic. | +---------------------------------------------+--------------------------------------------------------+

Desde mi punto de vista, estos dos puntos diferencian a FAAS, una arquitectura llamada "sin servidor", de PAAS.

Parece que ya lo has descifrado. Tiene razón en que el uso de Lambda en lugar de tener un servidor funcionando las 24 horas del día, los 7 días de la semana puede significar un ahorro de costos significativo. Este artículo hace el reclamo:

Y está ahorrando grandes cantidades de dinero a algunos de los clientes de Amazon, con al menos un cliente feliz de Lambda que ahorra el 80% de sus facturas en la nube.

Es posible que desee ver el Framework Serverless que gestiona algunos de los puntos débiles.

Creo que con el tiempo muchos de los puntos negativos desaparecerán, ya que Amazon agrega más características a Lambda y se crean más herramientas de terceros. Constantemente estoy descubriendo nuevos usos para Lambda, pero también estoy descubriendo constantemente usos que parecen ser una buena opción al principio, pero que realmente no funcionan en Lambda, al menos no todavía. Por ejemplo, realmente necesito alguna manera de limitar el número de instancias de una función Lambda que se puede ejecutar simultáneamente para evitar que se maximicen las conexiones de bases de datos disponibles o alcanzar los límites de uso en las API de terceros. También realmente necesito que las funciones de Lambda se ejecuten dentro de mi VPC, pero se supone que llegará muy pronto.