Aws-lambda-dotnet: .NET 5のサポート？

特に次のLTS（2021）を待つことは非常に悪い（ビジネス）アイデアのように聞こえるので、私もこのトピックについて興味があります。

ランタイムのLTSバージョンをサポートすることはLambdaサービスチームのポリシーです。 私たちAWS.NETチームは、Lambdaに多くの興奮があることを知っているので、Lambdaで.NET5をサポートする最善の方法を見つけるために代替案を検討しています。

ラムダの観点から.NETを実行することへの好奇心から、.NET 5で最も興味を持っている人は何ですか？ これは私が優先順位を押し上げるのに役立ちます。

高速起動、低フットプリント、および低メモリ使用量
.NETの静的コンパイル（事前– AOT）
Javaの相互運用性-これは「キラー機能」である可能性があります

こんにちは@ andyfurniss4 、

こんにちは。

@normjがこの質問に入力を提供したよう

ありがとう、
Ashish

ラムダの観点から.NETを実行することへの好奇心から、.NET 5で最も興味を持っている人は何ですか？ これは私が優先順位を押し上げるのに役立ちます。

レコード、新しいJsonシリアル化、Nullable Type Annotations、F＃5-の順序でC＃9に本当に移行したい

ネイティブの.NET5サポートの代わりにカスタムランタイムを使用してどこまで到達できるかを知りたいと思います。 特にリンクトリマーは、多くの不要なコードを切り取り、パッケージサイズを縮小できるはずです。 カスタムランタイムアプローチが適切でない場合は、ネイティブの.NET5サポートを非常に支持します。 他の人が指摘しているように、主要な推進力は新しいC＃言語機能です。

カスタムランタイムは機能するはずですが、5.0 RC1の.NETランタイムにはバグがあり、AWS Lambdaでは機能しません（＃730を参照）。 RC2がリリースされたら良いはずです。

カスタムランタイムを使用および維持することは、チームにとって多くのオーバーヘッドですか？ 最近は調べていませんが、前回は大変な努力のようでしたが、それはCoreRTの場合でした。

たとえば、セットアップ、使用、更新などですか？

それらに対するAWSサポートはどうですか？

個人的な経験から、私が抱えている唯一の継続的なオーバーヘッドは、月に1回NuGetパッケージとSDKをぶつけて、最新の修正やセキュリティパッチを取得し、再展開することです。

それ以外の場合、カスタムランタイムに切り替えると、すべてをリファクタリングしてテストし、 Amazon.Lambda.RuntimeSupportパッケージをプラグインするのに約1日かかったと思います。

もう少しコードを記述して最新の状態に保つ必要がありますが、最新の機能が利用可能になり次第、使用することができます。 更新などを維持するための帯域幅がない場合は、組み込みのランタイムを使用できますが、AWSLambdaチームが他のすべてのプロジェクトで新しいランタイムを利用できるようになるまで待つ必要があります仕事。

私のユースケースでは、オーバーヘッドはAWSに縛られるのではなく、独自のスケジュールで更新できる価値があると感じています。

YMMV。

現在、OracleからAurora Postgresに移行しています。最新のテクノロジーでイノベーションを起こすことができなかったため、開発が遅れたためです。 .NET Core3.XをターゲットとするOracle用のEntityFrameworkDriversがリリースされたばかりです。 しかし、私たちはそれらのためにLTSにとどまる必要があることに気づきました。 しかし、LTSのサポートは数か月後には実現できません。 .NET 5.0も、機能の大きな変化であるため、LTSプランの良い例外だと思います。

.NET 5がリリースされた今、これに関するニュースはありますか？

私の主な関心はC＃9とすべてのSystem.Text.Jsonアップデートです。

カスタムランタイム機能を使用して、今日.NET 5を使用できることに注意してください： //aws.amazon.com/blogs/developer/net-core-3-0-on-lambda-with-aws-lambdas-カスタムランタイム/

まだ試していませんが、.NET 5の新機能であるコードトリミングを使用すると、.NET Core3.0よりもはるかに優れたエクスペリエンスが得られるはずです。

ランタイムのLTSバージョンをサポートすることはLambdaサービスチームのポリシーです。 私たちAWS.NETチームは、Lambdaに多くの興奮があることを知っているので、Lambdaで.NET5をサポートする最善の方法を見つけるために代替案を検討しています。

ラムダの観点から.NETを実行することへの好奇心から、.NET 5で最も興味を持っている人は何ですか？ これは私が優先順位を押し上げるのに役立ちます。

これは、.NET 5.0でラムダアプリを実行すると、.NET 5.0が「現在」から「LTS」に移行した場合にのみサポートされることを意味しますか？

.NET5.0がLTSになることはありません。 .NET6.0は次のLTSバージョンになります。

.NET5.0がLTSになることはありません。 .NET6.0は次のLTSバージョンになります。

ラムダと.NET5.0の使用のサポートに関して、これは正確にはどういう意味ですか？

これは、Lambdaでの.NET 5のサポートがLTSになることはないため、期待すべきではないことを意味します。

これは、Lambdaでの.NET 5のサポートがLTSになることはないため、期待すべきではないことを意味します。

ありがとう@bjorg 。 これが結論である場合、この問題は直接の答えとしてこれで閉じられるべきではありませんか？

.NET 5はLTSではなく、AWSチームはLTSのみをサポートしていることを知って、これを提起しました。 リリースの規模と、次のLTSは2021年の終わりまで行われないという事実のために、例外が発生するのではないかと思っていました。つまり、明示的な「はい」または「いいえ」はありませんでした。まだですので、まだこれを閉じるべきではないと思います。 .NET 5のリリースは（3.1の場合と同じように）行ったり来たりしており、Lambdaのサポートはありませんが、A）作業していない、またはB）計画していないという意味ではありません。

AWSの担当者が.NET5をサポートしないことを決定し、これを明確にした場合は、この問題を解決しましょう。 その場合は、サポートされる次の.NETバージョンまでさらに12〜18か月待つ必要があります。

また、他にも取り組むべきことが何百万もあることを理解していますが、これはおそらく些細なことではありません。 私は光沢のある新しいものが好きです😋

真実は、マイクロソフトが.NETに与えることを決定したペースを考えると、隔年でLTSのリリースを待つことは意味がないということです。 現在のリリースでさえ、15か月間（1年+ 3か月のサポート）とどまると、LTSのようなにおいがするからです。

AWSがLTSとCurrentランタイムを定義して、お客様がどのパスを維持するかを決定できるようにすれば問題ありません。

正直なところ、Currentパス上のランタイム用に事前に作成されたカスタムランタイムで問題ありません。

正直なところ、Currentパス上のランタイム用に事前に作成されたカスタムランタイムで問題ありません。

あなたはそう言いますが、2021年11月にAWSからLambdasがAWSからのすべてのサポートを終了する前に、5.xから6.0に更新するのに3か月あるという通知を受け取ることにそれほど熱心ではないかもしれません。

1年で多くの変更が発生する可能性があり、突然、チームは、ホストを更新するAmazonによって以前に行われていたサポートを維持するために、数か月間触れられなかった可能性のあるLambdaを更新する必要性に対応する帯域幅を持たなくなる可能性があります。必要に応じて、それについて考える必要のないランタイム。

確かに、警告や警告がたくさんある現在の調理済みの現在のランタイムが存在する可能性がありますが、それはユーザーが理解する必要のある独自のサポートの複雑さとニュアンスを伴います。

LambdaがMicrosoftからリリースされた時点で.NETのすべての新しいメジャーバージョンをサポートしていれば素晴らしいのですが、その規模でそれを行うことの実用性が、現在の状況にある理由だと思います。

あなたが本当に、本当に最先端にいて、できるだけ早くアップグレードして、自分で物事をサポートし、あなた自身のことをして、すべての結果を受け入れたいのなら、それはカスタムランタイムのようなものです。

問題は、私たちが明らかに最先端にいるわけではないということです。 .NET Coreは高速で動作し、非常に安定しています。 今すぐNuGetを調べてください。パッケージは、5.0.0用にあります。 現在、一般消費者向けです。

DotNet Core3.1プロジェクトをDotNet5にアップグレードしようとしたことはありませんが、アップグレードするだけで大​​きな問題が発生することはありません（2.1から3.1など）。

DotNet 5は別の獣かもしれませんが、私にとってのカスタムランタイムは、C ++ Lambdaのようなもっと珍しい環境用です。

私はむしろアップデートを入手して、後でではなく早くDotNet 5Lambdaに移行したいと思っています。 2020年は1年が大変な時期であることを証明しました:-)

@martincostelloからあなたがどこから来ているのかわかります。

しかし、これは顧客にあるべき種類の選択です：CurrentまたはLTSに移行します。

AWSは、Currentでランタイムをリリースしていません。これは、ランタイムを選択した顧客が問題を抱えている可能性があるためです。これは、AWSが顧客に対して負う責任の歪みです。 彼らはツールを提供し、どのツールが彼らに最も適しているかを全員に決定させるべきです。

@genifycomが言ったことに

私の会社には数十の関数があり、ほとんどの場合、フォルダー全体の検索/置換を使用してそれらをアップグレードします（プロジェクトファイルから特定のLambdaToolsプロパティを削除する必要がある場合は少し複雑でした）。

私も、LTSバージョンが利用可能になるまでdotnet5の推移的なサポートを望んでいます。 （これは過去に別のバージョンで発生しました）

現在利用可能な唯一のオプションは次のとおりです。

• dotnet core 3.1を使い続け、dotnet6まで待ちます:(
• カスタムランタイムを使用します（ただし、dotnet 5には十分なネイティブAOTがないため、起動時間は、開発者がアイデアをオフにする程度に影響を受ける可能性がありますhttps://medium.com/ @ zaccharles / Benchmarking-lambdas-new-custom-runtime-for-net-core-43ea79b5a35a）

Zacは、カスタムランタイムの起動パフォーマンスを改善する方法の詳細について、その元の投稿をフォローアップしました： https ：//medium.com/@zaccharles/net -core-3-0-aws-lambda-benchmarks-and-recommendations- 8fee4dc131b0

カスタムランタイムで非常に役立つコードトリミングなど、.NET Core3.1には存在しなかった多くのコンパイルの改善が.NET5にあるため、彼が.NET5バージョンを投稿することを願っています。