Aws-lambda-dotnet: .NET 5-Unterstützung?

Auch ich bin neugierig auf dieses Thema, zumal das Warten auf den nächsten LTS (2021) nach einer sehr schlechten (Geschäfts-)Idee klingt.

Es ist die Richtlinie des Lambda-Serviceteams, LTS-Versionen von Laufzeiten zu unterstützen. Wir, das AWS .NET-Team, versuchen, unsere Alternativen durchzuarbeiten, um herauszufinden, wie wir .NET 5 mit Lambda am besten unterstützen können, da wir wissen, dass es viel Aufregung dafür gibt.

Aus Neugier, .NET in der Lambda-Perspektive auszuführen, woran interessieren sich die Leute bei .NET 5 am meisten? Das hilft mir, Prioritäten zu setzen.

Schneller Start, geringer Platzbedarf und geringerer Speicherverbrauch
statische Kompilierung von .NET (Ahead-of-Time – AOT)
Java-Interoperabilität - dies könnte ein "Killer-Feature" sein

Hallo @andyfurniss4 ,

Guten Tag.

Sieht so aus, als hätte @normj einen Beitrag zu dieser Frage geleistet. Bitte teilen Sie uns mit, ob wir dieses Problem schließen können.

Vielen Dank,
Ashish

Aus Neugier, .NET in der Lambda-Perspektive auszuführen, woran interessieren sich die Leute bei .NET 5 am meisten? Das hilft mir, Prioritäten zu setzen.

Ich möchte wirklich zu C# 9 für Records wechseln, neue Json-Serialisierung, Nullable Type Annotations, F# 5 - in dieser Reihenfolge

Ich wäre gespannt, wie weit wir mit einer benutzerdefinierten Laufzeit anstelle der nativen .NET 5-Unterstützung kommen können. Vor allem der Link-Trimmer sollte in der Lage sein, viel unnötigen Code herauszuschneiden, wodurch die Paketgröße reduziert wird. Wenn der benutzerdefinierte Runtime-Ansatz nicht geeignet ist, wäre ich sehr für eine native .NET 5-Unterstützung. Wie andere bereits erwähnt haben, sind die neuen C#-Sprachfeatures der Haupttreiber.

Eine benutzerdefinierte Laufzeit sollte funktionieren, aber es gibt einen Fehler in der .NET-Laufzeit in 5.0 RC1, der bedeutet, dass sie in AWS Lambda nicht funktioniert (siehe #730). Sollte gut sein, sobald RC2 veröffentlicht wird.

Ist die Verwendung und Pflege einer benutzerdefinierten Laufzeit ein großer Aufwand für Teams? Ich habe es in letzter Zeit nicht untersucht, das letzte Mal schien es viel Aufwand zu sein, aber das war für CoreRT.

ZB eine einrichten, verwenden, aktualisieren usw.?

Was ist mit dem AWS-Support für sie?

Aus eigener Erfahrung besteht der einzige laufende Aufwand, den ich habe, darin, die NuGet-Pakete und das SDK einmal im Monat zu stoßen, um die neuesten Fixes und/oder Sicherheitspatches zu erhalten, und dann erneut bereitzustellen.

Ansonsten glaube ich, dass der Wechsel zu einer benutzerdefinierten Laufzeit etwa einen Tag gedauert hat, um alles umzugestalten und zu testen und das Amazon.Lambda.RuntimeSupport Paket einzufügen.

Sie müssen ein wenig mehr Code schreiben und auf dem neuesten Stand halten, aber Sie können die neuesten Funktionen nutzen, sobald sie verfügbar sind. Wenn Sie nicht über die Bandbreite verfügen, um Dinge auf dem neuesten Stand zu halten usw., können Sie die integrierte Laufzeit verwenden, müssen jedoch so lange warten, bis das AWS Lambda-Team die neue Laufzeit für alle anderen Projekte verfügbar macht Arbeit.

Für meine Anwendungsfälle bin ich der Meinung, dass es sich lohnt, den Overhead nach unseren eigenen Zeitplänen aktualisieren zu können, anstatt an AWS gebunden zu sein.

YMMV.

Wir wechseln derzeit von Oracle zu Aurora Postgres, da diese unsere Entwicklung verlangsamt haben, da wir nicht in der Lage waren, mit der neuesten Technologie zu innovieren. Da es sich um Entity Framework Drivers for Oracle handelt, die auf .NET Core 3.X abzielen, wurde gerade veröffentlicht. Wir haben jedoch erkannt, dass wir wegen ihnen auf LTS bleiben müssen. Aber der LTS-Support kann Monate später nicht kommen. Da ich denke, dass .NET 5.0 auch eine gute Ausnahme vom LTS-Plan ist, da es sich um eine so monumentale Verschiebung der Funktionalität handelt.

Irgendwelche Neuigkeiten dazu jetzt, da .NET 5 veröffentlicht wird?

Meine Hauptinteressen sind C# 9 und all die System.Text.Json Updates.

Denken Sie daran, dass Sie die benutzerdefinierte Laufzeitfunktion verwenden können, um .NET 5 noch heute zu verwenden: https://aws.amazon.com/blogs/developer/net-core-3-0-on-lambda-with-aws-lambdas- benutzerdefinierte Laufzeit/

Ich habe es noch nicht ausprobiert, aber mit der Codekürzung, die in .NET 5 neu ist, sollte die Erfahrung viel besser sein als mit .NET Core 3.0.

Es ist die Richtlinie des Lambda-Serviceteams, LTS-Versionen von Laufzeiten zu unterstützen. Wir, das AWS .NET-Team, versuchen, unsere Alternativen durchzuarbeiten, um herauszufinden, wie wir .NET 5 mit Lambda am besten unterstützen können, da wir wissen, dass es viel Aufregung dafür gibt.

Aus Neugier, .NET in der Lambda-Perspektive auszuführen, woran interessieren sich die Leute bei .NET 5 am meisten? Das hilft mir, Prioritäten zu setzen.

Bedeutet dies, dass die Ausführung von Lambda-Apps mit .NET 5 erst unterstützt wird, nachdem .NET 5.0 von "aktuell" auf "LTS" verschoben wurde?

.NET 5.0 wird nie LTS sein. .NET 6.0 wird die nächste LTS-Version sein.

.NET 5.0 wird nie LTS sein. .NET 6.0 wird die nächste LTS-Version sein.

Was genau bedeutet dies in Bezug auf Lambdas und ihre Unterstützung für die Verwendung von .NET 5.0?

Das bedeutet, dass wir keine Unterstützung für .NET 5 auf Lambda erwarten sollten, da es sich nicht um LTS handeln wird.

Das bedeutet, dass wir keine Unterstützung für .NET 5 auf Lambda erwarten sollten, da es sich nicht um LTS handeln wird.

Danke @björg . Wenn dies die Schlussfolgerung ist, sollte diese Frage dann nicht mit dieser direkten Antwort abgeschlossen werden?

Ich habe dies in dem Wissen angesprochen, dass .NET 5 kein LTS ist und dass das AWS-Team nur LTS unterstützt. Ich habe mich gefragt, ob aufgrund des Umfangs der Veröffentlichung und der Tatsache, dass der nächste LTS erst Ende 2021 stattfinden wird, eine Ausnahme gemacht wird. Die Sache ist die, wir hatten kein explizites "Ja" oder "Nein" dennoch denke ich, dass wir dies noch nicht schließen sollten. Die .NET 5-Version ist gekommen und gegangen (genau wie bei 3.1) und wir haben keine Lambda-Unterstützung, aber das bedeutet nicht, dass A) sie nicht daran arbeiten oder B) sie nicht planen.

Wenn die AWS-Leute entschieden haben, .NET 5 nicht zu unterstützen, und dies klarstellen, dann lassen Sie uns dieses Thema schließen. Wenn dies der Fall ist, müssen wir nur noch 12-18 Monate auf die nächste unterstützte .NET-Version warten.

Außerdem verstehe ich, dass es noch eine Million andere Dinge gibt, an denen man arbeiten muss, und das ist wahrscheinlich nicht trivial. Ich mag einfach die glänzenden neuen Sachen 😋

Die Wahrheit ist, dass es angesichts des Tempos, das Microsoft für .NET entschieden hat, keinen Sinn macht, alle zwei Jahre auf eine LTS-Veröffentlichung zu warten. Denn selbst die aktuelle Veröffentlichung riecht nach LTS, wenn sie 15 Monate lang bleiben wird (1 Jahr + 3 Monate Support).

Mir wäre gut, wenn AWS LTS- und Current-Laufzeiten definieren würde, damit wir Kunden entscheiden könnten, auf welchem ​​Weg wir bleiben wollen.

Ehrlich gesagt wäre ich mit einer vorgefertigten benutzerdefinierten Laufzeit für Laufzeiten auf dem aktuellen Pfad in Ordnung.

Ehrlich gesagt wäre ich mit einer vorgefertigten benutzerdefinierten Laufzeit für Laufzeiten auf dem aktuellen Pfad in Ordnung.

Sie sagen das, aber andere sind möglicherweise nicht so begeistert, dass sie im November 2021 eine Benachrichtigung von AWS erhalten, in der ihnen mitgeteilt wird, dass sie 3 Monate Zeit haben, um von 5.x auf 6.0 zu aktualisieren, bevor ihre Lambdas den gesamten Support von AWS einstellen.

Vieles kann sich in einem Jahr ändern und plötzlich hat ein Team möglicherweise nicht die Bandbreite, um auf die Notwendigkeit zu reagieren, ein Lambda zu aktualisieren, das möglicherweise monatelang nicht angerührt wurde, um den Support aufrechtzuerhalten, der zuvor von Amazon in seinem Namen durchgeführt wurde, um die gehosteten Laufzeit nach Bedarf, ohne darüber nachdenken zu müssen.

Sicher, es könnte eine aktuelle vorgefertigte aktuelle Laufzeit mit vielen Warnungen und Vorbehalten geben, aber das würde mit eigenen Support-Komplexitäten und Nuancen einhergehen, die Benutzer verstehen müssten.

Es wäre großartig, wenn Lambda alle neuen Hauptversionen von .NET ab dem Tag unterstützt, an dem sie von Microsoft veröffentlicht werden, aber ich kann mir vorstellen, dass die Praktikabilität in ihrem Umfang der Grund dafür ist, dass die Dinge jetzt so sind, wie sie sind.

Wenn Sie wirklich, wirklich auf dem neuesten Stand sein und so schnell wie möglich upgraden möchten, Dinge selbst unterstützen und Ihr eigenes Ding machen und alle Konsequenzen akzeptieren möchten, dann sind benutzerdefinierte Laufzeiten da.

Das Problem ist, dass wir offensichtlich nicht auf dem neuesten Stand sind. .NET Core bewegt sich schnell und war bemerkenswert stabil. Schauen Sie jetzt in NuGet nach und Pakete sind für 5.0.0 da. Sie sind jetzt für den öffentlichen Konsum bestimmt.

Obwohl ich noch nicht versucht habe, ein DotNet Core 3.1-Projekt auf DotNet 5 zu aktualisieren, sind mir beim bloßen Upgrade (zB von 2.1 auf 3.1) keine größeren Probleme begegnet.

DotNet 5 mag ein anderes Tier sein, aber die benutzerdefinierten Laufzeiten sind für mich für ungewöhnlichere Umgebungen wie C++ Lambda.

Ich würde lieber die Updates haben und lieber früher als später auf DotNet 5 Lambda umsteigen. 2020 hat bewiesen, dass ein Jahr eine lange Zeit ist :-)

Ich sehe, woher du kommst @martincostello.

Aber dies ist die Art der Wahl, die Kunden haben sollten: Current oder LTS.

AWS veröffentlicht keine Laufzeiten auf Current, weil ein Kunde, der sich dafür entschieden hat, in Schwierigkeiten geraten könnte, da dies eine Verzerrung der Verantwortung von AWS gegenüber seinen Kunden darstellt. Sie sollten die Werkzeuge zur Verfügung stellen und jeden entscheiden lassen, welches Werkzeug für sie am besten geeignet ist.

Zusätzlich zu dem, was basiert meistens nicht auf spezifischen Funktionen eines Frameworks, so dass es schwierig ist, von einer Hauptversion zu einer anderen zu wechseln (offensichtlich gibt es Anomalien). .

In meinem Unternehmen haben wir Dutzende von Funktionen und die meiste Zeit aktualisieren wir sie mit einem ordnerweiten Suchen/Ersetzen (es war etwas komplexer, als wir die spezifische LambdaTools-Eigenschaft aus der Projektdatei entfernen mussten).

Auch ich würde gerne eine transitive Unterstützung für dotnet 5 sehen, bis eine LTS-Version verfügbar ist. (Dies geschah in der Vergangenheit mit einer anderen Version)

Die einzigen zur Zeit verfügbaren Optionen sind:

• bleib bei dotnet core 3.1 und warte bis dotnet 6 :(
• Verwenden Sie eine benutzerdefinierte Laufzeit (was an sich in Ordnung wäre, aber aufgrund des Mangels an ausreichend nativem AOT in dotnet 5 würden die Startzeiten wahrscheinlich so stark beeinträchtigt werden, dass es Entwickler von der Idee abschrecken würde https://medium.com/ @zaccharles/benchmarking-lambdas-new-custom-runtime-for-net-core-43ea79b5a35a)

Zac folgte diesem ursprünglichen Beitrag mit weiteren Details zur Verbesserung der Startleistung für die benutzerdefinierte Laufzeit: https://medium.com/@zaccharles/net -core-3-0-aws-lambda-benchmarks-and-recommendations- 8fee4dc131b0

Ich hoffe, dass er eine .NET 5-Version veröffentlicht, da es viele Kompilierungsverbesserungen in .NET 5 gibt, die in .NET Core 3.1 nicht vorhanden waren, z. B. Codekürzung, die mit der benutzerdefinierten Laufzeit sehr nützlich wäre.