Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Uso de .NET sin servidor

Descripción general de

La computación sin servidor se convirtió en una estrategia popular para crear e implementar aplicaciones. Esto se debe principalmente a la escalabilidad y la agilidad que ofrece la estrategia sin servidor a la hora de crear una arquitectura moderna. Sin embargo, es importante tener en cuenta el impacto en los costos de la computación sin servidor en algunos escenarios.

Lambda es una plataforma de computación sin servidor que permite a los desarrolladores usar código sin necesidad de servidores dedicados. Lambda es una opción particularmente atractiva para los desarrolladores de .NET que buscan reducir los costos asociados a la infraestructura. Con Lambda, los desarrolladores de .NET pueden desarrollar e implementar aplicaciones que son altamente escalables y potencialmente rentables. Al utilizar una estrategia sin servidor, los desarrolladores ya no aprovisionan servidores para gestionar las solicitudes de las aplicaciones. En su lugar, los desarrolladores pueden crear funciones que se pongan en marcha bajo demanda. Esto hace que una estrategia sin servidor sea más escalable, administrable y potencialmente más rentable que usar, administrar y escalar máquinas virtuales. Como resultado, solo paga por los recursos utilizados por la aplicación, sin tener que preocuparse por los recursos que no se usan lo suficiente o los costos derivados del mantenimiento del servidor.

Los desarrolladores pueden usar versiones modernas de .NET multiplataforma para crear aplicaciones sin servidor que sean rápidas, eficientes y rentables. .NET Core y las versiones más recientes son un marco gratuito y de código abierto ideal para plataformas sin servidor que las versiones anteriores de .NET Framework. Esto permite a los desarrolladores reducir el tiempo de desarrollo y aumentar el rendimiento de las aplicaciones. Las versiones modernas de .NET también son compatibles con varios lenguajes de programación, como C# y F#. Por este motivo, es una opción atractiva para los desarrolladores que desean crear arquitecturas modernas en la nube.

En esta sección se explica cómo puede ahorrar costos usando Lambda como opción sin servidor. Para optimizar aún más los costos, puede refinar los perfiles de ejecución de sus funciones de Lambda, dimensionar correctamente la asignación de memoria de sus funciones de Lambda, utilizar la compilación nativa anticipada y comenzar a usar funciones basadas en Graviton.

Impacto del costo

La medida en que pueda reducir los costos depende de varios factores, como el número de ejecuciones que ejecutarán sus funciones sin servidor, además de la cantidad de memoria asignada y la duración de cada función. AWS Lambda ofrece una capa gratuita, que incluye un millón de solicitudes gratuitas al mes y 400 000 GB por segundo de tiempo de procesamiento al mes. Puede reducir considerablemente los costos mensuales de las cargas de trabajo que se encuentren en los límites del nivel gratuito o próximos a ellos.

El uso de un equilibrador de carga con funciones de Lambda como destino también puede suponer costos adicionales. Esto se calcula como la cantidad de datos procesados por el equilibrador de carga para los destinos de Lambda.

Recomendaciones de optimización de costos

Dimensionamiento correcto de las funciones de Lambda

El dimensionamiento correcto es una práctica esencial para la optimización de costos en las funciones de Lambda basadas en .NET. Este proceso implica identificar la configuración de memoria óptima que proporcione un equilibrio entre rendimiento y costo, sin necesidad de cambiar el código.

Al configurar la memoria para una función de Lambda, que va desde 128 MB hasta 10 240 MB, también se ajusta la cantidad de vCPU disponible durante la invocación. Esto permite que las aplicaciones vinculadas a la memoria o a la CPU accedan a recursos adicionales durante la puesta en marcha, lo que se traduce en una posible reducción de la duración de la invocación y del costo total.

Sin embargo, identificar la configuración óptima para las funciones de Lambda basadas en .NET puede ser un proceso manual y laborioso, especialmente si los cambios son frecuentes. La herramienta AWS Lambda  Power Tuning puede serle de ayuda a la hora de identificar la configuración adecuada, pues analiza un conjunto de configuraciones de memoria y las compara con un ejemplo de carga útil.

Por ejemplo, aumentar la memoria de una función de Lambda basada en .NET puede mejorar el tiempo total de invocación y reducir los costos sin repercutir en el rendimiento. La configuración de memoria óptima de una función puede variar. La herramienta AWS Lambda Power Tuning puede ayudar a identificar la configuración más rentable para cada función.

En el siguiente gráfico de ejemplo, el tiempo total de invocación mejora a medida que aumenta la memoria de esta función de Lambda. Esto se traduce en una reducción del costo total de la puesta en marcha sin que ello repercuta en el rendimiento original de la función. En esta función, la configuración de memoria óptima es de 512 MB, ya que esta opción permite una utilización de los recursos más eficiente teniendo en cuenta el costo total de cada invocación. Esto varía según la función y, al usar la herramienta en sus funciones de Lambda, puede averiguar si el dimensionamiento correcto genera beneficios.

Le recomendamos que complete este ejercicio con regularidad como parte de cualquier prueba de integración cuando se publiquen nuevas actualizaciones. Si se actualiza con poca frecuencia, realice este ejercicio periódicamente para asegurarse de que las funciones estén ajustadas y tengan el tamaño adecuado. Cuando haya identificado la configuración de memoria adecuada de las funciones de Lambda, puede agregar el dimensionamiento correcto a sus procesos. La herramienta AWS Lambda Power Tuning genera resultados programáticos que pueden utilizar sus flujos de trabajo de CI/CD durante la publicación del nuevo código. Esto le permite automatizar la configuración de la memoria.

Puede descargar la herramienta AWS Lambda  Power Tuning de forma gratuita. Para obtener instrucciones sobre cómo utilizar la herramienta, consulte Cómo ejecutar la máquina de estados en. GitHub

Lambda también admite la compilación nativa anticipada, lo que permite precompilar las aplicaciones .NET. Reducir los tiempos de ejecución de las funciones .NET puede generar ahorro de costos. Para obtener más información sobre la creación de funciones con compilación nativa anticipada, consulte Funciones .NET con compilación nativa anticipada en la documentación de Lambda.

Evitar el tiempo de espera de inactividad

La duración de la función de Lambda es una dimensión que se utiliza para calcular la facturación. Cuando el código de la función realiza una llamada de bloqueo, se le facturará el tiempo que espere hasta recibir una respuesta. Este tiempo de espera puede aumentar cuando las funciones de Lambda están encadenadas o una función actúa como orquestadora de otras funciones. Si tiene flujos de trabajo como operaciones por lotes o sistemas de entrega de pedidos, esto agrega una sobrecarga de administración. Además, puede que no sea posible completar toda la lógica del flujo de trabajo ni la gestión de errores dentro del tiempo de espera máximo de Lambda de 15 minutos.

En lugar de utilizar esta lógica en el código de la función, le recomendamos que rediseñe la solución para utilizar AWS Step Functions como orquestador del flujo de trabajo. Cuando utilice un flujo de trabajo estándar, se le facturará por cada transición de estado del flujo de trabajo y no por la duración total del flujo de trabajo. Además, puede es posible gestionar los reintentos, las condiciones de espera, los flujos de error y las funciones de callback dentro del estado, permitiendo así que las funciones de Lambda se dediquen únicamente a la lógica empresarial. Para obtener más información, consulte Optimización de AWS Lambda los costes, segunda parte, en el blog de AWS informática.

Uso de funciones basadas en Graviton

Las funciones de Lambda impulsadas por los procesadores Graviton2 de última generación ya están disponibles de forma general. Las funciones Graviton2, que utilizan una arquitectura de procesador basada en ARM, están diseñadas para ofrecer hasta un 19 % más de rendimiento a un costo un 20 % menor para varias cargas de trabajo sin servidor. Con una latencia más baja y un mejor rendimiento, las funciones impulsadas por los procesadores Graviton2 son ideales para poner en marcha aplicaciones esenciales sin servidor.

La migración a funciones de Lambda basadas en Graviton puede ser una opción rentable para los desarrolladores de .NET que busquen optimizar los costos asociados al uso de Lambda. Las funciones basadas en Graviton utilizan procesadores basados en ARM en lugar de los procesadores x86 tradicionales. Esto puede suponer un importante ahorro de costos sin sacrificar el rendimiento.

Si bien empezar a usar funciones basadas en Gravitón tiene varias ventajas, también hay varios desafíos y consideraciones que le recomendamos que tenga en cuenta. Por ejemplo, las funciones basadas en Graviton requieren el uso de Amazon Linux 2, que puede no ser compatible con todas las aplicaciones .NET. Además, es posible que haya problemas de compatibilidad con bibliotecas o dependencias de terceros que no sean compatibles con los procesadores basados en ARM.

Si tiene en marcha aplicaciones de .NET Framework y desea aprovechar las ventajas de la tecnología sin servidor con Lambda, puede considerar la posibilidad de migrar las aplicaciones a una versión moderna de .NET mediante Asistente de portabilidad para .NET. Esto le permite acelerar la migración de aplicaciones .NET heredadas a las versiones modernas de .NET, lo que permitirá que la aplicación funcione en Linux.

En la siguiente tabla se comparan los resultados de las arquitecturas x86 y ARM/Graviton2 de una función que calcula números primos.

La función utiliza un único subproceso. La duración más baja para ambas arquitecturas se indica cuando la memoria es de 1,8 GB. En los casos en los que la memoria es superior, las funciones de Lambda tienen acceso a más de 1 vCPU, pero, en este caso, la función no puede utilizar la potencia adicional. Por este mismo motivo, los costos se mantienen estables con una memoria de hasta 1,8 GB. Con más memoria, los costos aumentan porque esta carga de trabajo no supone ningún beneficio de rendimiento adicional. Es evidente que el procesador Graviton2 proporciona un mejor rendimiento y unos costos más bajos para esta función que requiere un uso intensivo de recursos de computación.

Para que la función utilice un procesador basado en ARM con Graviton, haga lo siguiente:

Recursos adicionales