Aws-lambda-dotnet: Suporte para .NET 5?

Também estou curioso sobre este assunto, especialmente porque esperar pelo próximo LTS (2021) parece uma ideia (de negócios) muito ruim.

É política da equipe de serviço do Lambda oferecer suporte a versões LTS de tempos de execução. Nós, a equipe do AWS .NET, estamos tentando trabalhar em nossas alternativas para ver a melhor forma de oferecer suporte ao .NET 5 com Lambda, pois sabemos que há muito entusiasmo por ele.

Por curiosidade de executar o .NET na perspectiva Lambda, o que as pessoas estão mais interessadas no .NET 5? Isso me ajuda a priorizar.

Inicialização rápida, baixo consumo e menor uso de memória
compilação estática de .NET (antes do tempo - AOT)
Interoperabilidade Java - isso pode ser um "recurso matador"

Olá @ andyfurniss4 ,

Boa tarde.

Parece que @normj contribuiu com esta questão. Por favor, informe se podemos resolver este problema.

Obrigado,
Ashish

Por curiosidade de executar o .NET na perspectiva Lambda, o que as pessoas estão mais interessadas no .NET 5? Isso me ajuda a priorizar.

Eu realmente quero mudar para C # 9 para registros, nova serialização Json, anotações de tipo anulável, F # 5 - nessa ordem

Eu ficaria curioso para ver até onde podemos chegar com um tempo de execução personalizado em vez do suporte nativo do .NET 5. Especialmente o cortador de link deve ser capaz de cortar muitos códigos desnecessários, reduzindo o tamanho do pacote. Se a abordagem de tempo de execução personalizado não for adequada, eu seria a favor do suporte nativo ao .NET 5. Como outros apontaram, o driver principal seriam os novos recursos da linguagem C #.

Um tempo de execução personalizado deve funcionar, mas há um bug no tempo de execução do .NET no 5.0 RC1 que significa que ele não funciona no AWS Lambda (consulte # 730). Deve ser bom assim que o RC2 for lançado.

Usar e manter um tempo de execução personalizado é uma sobrecarga para as equipes? Eu não olhei para isso recentemente, da última vez pareceu muito esforço, mas isso foi para CoreRT.

Por exemplo, configurar um, usá-lo, atualizá-lo, etc?

E quanto ao suporte da AWS para eles?

Por experiência pessoal, a única sobrecarga contínua que tenho é alterar o (s) pacote (s) NuGet e o SDK uma vez por mês para obter as últimas correções e / ou patches de segurança e, em seguida, reimplantar.

Caso contrário, acho que a mudança para um tempo de execução personalizado me levou cerca de um dia para refatorar e testar tudo e conectar o pacote Amazon.Lambda.RuntimeSupport .

Você precisa escrever um pouco mais de código e mantê-lo atualizado, mas pode usar os recursos mais recentes assim que estiverem disponíveis. Se você não tem a largura de banda para manter as coisas atualizadas, etc., então você pode usar o tempo de execução integrado, mas então você tem que esperar o tempo que a equipe do AWS Lambda levar para disponibilizar o novo tempo de execução entre todos os seus outros projetos trabalhar.

Para meus casos de uso, acho que vale a pena atualizar em nossas próprias agendas, em vez de estar vinculado à AWS '.

YMMV.

No momento, estamos mudando do Oracle para o Aurora Postgres, pois eles desaceleraram nosso desenvolvimento, pois não fomos capazes de inovar com a tecnologia mais recente. Uma vez que é Entity Framework Drivers para Oracle direcionado ao .NET Core 3.X acaba de ser lançado. No entanto, percebemos que precisamos permanecer no LTS por causa deles. Mas o suporte LTS não pode vir meses depois. Considerando que eu acho que o .NET 5.0 também é uma boa exceção ao plano LTS, pois é uma mudança monumental na funcionalidade.

Alguma notícia sobre isso agora que o .NET 5 foi lançado?

Meus principais interesses são C # 9 e todas as atualizações de System.Text.Json .

Lembre-se de que você pode usar o recurso de tempo de execução personalizado para usar o .NET 5 hoje: https://aws.amazon.com/blogs/developer/net-core-3-0-on-lambda-with-aws-lambdas- custom-runtime /

Ainda não tentei, mas com o corte de código, que é uma novidade no .NET 5, a experiência deve ser muito melhor do que com o .NET Core 3.0.

É política da equipe de serviço do Lambda oferecer suporte a versões LTS de tempos de execução. Nós, a equipe do AWS .NET, estamos tentando trabalhar em nossas alternativas para ver a melhor forma de oferecer suporte ao .NET 5 com Lambda, pois sabemos que há muito entusiasmo por ele.

Por curiosidade de executar o .NET na perspectiva Lambda, o que as pessoas estão mais interessadas no .NET 5? Isso me ajuda a priorizar.

Isso significa que a execução de aplicativos lambda com .NET 5 só terá suporte depois que o .NET 5.0 for movido de "atual" para "LTS"?

.NET 5.0 nunca será LTS. .NET 6.0 será a próxima versão do LTS.

.NET 5.0 nunca será LTS. .NET 6.0 será a próxima versão do LTS.

O que exatamente isso significa em relação aos lambdas e seu suporte para usar o .NET 5.0?

Isso significa que não devemos esperar suporte para .NET 5 no Lambda, pois não será LTS.

Isso significa que não devemos esperar suporte para .NET 5 no Lambda, pois não será LTS.

Obrigado @bjorg . Se esta for a conclusão, não deveria este problema ser encerrado com esta como a resposta direta, então?

Levantei isso sabendo que o .NET 5 não era LTS e que a equipe da AWS só oferece suporte a LTS. Eu queria saber se uma exceção seria feita devido à magnitude do lançamento e ao fato de que o próximo LTS não será até o final de 2021. O fato é que não tivemos um "sim" ou "não" explícito ainda assim, não acho que devamos encerrar isso ainda. O lançamento do .NET 5 veio e se foi (assim como aconteceu com o 3.1) e não temos suporte para Lambda, mas isso não significa A) eles não estão trabalhando nele ou B) eles não estão planejando.

Se os caras da AWS decidiram não oferecer suporte ao .NET 5 e deixaram isso bem claro, vamos encerrar este problema. Se for esse o caso, teremos apenas que esperar mais 12-18 meses pela próxima versão .NET compatível.

Além disso, entendo que há um milhão de outras coisas para trabalhar e isso provavelmente não é trivial. Eu apenas gosto das coisas novas e brilhantes 😋

A verdade é que, considerando o ritmo que a Microsoft decidiu dar ao .NET, não faz sentido esperar pelo lançamento do LTS a cada dois anos. Porque até a versão atual cheira a LTS quando deve durar 15 meses (1 ano + 3 meses de suporte).

Eu ficaria bem se a AWS definisse os tempos de execução LTS e Atuais para que nós, clientes, pudéssemos decidir em qual caminho queremos permanecer.

Honestamente, eu ficaria bem com um tempo de execução personalizado pré-preparado para tempos de execução no caminho Atual.

Honestamente, eu ficaria bem com um tempo de execução personalizado pré-preparado para tempos de execução no caminho Atual.

Você diz isso, mas outros podem não estar tão entusiasmados em receber uma notificação da AWS em novembro de 2021 dizendo que eles têm 3 meses para atualizar de 5.x para 6.0 antes que seus Lambdas deixem de receber todo o suporte da AWS.

Muita coisa pode mudar em um ano e, de repente, uma equipe pode não ter a largura de banda para reagir à necessidade de atualizar um Lambda que pode não ter sido tocado por meses para manter o suporte que estava sendo feito anteriormente em seu nome pela Amazon atualizando o host tempo de execução conforme necessário, sem ter que pensar sobre isso.

Claro, poderia haver um runtime atual pré-preparado com muitos avisos e advertências, mas isso viria com suas próprias complexidades de suporte e nuances que os usuários precisariam entender.

Seria ótimo se Lambda suportasse todas as novas versões principais do .NET a partir do dia em que são lançadas pela Microsoft, mas imagino que os aspectos práticos de fazer isso em sua escala são o motivo pelo qual as coisas são como estão agora.

Se você realmente quer estar na vanguarda e atualizar o mais rápido possível, dar suporte às coisas você mesmo e fazer suas próprias coisas e aceitar todas as consequências, então é para isso que servem os tempos de execução personalizados.

O problema é que não estamos obviamente na vanguarda. O .NET Core se move rapidamente e tem se mantido incrivelmente estável. Procure no NuGet agora e os pacotes existem para o 5.0.0. Eles são para consumo público agora.

Embora eu não tenha tentado atualizar um projeto DotNet Core 3.1 para DotNet 5, até agora, não encontrei nenhum grande problema em apenas atualizar (por exemplo, de 2.1 para 3.1).

DotNet 5 pode ser uma fera diferente, mas os tempos de execução personalizados para mim são para ambientes mais incomuns como C ++ Lambda.

Eu prefiro ter as atualizações e mudar para o DotNet 5 Lambda mais cedo ou mais tarde. 2020 provou que um ano é muuuuito tempo :-)

Eu vejo de onde você está vindo @martincostello.

Mas esse é o tipo de escolha que deve caber aos clientes: aderir à Atual ou LTS.

A AWS não está liberando tempos de execução na Current porque um cliente que a escolheu pode ter problemas, pois isso é uma distorção da responsabilidade da AWS para com seus clientes. Eles devem fornecer as ferramentas e deixar que todos decidam qual ferramenta é mais adequada para eles.

Adicionando ao que @genifycom disse, as funções Lambda são geralmente muito simples e na maioria das vezes seu código não depende de recursos específicos de um framework, o que torna difícil passar de uma versão principal para outra (obviamente, existem anomalias) .

Em minha empresa, temos dezenas de funções e, na maioria das vezes, as atualizamos com localizar / substituir em toda a pasta (foi um pouco mais complexo quando tivemos que remover a propriedade LambdaTools específica do arquivo de projeto).

Eu também gostaria de ver o suporte transitivo para dotnet 5 até que uma versão LTS esteja disponível. (isso aconteceu no passado com outra versão)

As únicas opções disponíveis no momento são:

• fique com o dotnet core 3.1 e espere até o dotnet 6 :(
• usar um tempo de execução personalizado (o que por si só seria bom, no entanto, devido à falta de AOT nativo suficiente no dotnet 5, os tempos de inicialização provavelmente seriam afetados a ponto de afastar os desenvolvedores da ideia https://medium.com/ @ zaccharles / benchmarking-lambdas-new-custom-runtime-for-net-core-43ea79b5a35a)

Zac continuou a postagem original com mais detalhes sobre como melhorar o desempenho de inicialização para o tempo de execução personalizado: https://medium.com/@zaccharles/net -core-3-0-aws-lambda-benchmarks-and-recomendações- 8fee4dc131b0

Espero que ele poste uma versão do .NET 5, porque há muitos aprimoramentos de compilação no .NET 5 que não existiam no .NET Core 3.1, como corte de código, o que seria muito útil com o tempo de execução personalizado.