Aws-lambda-dotnet: .NET Core 3.1 (LTS) foi lançado

É um LTS e será compatível. Levará algum tempo para que o .NET Core 3.1 esteja pronto para Lambda e implantado.

É um LTS e será compatível. Levará algum tempo para que o .NET Core 3.1 esteja pronto para Lambda e implantado.

Se houver algo que eu possa fazer para ajudar, por favor, me avise.

Haverá uma aceleração para o tempo de inicialização a frio?

.NET Core 3.1 tem alguns recursos como compilação AOT

• PublishReadyToRun
• PublishTrimmed

@normj as pessoas devem se inscrever neste problema para obter atualizações ou há outro problema do .NET Core 3.1 que devemos seguir para o progresso?

Podemos usar esse problema para rastrear atualizações. Infelizmente, provavelmente não poderei fornecer muitas atualizações de status até que seja lançado.

Haverá uma aceleração para o tempo de inicialização a frio?

.NET Core 3.1 tem alguns recursos como compilação AOT

• PublishReadyToRun
• PublishTrimmed

Caso a resposta seja sim para o comentário, será possível executar e testar o 'lambda compilado' de um ambiente local? Gostaria de definir ansiosamente um ambiente Linux para ele :)

Alguma atualização aqui?

@ rati-dzidziguri

Como acima de @normj

Podemos usar esse problema para rastrear atualizações. Infelizmente, provavelmente não poderei fornecer muitas atualizações de status até que seja lançado.

@beeradmoore
Minha pergunta era sobre o ETA. Seria útil saber a ETA para isso, pois poderíamos nos preparar adequadamente.

@ rati-dzidziguri A Amazon raramente divulga seu ETA quando se trata de lançamentos.

@ rati-dzidziguri Eu entendo e agradeço por você querer um ETA para que possa planejar de acordo. Na realidade, é por essa razão que geralmente não damos um ETA porque tentamos muito não fazer promessas que não temos 100% de certeza que poderemos cumprir. Eu odiaria dar a você um ETA e você fazer seu roteiro com base nisso e então eu perderia aquele ETA que você esperava que jogasse todos os seus planos em desordem.

Por enquanto, se você realmente precisa dos recursos do .NET Core 3.1, sugiro usar o .NET Core 3.1 como um Lambda Custom Runtime, que é explicado aqui (exceto referências de alteração do .NET Core 3.0 para .NET Core 3.1). Então, quando o suporte nativo do .NET Core 3.1 chegar, você terá uma migração muito simples de alterar algumas configurações em sua função Lambda.

@normj Um motivo que me fez decidir que não posso usar o recurso de tempo de execução personalizado com a classe 'LambdaEntry' é o aspecto de 'arquitetura monolítica' da abordagem de implementação. Cada solicitação de API vem por meio da única entrada lambda e 'distribuída' para controladores do projeto ASP .net é o que a estrutura de tempo de execução personalizada pretendia, o que é definitivamente conveniente, mas inclui desvantagens estruturais para casos como eu desejo. Quero que cada solicitação de comando / consulta se torne lambda cada. Desde então, posso obter uma escalabilidade no gerenciamento de pacotes de implantação que posso dividir algumas funções e gerenciar códigos sempre que quiser.
É por isso que estou esperando o tempo de execução oficial ser suportado para que eu possa construir um pacote de 'lambdas de propósito único' usando SAM escrito em um modelo com a configuração 'runtime: .netcore 3.1'.

Por favor, me dê um conselho se eu estiver errado :)

Definitivamente, você pode obter várias funções lambda a partir de uma base de código usando o Lambda Bootstrapper e o recurso de tempo de execução personalizado.

Eu tenho um conjunto de 16 lambdas que são implantados a partir de um aplicativo, em vez de um “monólito”.

Isso é obtido usando a variável de ambiente _handler para escolher o método a ser usado no tempo de execução, em vez do mapeamento um-para-um embutido mostrado no código de amostra da postagem do blog.

Eu penso nisso como um aplicativo de console que recebe um interruptor que diz em qual ação "tornar-se" ao ser inicializado.

@martincostello
Obrigado pela gentil sugestão! Posso descobrir como pode ser o seu caso. Você pode ter colocado a lógica do switch na classe Main ou Startup para que seja possível determinar sua funcionalidade no primeiro estágio do tempo de execução. E pode resolver o problema do "único monolítico", é claro. Abordagem muito inteligente :)

Mesmo assim, há uma (senão muitas) considerações em que devo pensar, especialmente quando me imagino trabalhando em equipe. Usar o tempo de execução personalizado e determinar a 'identidade funcional' na inicialização eliminará a possibilidade do SAM. Para um exemplo fácil para nós, o gateway de API não pode ser definido durante a implantação de um lambda, o que significa que temos que gerar um manualmente para ele.
Eu sei que estou exagerando aqui porque podemos fazer algo como a configuração do SAM usando o script de bootstrap, conforme explicado pelo tutorial do aws . Mas não vai nos satisfazer completamente, pois está usando um script Linux, o que significa
(1) pode ser embaraçoso para os recém-chegados e, às vezes, torna-se uma curva de aprendizado.
(2) descartará o benefício da expressividade do modelo sem servidor porque é literalmente um script, não um documento.

Acho que o modelo sem servidor funciona como um semidocumento de como o servidor se parece e como funciona, que não será apenas compartilhado dentro de uma equipe de desenvolvimento, mas até mesmo com alguns não técnicos perspicazes. e o SAM é um conceito bem definido que, em um futuro próximo, as representações abstratas de uma aplicação possibilitarão a reutilização por outra equipe em linguagens e plataformas totalmente diferentes. Esses aspectos ainda me motivam inegavelmente a continuar usando o recurso 'modelo sem servidor'.

Algumas boas datas para o lançamento deste, 25 de dezembro, 1 de janeiro vêm à mente;)

Boas festas, gostaria de poder oferecer todo o runtime do .NET Core 3.1 Lambda para o Natal, mas acho que 2020 será um período empolgante para .NET e AWS.

Boas festas, gostaria de poder oferecer todo o runtime do .NET Core 3.1 Lambda para o Natal, mas acho que 2020 será um período empolgante para .NET e AWS.

Não se preocupe, aproveite as férias! Mal posso esperar para ver o que você tem para nós em 2020! :)

aguardando suporte nativo lambda em .NetCore3.1

Há um limite de tamanho de disco para funções lambda. Eu acho que é 250 megas e ao usar o tempo de execução personalizado, temos que enviar todos os assemblies de núcleo do asp.net junto com nosso aplicativo. Eu alcancei esse limite quando a AWS estava descompactando meu pacote zip. Tive que fazer uma limpeza para reduzir o espaço usado pelo meu aplicativo. Quando o suporte nativo é lançado, não precisamos empacotar nosso aplicativo com assemblies .core.

Existe alguma estimativa de quando podemos esperar que isso seja lançado?

Estamos esperando para atualizar para .Net core 3.1 até que haja suporte nativo para ele.

Existe alguma estimativa de quando podemos esperar que isso seja lançado?

Estamos esperando para atualizar para .Net core 3.1 até que haja suporte nativo para ele.

Se você voltar e ler as respostas, lerá de normj que eles não fornecerão nenhuma estimativa.

Se você voltar e ler as respostas, lerá de normj que eles não fornecerão nenhuma estimativa.

Mmmm normalmente - sim. Mas se um número suficiente de pessoas aparecer com pitch forks, talvez uma dica de uma data de lançamento seja dada para conter a agitação: sorriso:

Lembro-me de um tempo atrás, quando a AWS passou muito tempo preparando as imagens nativas 2.1. Eles disseram algo no sentido de que redesenharam o processo para tornar a implantação de versões futuras mais fácil e rápida. Entre no NetCore 3.1 e quase dois meses depois e ainda não está disponível :(

Você sabe que o Azure tinha essa imagem 3.1 disponível no dia 1. Estou começando a ver por que o governo dos EUA escolheu o Azure como seu provedor de nuvem para JEDI.

Acabamos de receber luz verde de nossas partes interessadas para começar a direcionar o Azure como nosso provedor principal, deixando a AWS como backup. Com atrasos bobos como esse, tenho certeza de que não somos os únicos.

Lembro-me de um tempo atrás, quando a AWS passou muito tempo preparando as imagens nativas 2.1. Eles disseram algo no sentido de que redesenharam o processo para tornar a implantação de versões futuras mais fácil e rápida. Entre no NetCore 3.1 e quase dois meses depois e ainda não está disponível :(

Você sabe que o Azure tinha essa imagem 3.1 disponível no dia 1. Estou começando a ver por que o governo dos EUA escolheu o Azure como seu provedor de nuvem para JEDI.

Acabamos de receber luz verde de nossas partes interessadas para começar a direcionar o Azure como nosso provedor principal, deixando a AWS como backup. Com atrasos bobos como esse, tenho certeza de que não somos os únicos.

Concordo com você. Minha organização não permite tempo de execução personalizado e estamos meio que presos ao 2.1. Quando se trata de EF e Postgres junto com operações espaciais, é muito chato. Temos esperado que isso seja feito. Pena que ainda não acabou.

Lembro-me de um tempo atrás, quando a AWS passou muito tempo preparando as imagens nativas 2.1. Eles disseram algo no sentido de que redesenharam o processo para tornar a implantação de versões futuras mais fácil e rápida. Entre no NetCore 3.1 e quase dois meses depois e ainda não está disponível :(

Você sabe que o Azure tinha essa imagem 3.1 disponível no dia 1. Estou começando a ver por que o governo dos EUA escolheu o Azure como seu provedor de nuvem para JEDI.

Acabamos de receber luz verde de nossas partes interessadas para começar a direcionar o Azure como nosso provedor principal, deixando a AWS como backup. Com atrasos bobos como esse, tenho certeza de que não somos os únicos.

O JEDI usa o .NET Core para fazer a suposição de que é por isso que o governo escolheu o Azure?

Olá a todos,

Estou trabalhando ativamente para trazer o suporte para .NET Core 3.1 no Lambda. Leva algum tempo porque muito trabalho foi feito pela Microsoft em como eles constroem o tempo de execução. Estou trabalhando para incorporar essas mudanças para trazer a você um tempo de execução nativo.

@assyadh Obrigado! Não acredito que os atrasos sejam "bobos"; na verdade, prefiro esperar por uma versão sólida e funcional. Adoro o fato de o AWS Lambda ter suporte para .NET Core e agradeço que você continue oferecendo suporte, conforme prometido.

Eu não entendo o desejo. Não é que não tenhamos um ambiente LTS agora.

Obviamente, queremos usar os novos brinquedos, mas a equipe .NET na AWS tem apenas uma quantidade fixa de recursos e eles não podem fazer tudo de uma vez.

Além disso, não estou ansiando pela necessidade de apressar e atualizar o tempo de execução de todas as funções com medo de ficar fora dos prazos de serviço.

Bom para você @Kralizek, mas sua situação é sua e não representa outras pessoas. Não são realmente "brinquedos novos" agora, é. .NET Core 3.x (e ASP.NET Core) tem melhorias significativas em relação ao 2.x de várias maneiras e os primeiros usuários estão ansiosos para adotar e aproveitar. Como @JamesQMurphy disse, também preferimos que o lançamento seja sólido.

Estou ansioso para ver seu trabalho @assyadh.

"Eu não entendo o desejo."

Não podemos usar o .NET Core 3.1 compartilhado em uma função lambda do .NET Core 2.1, na verdade, não podemos nem mesmo usar o código .NET Core 2.2 compartilhado em uma função lambda do .NET Core 2.1, então recentemente tivemos que fazer um downgrade relutantemente componentes compartilhados para .NET Core 2.1 para que tenham suporte na função.

Seus componentes compartilhados podem ser compilados em netstandard20? Então você pode compartilhá-los no netcore2 e 3

Embora este tópico seja específico do .NET 3.1, tenho certeza de que essa conversa exata será repetida quando o .NET 5 chegar (ou 6, se for o próximo LTS).

Embora alguns exemplos específicos tenham sido citados onde não é possível (por exemplo, arquivo ZIP muito grande, política da empresa), _em geral_ se você quiser usar o “mais recente e melhor” .NET Core indo em frente, você pode fazer isso com um pouca refatoração e o pacote de suporte de tempo de execução customizado.

Neste momento, estamos em um ponto em que a versão mais recente _também acontece_ é uma versão LTS, o que parece estar fazendo com que a necessidade de tê-lo "ASAP" da Amazon pareça muito mais "urgente" do que era com, digamos, tendo suporte integrado para 2.2 ou 3.0.

Em última análise, há uma troca a ser feita entre os novos recursos que podem ser usados ​​no Lambda e o esforço de desenvolvimento necessário para ser colocado nas soluções de PaaS.

O .NET Core 3.1 nem estava disponível no Azure App Service da Microsoft por 2 a 3 semanas após seu lançamento.

Se você geralmente gosta de estar na “vanguarda” o mais rápido possível, fazer um pequeno investimento no uso do suporte de tempo de execução customizado em curto prazo o desbloqueará para potencialmente executar qualquer versão futura do .NET Core no Lambda em seus próprios prazos. É claro que a compensação aqui, entre outras coisas, são pacotes maiores, um pouco mais de código e a necessidade de fazer seu próprio patch.

Em tudo, há um equilíbrio e uma compensação e, para suporte integrado, sempre haverá um atraso de disponibilidade porque o software leva tempo.

Com os principais lançamentos do .NET ocorrendo em novembro, o período de Natal / Feriado provavelmente sempre terá um efeito sobre quanto tempo vai levar para disponibilizar essas coisas integradas em termos de tempo e capacidade disponível da equipe Lambda.

Apenas adicionando meus pensamentos. Eu entendo como este lançamento é muito importante e agradeço por nos contar. Eu uso esse feedback para colocar a urgência do nosso lado. Como @martincostello mencionou, o momento em que o .NET Core 3.1 foi lançado não foi bom devido aos feriados, mas também durante o reInvent.

Eu fui o cara que mencionou no passado para o 2.1 que esperava que a automação que implementamos aceleraria o lançamento futuro. A automação que @assyadh colocou realmente nos ajudou, mas, infelizmente, com o

Então, acredite em mim que o .NET Core 3.1 é @assyadh , eu e muitos outros a mais alta prioridade para ser concluído.

Só para verificar, o trabalho para incorporá-lo começa assim que a Microsoft lança os pré-lançamentos, em vez de esperar pelo lançamento final? Isso presumivelmente reduziria o impacto do Natal e permitiria que ele fosse entregue mais cedo, uma vez que a versão final fosse lançada, pois só precisaria de testes.

Eu uso esse feedback para empurrar a urgência do nosso lado

Obrigado por este @normj. Aqui está meu $ 0,02, na esperança de que também ajude no seu evangelismo.

Como @martincostello mencionou, o momento em que o .NET Core 3.1 foi lançado não foi bom devido aos feriados, mas também durante o reInvent.

Como @mungojam aludiu, o .NET Core 3.1 estava disponível na forma de visualização a partir de 15 de outubro, mais de um mês antes do lançamento. Além disso, é basicamente uma versão de correção de bug do 3.0 - não conheço suas ferramentas, mas imagino que o trabalho exploratório poderia ter começado com o 3.0, que foi lançado em 23 de setembro e em versão prévia durante todo o ano . É importante notar que o 3.1 teve uma data de lançamento estimada no anúncio de lançamento do 3.0.

O .NET Core 3.1 nem estava disponível no Azure App Service da Microsoft por 2 a 3 semanas após seu lançamento.

O .NET Core 3.1 estava disponível no Azure Functions em 17 de outubro , dois dias após o lançamento do Preview 1.

Você pode dizer o que quiser sobre a necessidade de qualquer empresa de ter o 3.1 imediatamente, seja "inovação", opções de tempo de execução personalizadas e assim por diante, mas isso é realmente parte de um quadro mais amplo sobre a seriedade com que a AWS deseja nos apoiar. clientes. Se a AWS - não a equipe de Norm, mas a AWS em geral - tivesse tornado isso uma prioridade, tenho que pensar que eles poderiam estar à frente disso, certificando-se de que estavam competindo com o Azure.

Pessoalmente, eu realmente valorizo ​​ter opções entre as ofertas de nuvem que posso escolher com base no mérito, em vez de dogma corporativo, e adoraria ver a AWS dar o próximo passo para melhorar o suporte .NET.

Obrigado @normj , @assyadh e todos os outros que estão trabalhando nisso por seus esforços.

É possível que a equipe .NET na AWS tenha iniciado muito bem sua jornada de preparação para o .NET 3.1 LTS após o lançamento da versão 3.0. O fato é que a AWS tende a ser discreta sobre o que está fazendo por trás das cortinas. Essa falta de transparência gera suposições. Acho que não faria mal ter algum tipo de roteiro, mesmo que seja provisório e as datas estejam sujeitas a alterações, etc.

Acho que o problema é que a equipe da AWS não quer lançar nenhum tipo de ETA e, portanto, os desenvolvedores ficam no escuro. @normj diz que é porque não quer que ninguém ou nenhuma empresa faça planos futuros com base nesses ETAs. Não é o entendimento geral que um ETA é apenas uma estimativa e nenhuma empresa deve fazer planos sérios com base nas estimativas de outra empresa e, mesmo que o fizessem, a empresa não pode culpar a AWS ou ficar zangada com ela por perder um ETA?

Um ETA também não é um dia específico. Pode demorar um mês. Um quarto. E devemos aceitar qualquer HEC e se ele for perdido.

Olhando para
https://docs.aws.amazon.com/lambda/latest/dg/runtime-support-policy.html
parece que a AWS desativa o tempo de execução logo após o fim da vida dessa versão de tempo de execução.

Como as versões LTS do .NET Core são suportadas por 3 anos, já estamos
"gastando o tempo, podemos usar lambdas do .NET Core 3.1".
Portanto, eu entendo que as pessoas estão internadas para obter o .NET core 3.1 em lambdas.
BTW, eu também preferiria um lançamento sólido como uma rocha, em seguida, algo apressado.

Presumo que estará disponível nos próximos um ou dois meses, mas com algum compromisso da AWS,
mesmo que muito conservador, pode ser benéfico para as equipes planejarem suas operações.

Outra coisa é que nesta época de OSS: a comunidade .NET pode ajudar? Afinal, estamos conversando no github.
Este runtime "embutido" é algum código fechado?

Além disso, seria um recurso ASSASSINO se o processo de implantação tivesse uma opção para fazer o ReadyToRun e outros recursos de compilação AOT, de forma que os tempos de inicialização a frio caíssem seriamente.
Isso tornaria o .NET Core MUITO atraente no AWS Lambda, IMO.

@normj e equipe:
obrigado por tornar o .NET core excelente na AWS

Apenas adicionando meus pensamentos. Eu entendo como este lançamento é muito importante e agradeço por nos contar. Eu uso esse feedback para colocar a urgência do nosso lado.

Por favor, use esta postagem para empurrar a urgência do seu lado. Com isso em mente, aqui estão meus dois centavos.

Só para verificar, o trabalho para incorporá-lo começa assim que a Microsoft lança os pré-lançamentos, em vez de esperar pelo lançamento final?

Pergunta: obteremos uma resposta honesta a esta pergunta?

Parece que a resposta é evidente. Parece que a prioridade do .NET é "nível de hobby" e não "nível corporativo" como deveria ser.

Eu ouvi em algum lugar que 1) todo o material do Net Core foi feito de código aberto e 2) existem alguns programas de adoção inicial que permitem que você "comece a trabalhar" após o lançamento real. (consulte o Google para obter detalhes).

Estou sendo engraçado aqui, mas a verdade é que todo mundo que segue o .NET sabe disso, então isso aumenta a autoevidência de que falo.

Honestamente, após os atrasos do 2.1 no lançamento, eu estava esperançoso de que as mudanças feitas naquela época significassem que desta vez (3.1) teríamos suporte para o novo framework no máximo duas semanas após o lançamento real. Quero dizer, poucas horas após o lançamento seria o ideal, mas dar algum espaço para os retoques finais / polimento, dentro de duas semanas parece certo.

Mas aqui estamos nós quase dois meses fora e parece apenas "nível de hobby".

@ rati-dzidziguri Eu entendo e agradeço por você querer um ETA para que possa planejar de acordo. Na realidade, é por essa razão que geralmente não damos um ETA porque tentamos muito não fazer promessas que não temos 100% de certeza que poderemos cumprir.

Este é o pensamento "nível de passatempo", como @abukres tão elegantemente afirma:

Acho que o problema é que a equipe da AWS não quer lançar nenhum tipo de ETA e, portanto, os desenvolvedores ficam no escuro. @normj diz que é porque não quer que ninguém ou nenhuma empresa faça planos futuros com base nesses ETAs. Não é o entendimento geral que um ETA é apenas uma estimativa e nenhuma empresa deve fazer planos sérios com base nas estimativas de outra empresa e, mesmo que o fizessem, a empresa não pode culpar a AWS ou ficar zangada com ela por perder um ETA?

Um ETA também não é um dia específico. Pode demorar um mês. Um quarto. E devemos aceitar qualquer HEC e se ele for perdido.

Acho que o fato de a AWS ter perdido o contrato JEDI para o Azure deveria ter sido suficiente para iniciar internamente algumas reuniões de priorização, já que, à primeira vista, prova que .NET é um empreendimento de "nível corporativo" e deve ser tratado como tal. Em vez de desperdiçar recursos tentando "processar" a decisão, use esses recursos internamente para dar um pouco de amor à comunidade .NET. Use isso como um momento para priorizar novamente o .NET para que no próximo lançamento do .NET, a AWS esteja em cima dele e torne evidente que eles estão prontos para começar a trabalhar.

@normj , @martincostello e o resto das abelhas operárias da AWS, trabalhando muito para fornecer uma oferta SOLID .NET, por favor, entenda que essas reclamações (da comunidade) não são com você em si, mas mais com a cultura / política que ditam o mandato de prioridade que você recebeu em relação ao .NET. Use esta postagem para ajudar a obter suporte de "nível empresarial".

Vejo isso principalmente como uma oportunidade perdida para a AWS brilhar. Imagine se seguir um novo lançamento de LTS fosse uma alta prioridade. Que declaração forte seria.

Coisas como essa nos fazem, desenvolvedores / arquitetos, perdermos argumentos contra tomadores de decisão não técnicos quando precisamos decidir qual nuvem usar para o próximo projeto. Hoje em dia, quando o Azure e o AWS têm praticamente o mesmo custo e ofertas de recursos, as decisões são mais tomadas com base na política e na percepção. Não tenho nada a dizer quando dizem "já se passaram X semanas / meses após o lançamento oficial e a AWS ainda não está pronta"

Novamente, como @ VagyokC4 diz, isso não é pessoal contra os funcionários que estão fazendo o trabalho real, mas mais como um alerta para a alta administração da AWS.

Qualquer pessoa que esteja usando o .NET Core 3.1 Lambda pode considerar habilitar o IL Trimming. Muito provavelmente, você vai reduzir o tamanho dos seus arquivos zip.
https://www.hanselman.com/blog/MakingATinyNETCore30EntirelySelfcontainedSingleExecutable.aspx

o .NET core lambda 3.1 é construído usando RuntimeAPI?
ao ar livre, no github?
se não, por que não?

Tudo que eu quero para .... Dia dos namorados é suporte para lambda .net core 3.1

Tudo que eu quero para .... Dia dos namorados é suporte para lambda .net core 3.1

Não rola exatamente para fora da língua, mas é agradável:

Não quero muito no natal dia dos namorados
Há apenas uma coisa que eu preciso
Eu não me importo com os presentes
Embaixo da árvore AWS
Eu só quero isso para mim
Mais do que você poderia imaginar
Faça meu desejo se tornar realidade oh
Tudo que eu quero no Dia dos Namorados é .NET Core 3.1 suppooooort ...

:sorriso:

A Microsoft inclui licenças Go Live no final de seu ciclo de visualização, quando eles não apresentarão nenhuma alteração importante. Nesse ponto, eles oferecem suporte de produção para o próximo lançamento. Minha recomendação é esperar até que eles façam um lançamento com uma licença Go Live e então começar a trabalhar nas ferramentas. Com o .NET Core 3.1, ele veio na Visualização 3, lançada em 14/11. Neste caso, o RTM não chegou nem 3 semanas depois, em 03/12, mas você ainda estaria mais perto de lançar os recursos quando o RTM chegar e os clientes começarem a criar expectativas.

Só meus $ 0,02

Tudo que eu quero para .... Dia dos namorados é suporte para lambda .net core 3.1

Não rola exatamente para fora da língua, mas é agradável:

Eu não quero muito para ~ Natal ~ Dia dos Namorados
Há apenas uma coisa que eu preciso
Eu não me importo com os presentes
Embaixo da árvore AWS
Eu só quero isso para mim
Mais do que você poderia imaginar
Faça meu desejo se tornar realidade oh
Tudo que eu quero no Dia dos Namorados é .NET Core 3.1 suppooooort ...

😁

+1 :)

alguma atualização no tempo de execução do .NET Core 3.1 para Lambda?

Estamos iniciando um novo projeto e estávamos fortemente inclinados a usar Lamba na maioria dos sistemas sem servidor, mas ver quanto tempo leva para ter uma versão LTS suportada está nos fazendo repensar, possivelmente mudando a arquitetura ou o provedor.

<Rant>
É frustrante que a política de suporte do AWS Lambda Runtime seja muito rígida sobre a janela de 30 dias, quando recursos como este são solicitados por mais de 30 dias. Então, magicamente, um dia a AWS implantará esse recurso e todos os outros terão que se esforçar para migrar para o .NET Core 3.1. Isso coloca a MAIORIA das organizações em uma situação ruim, pois muitas vezes leva mais de um mês para consertar, testar e implantar algo em um ambiente de produção. Eu pessoalmente fui prejudicado por essa política. Uma vez (devido a restrições de recursos e outras prioridades mais altas), uma empresa em que eu estava deixou escapar esse tempo. Não foi senão três meses depois que pudemos atualizar nossos Lambdas para .NET Core 2.1. Depois de tentar implantar um lambda específico com o CloudFront, algo ruim (o quê? Quem sabe porque os logs do CF são lixo) aconteceu e foi necessário reverter. Exceto que não havia um tempo de execução para o qual reverter. Portanto, é LOCKED a implantação. Imediatamente abrimos um tíquete. 24 horas depois, recebemos nossa primeira resposta, que foi "exclua a pilha inteira e recomece". O que é uma resposta completamente ignorante, considerando que nossas tabelas DynamoDb teriam sido retiradas com a operação "delete". Ficamos presos nessa reversão por mais de 2 semanas e meia. Eventualmente, conseguimos um engenheiro de suporte que entendeu as tecnologias de contêiner e nos ajudou a reverter e, em seguida, permaneceu na linha até que nosso CloudFormation foi bem-sucedido. O que funcionou bem, nenhuma alteração na primeira tentativa. Que é meio por que agora odeio CF, já que é muito temperamental de usar.
</Rant>

TL; DR; A política de suporte do AWS Lambda Runtime é desagradável de se trabalhar e pode colocá-lo em apuros.
https://docs.aws.amazon.com/lambda/latest/dg/runtime-support-policy.html

@CraigHead, desculpe por sua experiência frustrante, mas para ser claro, independentemente de quando o .NET Core 3.1 for lançado no Lambda, o tempo de execução do .NET Core 2.1 terá suporte no Lambda até pelo menos 21 de agosto de 2021 com base no ciclo de suporte da Microsoft. Não haverá necessidade de pressa para converter as funções 2.1 em 3.1. Presumo que sua experiência anterior tenha sido com o .NET Core 2.0, o que era uma anomalia para Lambda porque era a única versão não LTS a entrar no Lambda. Isso só foi feito devido a alguns problemas importantes com o .NET Core 1.0.

Sim, foi a migração do .NET Core 2.0 para o .NET Core 2.1. Desculpe pelo discurso retórico. 30 dias é meio apertado para alguns de nós. Olhando para o comprimento geral, um lambda poderia potencialmente ser executado sem manutenção significativa e controle de qualidade adicional.

enquanto isso, isso está acontecendo no lado do Azure sem servidor
https://visualstudiomagazine.com/articles/2020/01/30/azure-functions-3-0-runtime.aspx

Enquanto isso, a equipe da AWS está trabalhando nisso. Comentários sarcásticos não estão ajudando
eles. Eles atualizarão este problema quando estiver pronto.

Na terça, 11 de fevereiro de 2020 às 18:22, Rati Dzidziguri [email protected]
escreveu:

enquanto isso, isso está acontecendo no lado do Azure sem servidor

https://visualstudiomagazine.com/articles/2020/01/30/azure-functions-3-0-runtime.aspx

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/aws/aws-lambda-dotnet/issues/554?email_source=notifications&email_token=AAAZVJXAAYET4F7PFFOTO3LRCLUETA5CNFSM4JU5UTJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELNQMBY#issuecomment-584779271 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/AAAZVJQK3NBVXBZALM4V5KLRCLUETANCNFSM4JU5UTJA
.

Meu ponto não foi fazer um comentário sarcástico, mas apontar que até mesmo a MS anunciou a disponibilidade do GA para o 3.1 recentemente, então espero ver a AWS finalizar seu trabalho no suporte ao 3.1 em breve.
.

enquanto isso, isso está acontecendo no lado do Azure sem servidor
https://visualstudiomagazine.com/articles/2020/01/30/azure-functions-3-0-runtime.aspx

Considerando que é uma linguagem MS, não é surpreendente que o Azure supere a AWS no suporte a isso.

Observando este tópico de perto - ansioso para atualizar meu C # Lambdas.

dotnet core 3.1.0 foi lançado em 03/12/2019
https://dotnet.microsoft.com/download/dotnet-core/3.1

estava disponível no Azure em 2020-01-23
https://azure.microsoft.com/en-us/updates/azure-functions-runtime-30-is-now-available/

faltam um pouco mais de um mês em comparação com o Azure

BTW, todo o desenvolvimento do .NET core é feito abertamente no github
Portanto, ser "linguagem MS" não deve ter muito efeito.
Ou você sugere que os clientes AWS que usam dotnet são melhores no Azure: P?

De qualquer forma, para qualquer pessoa ouvindo na AWS:
existem nós esperando por 3.1 no Lambda, é importante para nós.

BTW, todo o desenvolvimento do .NET core é feito abertamente no github
Portanto, ser "linguagem MS" não deve ter muito efeito.
Ou você sugere que os clientes AWS que usam dotnet são melhores no Azure: P?

Quer dizer, seria um pouco constrangedor para a plataforma em nuvem da Microsoft não oferecer suporte aos novos recursos de sua própria linguagem. Para ser honesto, estou um pouco surpreso que eles demoraram um pouco mais de um mês e meio! Um pouco mais de comunicação interna teria permitido que os dois fossem liberados ao mesmo tempo.

Acho que a AWS está indo bem com seu suporte .Net, especialmente com pacotes de desenvolvimento que se conectam a seus serviços, como CloudWatch + ILogging e sua configuração de parâmetro SSM. Isso nos ajudou muito.

Espero ver o lançamento 3.1 em breve :)

Eu gostaria que houvesse uma implementação concreta melhor do Cloudwatch de ILogger . Isso seria melhor integrado em ServiceCollection / ServiceProvider ao usar o Lambda SDK. A versão atual que é fornecida no contexto da solicitação e a classe LambdaLogger estática é basicamente impossível para testar a unidade / verificar a saída do log e conectar os resultados .netcore ConsoleLogProvider padrão em logs do Cloudwatch confusos.

Eu gostaria que houvesse uma implementação concreta melhor do Cloudwatch de ILogger .

Você já tentou https://github.com/aws/aws-logging-dotnet#aspnet -core-logging?

Como você deseja que seus logs se pareçam com @CraigHead?

Usamos Serilog e https://github.com/structured-log/structured-log no passado para gerar bons logs de console e também logs baseados em JSON que foram importados para o Seq. https://datalust.co/ essa foi a melhor maneira de obtermos logs centrais em um formato muito bom.

@CraigHead Amazon.Lambda.Logging.AspNetCore é a nossa implementação para integrar o log do Lambda no IServiceCollection. Essa biblioteca não funciona para você.

Eu não recomendaria o pacote AWS.Logger.AspNetCore de

Eu não sabia disso. Obrigado pela dica!
Eu estava me referindo a Amazon.Lambda.Core.LambdaLogger no SDK.
Definitivamente irei verificar esse pacote ( Amazon.Lambda.Logging.AspNetCore ).

https://docs.aws.amazon.com/lambda/latest/dg/csharp-logging.html

@clearwaterstream
No lambda-land AFAIK não há evento que irá notificá-lo de que a instância atual irá parar de processar ou será encerrada, então sua sugestão ainda deixará eventos de log armazenados em buffer não liberados (perdidos).

Por favor, não sequestre este tópico para outras necessidades.
Este thread foi criado para fornecer algumas informações quando o .NET Core 3.1 no AWS Lambda estará disponível.
E para que a AWS saiba que estamos lá e esperando.

A ferramenta de teste lambda será incluída na versão 3.1? https://github.com/aws/aws-lambda-dotnet/tree/master/Tools/LambdaTestTool

Essa é minha intenção. O trabalho está acontecendo no mock-testtool-31 . A grande melhoria no branch 3.1 é que o código do Lambda do usuário agora está sendo executado em um AssemblyLoadContext separado, que deve corrigir muitos dos conflitos de versão que os usuários tinham com a versão atual. Estou pensando em voltar a portar o recurso AssemblyLoadContext para a versão 2.1.

Como uma nota rodapé. Estou debatendo sobre como converter a interface do usuário básica em um aplicativo Blazor do lado do servidor. Alguém com mais experiência no Blazor tem algum feedback sobre se isso é uma boa ou má ideia?

Como uma nota rodapé. Estou debatendo sobre como converter a interface do usuário básica em um aplicativo Blazor do lado do servidor. Alguém com mais experiência no Blazor tem algum feedback sobre se isso é uma boa ou má ideia?

Qualquer coisa Blazor neste momento é uma boa ideia, especialmente para aqueles de nós que estão arrasando no DotNet!

"UI esquelética" - este é algum outro aplicativo, não conectado ao .NET Core 3.1 Lambdas?
BTW, eu não me importo com blazor em tudo

@petarrepac Isso foi em referência à ferramenta de teste AWS .NET Mock Lambda que enviamos para ajudar a depurar funções do .NET Core 2.1 Lambda. Aqui está a postagem para referência https://aws.amazon.com/blogs/developer/debugging-net-core-aws-lambda-functions-using-the-aws-net-mock-lambda-test-tool/

Estou atualizando a ferramenta do .NET Core 3.1.

@normj
ah não entendi obrigado
é interessante pensar que nunca precisamos de tal ferramenta

de nossa perspectiva, lambda é um AspNetCore HttpApi simples que você pode chamar localmente e testar localmente
a única diferença é o arquivo / classe de ponto de entrada que tem menos de 50 linhas de código
Além disso, muitas coisas só podem ser testadas adequadamente quando implantadas na AWS:

• permissões
• forma de eventos JSON recebidos e contexto
• ...
  então, uma combinação de:
• bons testes de unidade / integração executados localmente
• teste de http local
• fácil de implantar para testar o ambiente aws
  pode ir longe

ou estou perdendo algum cenário óbvio?

@petarrepac Esse é um dos grandes benefícios de usar a ponte ASP.NET Core é que é realmente fácil de executar localmente. Eu concordo que a prática recomendada é usar teste de unidade / integração, mas muitas vezes há necessidade de um teste ad hoc rápido da lógica do aplicativo e é para isso que essa ferramenta é boa.

Obrigado @normj. Em relação ao Blazor, poderia ser um belo toque. Para o caso de uso de nossa equipe, pelo menos provavelmente seria subutilizado.

Estamos apenas na IU o tempo suficiente para enviar uma carga útil e, em seguida, percorremos o código no VS.

Definitivamente, você pode obter várias funções lambda a partir de uma base de código usando o Lambda Bootstrapper e o recurso de tempo de execução personalizado.

Eu tenho um conjunto de 16 lambdas que são implantados a partir de um aplicativo, em vez de um “monólito”.

Isso é obtido usando a variável de ambiente _handler para escolher o método a ser usado no tempo de execução, em vez do mapeamento um-para-um embutido mostrado no código de amostra da postagem do blog.

Eu penso nisso como um aplicativo de console que recebe um interruptor que diz em qual ação "tornar-se" ao ser inicializado.

@martincostello

Estou tendo problemas para fazer isso com base na sua explicação. Tenho cerca de 20 funções Lambda em meu Functions.cs que estão vinculadas às definições correspondentes em meu serverless.template. Eu entendo que você estaria passando uma variável de ambiente com cada definição para indicar qual função chamar. A maioria dessas funções são de assinatura:

public APIGatewayProxyResponse ThisLambdaFunction (solicitação APIGatewayProxyRequest, contexto ILambdaContext)
{

Como adicionar suporte para diferentes assinaturas de função lambda, se eu tiver outras funções que usam argumentos diferentes (diferente de APIGatewayProxyRequest) e diferentes tipos de retorno?

Por favor, não descarrilhe o tópico.

@twopointzero Passei dias no Google procurando uma solução para executar várias funções lambda usando o projeto .NET Core 3.1 Custom Runtime. Não há tópico mais relevante na internet e estou respondendo a um post existente que me deu um vislumbre de esperança de que haja uma solução para o meu problema.

Não ter suporte nativo ao .NET Core 3.1 no AWS está dificultando a vida. Precisamos atualizar para 3.1 a fim de atualizar para o EntityFramewore Core 3.1.2 mais recente, que corrige problemas que estamos vendo com o pool de conexão no Aurora (PostgresSQL).

@normj Eu entendo

@antsaia Com respeito, seu comentário foi em relação à implantação de um monólito distribuído usando suporte de tempo de execução personalizado, não em relação ao suporte AWS Lambda para .NET Core 3.1. Se você não conseguir encontrar um tópico mais relevante na Internet, solicito que crie um, em vez de descarrilhar um.

Para não inviabilizar este tópico, este é meu comentário final sobre o assunto.

@normj existe algum recurso disponível (blog, fórum, etc.) onde possamos obter informações sobre o status da implementação do suporte .net core 3.1?

Visito esta página diariamente com a esperança de obter novas informações, mas obviamente não há informações suficientes (já que não se destina a esse uso). Seria muito mais fácil se tivéssemos algum tipo de atualização básica para que possamos planejar com antecedência.

Como muitos aqui, nossos planos para fornecer recursos dependem muito se podemos usar o 3.1 ou se temos que desenvolvê-lo usando o 2.1. No meu caso, o 3.1 fornecerá suporte para System.Draw e isso terá um grande impacto no recurso no qual devo trabalhar.

Tudo que eu quero para .... o dia de São Patrício é suporte a lambda .net core 3.1

@ liam-sage tudo que pude encontrar foram algumas postagens no fórum amazon indicando que estaria pronto no primeiro trimestre de 2020. https://forums.aws.amazon.com/thread.jspa?threadID=313806

@ liam-sage tudo que pude encontrar foram algumas postagens no fórum amazon indicando que estaria pronto no primeiro trimestre de 2020. https://forums.aws.amazon.com/thread.jspa?threadID=313806

Isso significa que ele deve entrar no ar em março. Estou esperando.

Olá, eu sei que não é totalmente adequado, mas você pode obter seus próprios lambdas atualizados para dotnetcore 3.1. Enquanto isso, enquanto você espera, sugiro que você crie muitos lambdas para escrever seu próprio modelo dotnetcore. Eu fiz isso por mim mesmo. Eu queria garantir que não perdesse horas com código clichê. Um exemplo de modelo pode ser encontrado aqui .

E Vincent, como o hospedamos lá? usando o tempo de execução personalizado?
Na quinta, 5 de março de 2020 às 19h40 Vincent van der Walt <
notificaçõ[email protected]> escreveu:

Olá, eu sei que não é totalmente adequado, mas você pode obter seus próprios lambdas
atualizado para dotnetcore 3.1. Enquanto isso, enquanto você espera, sugiro
se você criar muitos lambdas para escrever seu próprio modelo dotnetcore. eu fiz
isso para mim. Eu queria garantir que não perdesse horas com
código clichê. Um exemplo de modelo pode ser encontrado aqui
https://github.com/vincentvanderwalt/aws-lambda-dotnetcore-3-template .

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/aws/aws-lambda-dotnet/issues/554?email_source=notifications&email_token=AGIDH4OWUT7Y3HR3O5KARBDRF62V3A5CNFSM4JU5UTJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEN5P2CY#issuecomment-595262731 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/AGIDH4PLKFSDLNBX2QVMG63RF62V3ANCNFSM4JU5UTJA
.

Sim, ele usa o tempo de execução personalizado.

Você pode executá-lo localmente em sua máquina ou implantar no aws.

F5 para local e dotnet lambda deploy-serverless para implantação em aws

O leia-me explica como instalar o modelo em sua máquina local (é um modelo dotnetcore)

Os tempos de execução personalizados são legais, mas ainda estou esperando o suporte completo da AWS para .Net Core 3.1 para lambdas para usá-los em ambientes de produção 😄

Sempre que vejo isso em minha caixa de entrada, eu abro ansiosamente para ver se @normj
anunciou qualquer coisa apenas para encontrar uma postagem que está pelo menos um pouco errada
tema. Alguém pediu a outros para não sequestrar o tópico e isso não
trabalhado. Alguém pode bloquear o tópico até que alguém esteja pronto para anunciar o
lançamento do suporte 3.1?

Na sexta-feira, 6 de março de 2020 às 7h13 bartoszsiekanski [email protected]
escreveu:

Os tempos de execução personalizados são legais, mas ainda estou esperando pelo suporte completo da AWS
para .Net Core 3.1 para lambdas para usá-los em ambientes de produção 😄

-
Você está recebendo isto porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/aws/aws-lambda-dotnet/issues/554?email_source=notifications&email_token=AAVUT3SNDR4L2ZL5J4KQYDDRGDSHBA5CNFSM4JU5UTJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEOBE2OI#issuecomment-595742009 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/AAVUT3TBH3NIBMGB54EFCR3RGDSHBANCNFSM4JU5UTJA
.

Crie problemas separados para qualquer outra coisa além de discutir o suporte do .NET Core 3.1. Posso encerrar este problema até termos mais notícias @normj ?

@ hounddog22030 Não percebi que estava 'sequestrando' o tópico. Eu estava sugerindo que, em vez de perguntar constantemente se está pronto, existem abordagens alternativas se as pessoas estão desesperadas para mudar para o dotnetcore 3.1. O suporte oficial de tempo de execução não personalizado estará pronto quando estiver pronto. As pessoas só precisam ser um pouco mais pacientes ou buscar uma abordagem alternativa.

Se a AWS oferecer suporte à opção - self-contido no comando dotnet lambda package, as funções lambda devem ser executáveis ​​independentemente de sua versão do SDK. direito? Por que não fazer isso em vez de adicionar suporte para todas as versões do .NET Core?

Se a AWS oferecer suporte à opção - self-contido no comando dotnet lambda package, as funções lambda devem ser executáveis ​​independentemente de sua versão do SDK. direito? Por que não fazer isso em vez de adicionar suporte para todas as versões do .NET Core?

Você acabou de descrever o recurso de tempo de execução personalizado lambda

@aussiearef Isso realmente funciona bem, mas o pacote independente inclui o próprio .Net Core, que normalmente adiciona pelo menos 40 MB (compactado) para um site - não deixando muito espaço para o aplicativo e as dependências em si.

Ao usar a mesma versão do .NET core, o tempo de execução personalizado também é mais lento (inicializações a frio) do que o tempo de execução nativo. 3.1 adiciona muitas melhorias de desempenho, então você pode esperar o mesmo nível de perfs entre 3.1 customizado totalmente otimizado e 2.1 nativo. Tenho esperanças de que o 3.1 nativo trará melhorias significativas.

O primeiro trimestre terminará em 4 dias, mas parece que não veremos 3.1 em lambda.
Espero que todos os membros da equipe estejam seguros neste momento de pandemia e espero ver este lançamento no segundo trimestre.

Não perca as esperanças de que ainda nos restam alguns dias! Estamos todos muito envolvidos esperando as implantações finais e outras atividades de última hora. Tenha em mente que todos nós conhecemos software e pode haver soluços de última hora.

Na verdade, pretendo começar a implantar as novas atualizações de ferramentas do cliente em breve, para garantir que tudo esteja disponível assim que o tempo de execução for aberto. Portanto, se você vir novas atualizações do pacote NuGet, não presuma que o tempo de execução está lá. Espere até que a postagem no blog seja lançada e eu postarei uma atualização aqui.

Isso é uma notícia fantástica. Obrigado @normj

Ansioso pela postagem e lançamento do blog.

Não perca as esperanças de que ainda nos restam alguns dias! Estamos todos muito envolvidos esperando as implantações finais e outras atividades de última hora. Tenha em mente que todos nós conhecemos software e pode haver soluços de última hora.

Na verdade, pretendo começar a implantar as novas atualizações de ferramentas do cliente em breve, para garantir que tudo esteja disponível assim que o tempo de execução for aberto. Portanto, se você vir novas atualizações do pacote NuGet, não presuma que o tempo de execução está lá. Espere até que a postagem no blog seja lançada e eu postarei uma atualização aqui.

Sua paciência em face da atitude neste tópico é além de impressionante. Obrigado por trabalhar nisso!

@normj feliz em ajudar com qualquer teste que você queira fazer antes da publicação;)

Mais 2 dias e dedos cruzados.

E está fora com 13 horas restantes do trimestre 😅

https://aws.amazon.com/blogs/compute/announcing-aws-lambda-supports-for-net-core-3-1/

Obrigado a todos pela paciência. @raRaRa deixo a honra de encerrar este assunto.

Excelente

Na terça-feira, 31 de março de 2020, 20:06 Norm Johanson, [email protected] escreveu:

E está fora com 13 horas restantes do trimestre 😅

https://aws.amazon.com/blogs/compute/announcing-aws-lambda-supports-for-net-core-3-1/

Obrigado a todos pela paciência. @raRaRa https://github.com/raRaRa
Deixo-lhe a honra de encerrar esta edição.

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/aws/aws-lambda-dotnet/issues/554#issuecomment-606785798 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/AGUX3OUR6LN5CERIBTDHXP3RKIWLVANCNFSM4JU5UTJA
.

obrigada!!!!

E .... Cancelar inscrição :-)

Obrigado a todos os envolvidos !!!

Obrigado!

E está fora com 13 horas restantes do trimestre 😅

https://aws.amazon.com/blogs/compute/announcing-aws-lambda-supports-for-net-core-3-1/

Obrigado a todos pela paciência. @raRaRa deixo a honra de encerrar este assunto.

Bom trabalho!

Isso é AWS baby. Isso é AWS !!!
Não importa o que aconteça, no final, eles conseguem.

Muito obrigado, time !!!

Boas notícias e muito obrigado @normj !!! Correndo o risco de soar tolo e / ou ganancioso, isso também significa intrinsecamente o Powershell 7? Apenas checando ...

Excelente trabalho @normj e todos na AWS! 🥳

Aqui está o link para o blog para quem está rolando até o final
https://aws.amazon.com/blogs/compute/announcing-aws-lambda-supports-for-net-core-3-1/

incrível, um milhão de agradecimentos por adicionar suporte ao dotnet core 3.1 !!!

@andyKalman Ainda não no PowerShell 7. Estou fazendo alguns retoques finais no módulo AWSLambdaPSCore e, em seguida, enviarei a versão 2.0.0 do AWSLambdaPSCore para a galeria.

Agradeço a resposta rápida @normj . Eu vi # 607 após o fato tão bom ver que parece ser um seguimento rápido. Há outro problema a ser rastreado para que eu possa interromper os comentários aqui? :) Obrigado novamente.

Parabéns!
E obrigado equipe AWS e .NET!
Muito apreciado.

Obrigado a todos que ajudaram a fazer isso acontecer! Este é um grande lançamento e mostra muito trabalho árduo investido nele! Agradável! 🎉🥳

Obrigado !! : clap :: clap :: tada :: tada:

Parabéns pessoal, ansioso para atualizar.

Obrigado!

Ótimo trabalho, ansioso para atualizar esses lambdas.

Ótimo trabalho! Obrigado @normj 👏 👏

Bom trabalho Equipe!

Ansioso para pular em trabalhadores Lambda com assinaturas dotnet 3.1 Async Streams + AWS AppSync / GraphQL.
Equipe AWS, muito obrigado!

OMG, galera, você manda! Surpreendente! Uau! 😄😄😄

OBRIGADO!

@andyKalman Eu empurrei a versão 2.0.0 do módulo AWSLambdaPSCore que agora usa PowerShell 7. Estou planejando publicar uma postagem de blog sobre o suporte PS7, mas funciona da mesma forma que o suporte PowerShell 6 existente usa apenas 7.

@andyKalman Eu empurrei a versão 2.0.0 do módulo AWSLambdaPSCore que agora usa PowerShell 7. Estou planejando publicar uma postagem de blog sobre o suporte PS7, mas funciona da mesma forma que o suporte PowerShell 6 existente usa apenas 7.

A nova versão do AWSLambdaPSCore atualiza alguma das configurações dentro das minhas funções Lambda existentes se eu publicá-las com a nova versão? Como ele vai apontar para dotnet3.1 e ps7?

@ tr33squid Sim, se você implantar com 2.0.0, ele usará .NET Core 3.1 e PS7

Muito obrigado e ótimo trabalho, equipe AWS !!

Olá a todos,

Estou trabalhando ativamente para trazer o suporte para .NET Core 3.1 no Lambda. Leva algum tempo porque muito trabalho foi feito pela Microsoft em como eles constroem o tempo de execução. Estou trabalhando para incorporar essas mudanças para trazer a você um tempo de execução nativo.

Agradecimentos à equipe AWS-Lambda .NET core

Oi,
Estou recebendo este erro ao tentar executar AWS-Lambda
Não foi possível encontrar nenhuma versão compatível do framework.
A estrutura especificada 'Microsoft.AspNetCore.App', versão '3.1.0' não foi localizada.
alguma sugestão ??

Oi,
Estou recebendo este erro ao tentar executar AWS-Lambda
Não foi possível encontrar nenhuma versão compatível do framework.
A estrutura especificada 'Microsoft.AspNetCore.App', versão '3.1.0' não foi localizada.
alguma sugestão ??

Você precisa instalar o 3.1.0 SDK.

Acredito que Microsoft.AspNetCore.App deve ser removido do seu projeto
dependências, não são mais necessárias para o Core 3.1.0, tive que removê-lo para
construir e implantar o serviço que atualizei da versão 2.1.

Na sexta-feira, 24 de abril de 2020 às 03h24 Gregory Lyons [email protected]
escreveu:

Oi,
Estou recebendo este erro ao tentar executar AWS-Lambda
Não foi possível encontrar nenhuma versão compatível do framework.
A estrutura especificada 'Microsoft.AspNetCore.App', versão '3.1.0' era
não encontrado.
alguma sugestão ??

Você precisa instalar o 3.1.0 SDK.

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/aws/aws-lambda-dotnet/issues/554#issuecomment-618850277 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/AMSHCOLW5WJDS7CCAFDMP4TROE5ENANCNFSM4JU5UTJA
.

-
Melhor,
George

George Taskos
Arquiteto de Soluções Sênior

WeAre8
230 Park Avenue, 3º andar. Oeste
Nova York, NY 10169
(917) 717-9067
weare8.com

Entrada Privada,
71 Vanderbilt Ave
3 º andar

Eu acredito que o Microsoft.AspNetCore.App deve ser removido das dependências do seu projeto, não mais necessário para o Core 3.1.0, eu tive que removê-lo para construir e implantar o serviço que atualizei do 2.1.
…
Na sexta-feira, 24 de abril de 2020 às 03h24 Gregory Lyons @ . * > escreveu: Olá, estou recebendo este erro ao tentar executar o AWS-Lambda. Não foi possível encontrar nenhuma versão compatível do framework. A estrutura especificada 'Microsoft.AspNetCore.App', versão '3.1.0' não foi localizada. alguma sugestão ?? Você precisa instalar o 3.1.0 SDK. - Você está recebendo isto porque está inscrito neste tópico. Responda a este e-mail diretamente, visualize-o no GitHub < # 554 (comentário) > ou cancele a inscrição https://github.com/notifications/unsubscribe-auth/AMSHCOLW5WJDS7CCAFDMP4TROE5ENANCNFSM4JU5UTJA .
- Atenciosamente, George George Taskos Arquiteto de soluções sênior WeAre8 230 Park Avenue, 3th fl. West New York, NY 10169 (917) 717-9067 weare8.com Entrada privativa, 71 Vanderbilt Ave, 3º andar

Obrigado pela sua resposta,
Na verdade, esse erro foi devido ao meu erro bobo. Esqueci de remover o runtime: dotnetcore2.1 no meu serverless.yml. Agora o problema está resolvido.

Alguém faz benchmark / comparações atualizadas sobre isso? Tudo que posso encontrar são antigos com um tempo de execução personalizado.

Alguém faz benchmark / comparações atualizadas sobre isso? Tudo que posso encontrar são antigos com um tempo de execução personalizado.

Esta é uma boa.
https://medium.com/@zaccharles/a -close-look-at-net-core-3-1-on-aws-lambda-9ccec4dd96be

Além disso, minha experiência pessoal atualizando um lambda complexo 2.1 para 3.1 em um tamanho lambda de 512 MB viu quase exatamente o mesmo desempenho (inicialização a frio e quente). Tanto o lambda 2.1 quanto o 3.1 usam a camada lambda, publicação otimizada, newtonsoft (pode haver melhoria de desempenho com Microsoft json no 3.1), compilação em camadas desativada e RTR para 3.1.

Pelas minhas métricas, parece ganhar um ligeiro desempenho com o tempo de execução dotnet 3.1, mas perder desempenho no Amazon Linux 2 e inicialização do dotnet 3.1. (2.1 usa o Amazon Linux 1.) Fazendo os ganhos uma lavagem.