Aws-lambda-dotnet: ¿Soporte .NET 5?

También tengo curiosidad sobre este tema, especialmente porque esperar el próximo LTS (2021) parece una idea (de negocios) muy mala.

La política del equipo de servicio de Lambda es admitir versiones LTS de tiempos de ejecución. Nosotros, el equipo de AWS .NET, estamos tratando de trabajar con nuestras alternativas para ver cuál es la mejor manera de admitir .NET 5 con Lambda, ya que sabemos que hay mucho entusiasmo por ello.

Por curiosidad de ejecutar .NET en la perspectiva de Lambda, ¿qué es lo que más le interesa a la gente con .NET 5? Esto me ayuda a impulsar las prioridades.

Inicio rápido, espacio reducido y menor uso de memoria
compilación estática de .NET (anticipada - AOT)
Interoperabilidad de Java: esta podría ser una "característica excelente"

Hola @ andyfurniss4 ,

Buenas tardes.

Parece que @normj había proporcionado información sobre esta pregunta. Indique si podemos solucionar este problema.

Gracias,
Ashish

Por curiosidad de ejecutar .NET en la perspectiva de Lambda, ¿qué es lo que más le interesa a la gente con .NET 5? Esto me ayuda a impulsar las prioridades.

Realmente quiero pasar a C # 9 para registros, nueva serialización de Json, anotaciones de tipo que aceptan valores NULL, F # 5, en ese orden

Tendría curiosidad por ver qué tan lejos podemos llegar con un tiempo de ejecución personalizado en lugar del soporte nativo de .NET 5. Especialmente, el recortador de enlaces debería poder eliminar una gran cantidad de código innecesario, reduciendo el tamaño del paquete. Si el enfoque de tiempo de ejecución personalizado no es adecuado, entonces estaría muy a favor del soporte nativo de .NET 5. Como han señalado otros, el controlador principal serían las nuevas funciones del lenguaje C #.

Un tiempo de ejecución personalizado debería funcionar, pero hay un error en el tiempo de ejecución de .NET en 5.0 RC1 que significa que no funciona en AWS Lambda (consulte el n. ° 730). Debería ser bueno una vez que se lance RC2.

¿Usar y mantener un tiempo de ejecución personalizado es una sobrecarga para los equipos? No lo he investigado recientemente, la última vez me pareció un gran esfuerzo, pero eso fue para CoreRT.

Por ejemplo, ¿configurar uno, usarlo, actualizarlo, etc.?

¿Qué pasa con el soporte de AWS para ellos?

Por experiencia personal, la única sobrecarga continua que tengo es cambiar los paquetes NuGet y el SDK una vez al mes para obtener las últimas correcciones y / o parches de seguridad y luego volver a implementarlos.

De lo contrario, creo que cambiar a un tiempo de ejecución personalizado me llevó aproximadamente un día para refactorizar y probar todo y conectar el paquete Amazon.Lambda.RuntimeSupport .

Tienes que escribir un poco más de código y mantenerlo actualizado, pero puedes usar las últimas funciones tan pronto como estén disponibles. Si no tiene el ancho de banda para mantener las cosas actualizadas, etc., puede usar el tiempo de ejecución incorporado, pero luego debe esperar el tiempo que le tome al equipo de AWS Lambda hacer que el nuevo tiempo de ejecución esté disponible entre todos sus otros proyectos. trabaja.

Para mis casos de uso, creo que vale la pena poder actualizar los gastos generales en nuestros propios horarios, en lugar de estar vinculados a los de AWS.

YMMV.

Actualmente nos estamos mudando de Oracle a Aurora Postgres, ya que ralentizaron nuestro desarrollo ya que no pudimos innovar con la última tecnología. Dado que son los controladores de Entity Framework para Oracle destinados a .NET Core 3.X, se acaba de lanzar. Sin embargo, nos dimos cuenta de que debemos permanecer en LTS debido a ellos. Pero el soporte de LTS no puede llegar meses después. Dado que creo que .NET 5.0 también es una buena excepción al plan LTS, ya que es un cambio monumental en la funcionalidad.

¿Alguna noticia sobre esto ahora que se lanza .NET 5?

Mis principales intereses son C # 9 y todas las actualizaciones de System.Text.Json .

Tenga en cuenta que puede usar la capacidad de tiempo de ejecución personalizado para usar .NET 5 hoy: https://aws.amazon.com/blogs/developer/net-core-3-0-on-lambda-with-aws-lambdas- tiempo de ejecución personalizado /

Todavía no lo he probado, pero con el recorte de código, que es nuevo en .NET 5, la experiencia debería ser mucho mejor que con .NET Core 3.0.

La política del equipo de servicio de Lambda es admitir versiones LTS de tiempos de ejecución. Nosotros, el equipo de AWS .NET, estamos tratando de trabajar con nuestras alternativas para ver cuál es la mejor manera de admitir .NET 5 con Lambda, ya que sabemos que hay mucho entusiasmo por ello.

Por curiosidad de ejecutar .NET en la perspectiva de Lambda, ¿qué es lo que más le interesa a la gente con .NET 5? Esto me ayuda a impulsar las prioridades.

¿Significa esto que la ejecución de aplicaciones lambda con .NET 5 solo será compatible una vez que .NET 5.0 se haya movido de "actual" a "LTS"?

.NET 5.0 nunca será LTS. .NET 6.0 será la próxima versión LTS.

.NET 5.0 nunca será LTS. .NET 6.0 será la próxima versión LTS.

¿Qué significa exactamente esto con respecto a las lambdas y su soporte para usar .NET 5.0?

Significa que no deberíamos esperar soporte para .NET 5 en Lambda, ya que no será LTS.

Significa que no deberíamos esperar soporte para .NET 5 en Lambda, ya que no será LTS.

Gracias @bjorg . Si esta es la conclusión, ¿no debería cerrarse este problema con esto como respuesta directa entonces?

Planteé esto sabiendo que .NET 5 no era LTS y que el equipo de AWS solo es compatible con LTS. Me preguntaba si se haría una excepción debido a la magnitud del lanzamiento y al hecho de que la próxima LTS no será hasta finales de 2021. La cosa es que no hemos tenido un "sí" o un "no" explícito. sin embargo, no creo que debamos cerrar esto todavía. La versión .NET 5 llegó y se fue (al igual que lo hizo para 3.1) y no tenemos soporte para Lambda, pero eso no significa que A) no estén trabajando en ello o B) no planeen hacerlo.

Si los chicos de AWS han decidido no admitir .NET 5 y dejan esto en claro, entonces claro, cerremos este problema. Si ese es el caso, solo tendremos que esperar otros 12-18 meses para la próxima versión de .NET compatible.

Además, entiendo que hay un millón de otras cosas en las que trabajar y esto probablemente no sea trivial. Simplemente me gustan las cosas nuevas y brillantes 😋

La verdad es que, considerando el ritmo que Microsoft ha decidido darle a .NET, no tiene sentido esperar un lanzamiento de LTS cada dos años. Porque incluso la versión actual huele a LTS cuando está obligado a permanecer durante 15 meses (1 año + 3 meses de soporte).

Estaría bien si AWS definiera los tiempos de ejecución actuales y LTS para que los clientes pudiéramos decidir qué camino queremos seguir.

Honestamente, estaría bien con un tiempo de ejecución personalizado precocinado para tiempos de ejecución en la ruta actual.

Honestamente, estaría bien con un tiempo de ejecución personalizado precocinado para tiempos de ejecución en la ruta actual.

Usted dice eso, pero es posible que otros no estén tan entusiasmados de recibir una notificación de AWS en noviembre de 2021 diciéndoles que tienen 3 meses para actualizar de 5.xa 6.0 antes de que sus Lambdas abandonen todo el soporte de AWS.

Muchas cosas pueden cambiar en un año y, de repente, es posible que un equipo no tenga el ancho de banda para reaccionar a la necesidad de actualizar un Lambda que podría no haber sido tocado durante meses para mantener el soporte que anteriormente estaba haciendo en su nombre por parte de Amazon actualizando el archivo alojado. tiempo de ejecución según sea necesario sin tener que pensar en ello.

Claro, podría haber un tiempo de ejecución actual precocinado con un montón de advertencias y advertencias, pero eso vendría con sus propias complejidades de soporte y matices que los usuarios deberían comprender.

Sería genial si Lambda admitiera todas las nuevas versiones principales de .NET a partir del día en que Microsoft las lanzó, pero imagino que los aspectos prácticos de hacerlo a su escala son la razón por la que las cosas están como están ahora.

Si realmente quieres estar a la vanguardia y actualizar lo antes posible y respaldar las cosas tú mismo y hacer lo tuyo y aceptar todas las consecuencias, entonces para eso están los tiempos de ejecución personalizados.

El problema es que, obviamente, no estamos a la vanguardia. .NET Core se mueve rápido y ha sido notablemente estable. Busque en NuGet ahora mismo y los paquetes están ahí para 5.0.0. Ahora son para consumo público.

Si bien no he intentado actualizar un proyecto DotNet Core 3.1 a DotNet 5, hasta ahora, no me he encontrado con ningún problema importante solo con la actualización (por ejemplo, de 2.1 a 3.1).

DotNet 5 puede ser una bestia diferente, pero los tiempos de ejecución personalizados para mí son para entornos más inusuales como C ++ Lambda.

Preferiría tener las actualizaciones y pasar a DotNet 5 Lambda más temprano que tarde. 2020 ha demostrado que un año es mucho tiempo :-)

Veo de dónde vienes @martincostello.

Pero este es el tipo de elección que deberían elegir los clientes: pasar a Current o LTS.

AWS no lanza tiempos de ejecución en Current porque un cliente que lo eligió podría tener problemas porque es una distorsión de la responsabilidad que AWS tiene para con sus clientes. Deben proporcionar las herramientas y permitir que todos decidan qué herramienta es la más adecuada para ellos.

Además de lo que dijo @genifycom , las funciones de Lambda suelen ser muy simples y la mayoría de las veces su código no se basa en características específicas de un marco, por lo que es difícil pasar de una versión principal a otra (obviamente, hay anomalías). .

En mi empresa tenemos decenas de funciones y la mayoría de las veces las actualizamos con una búsqueda / reemplazo en toda la carpeta (fue un poco más complejo cuando tuvimos que eliminar la propiedad específica de LambdaTools del archivo del proyecto).

A mí también me gustaría ver soporte transitivo para dotnet 5 hasta que esté disponible una versión LTS. (esto sucedió en el pasado con otra versión)

Las únicas opciones disponibles en este momento son:

• quédese con dotnet core 3.1 y espere hasta dotnet 6 :(
• use un tiempo de ejecución personalizado (que en sí mismo estaría bien, sin embargo, debido a la falta de suficiente AOT nativo en dotnet 5, los tiempos de inicio probablemente se verían afectados en la medida en que desanimaría a los desarrolladores la idea https://medium.com/ @ zaccharles / benchmarking-lambdas-new-custom-runtime-for-net-core-43ea79b5a35a)

Zac siguió esa publicación original con más detalles sobre cómo mejorar el rendimiento de inicio para el tiempo de ejecución personalizado: https://medium.com/@zaccharles/net -core-3-0-aws-lambda-benchmarks-and-recommended- 8fee4dc131b0

Espero que publique una versión .NET 5, porque hay muchas mejoras de compilación en .NET 5 que no existían en .NET Core 3.1, como el recorte de código, que sería muy útil con el tiempo de ejecución personalizado.