Aws-lambda-dotnet: .NET 5 dukungan?

Saya juga penasaran dengan topik ini, terutama karena menunggu LTS berikutnya (2021) terdengar seperti ide (bisnis) yang sangat buruk.

Merupakan kebijakan tim layanan Lambda untuk mendukung runtime versi LTS. Kami, Tim .NET AWS, mencoba mencari alternatif kami untuk melihat cara terbaik yang dapat kami lakukan untuk mendukung .NET 5 dengan Lambda karena kami tahu ada banyak kegembiraan untuk itu.

Karena penasaran menjalankan .NET dalam perspektif Lambda, apa yang paling diminati orang dengan .NET 5? Ini membantu saya mendorong prioritas.

Startup cepat, footprint rendah, dan penggunaan memori lebih rendah
kompilasi statis .NET (sebelumnya – AOT)
Interoperabilitas Java - ini bisa menjadi "fitur pembunuh"

Hai @andyfurniss4 ,

Selamat siang.

Sepertinya @normj telah memberikan masukan untuk pertanyaan ini. Mohon saran jika kami bisa menutup masalah ini.

Terima kasih,
Ashish

Karena penasaran menjalankan .NET dalam perspektif Lambda, apa yang paling diminati orang dengan .NET 5? Ini membantu saya mendorong prioritas.

Saya benar-benar ingin pindah ke C # 9 untuk Catatan, Serialisasi Json baru, Anotasi Jenis Nullable, F # 5 - dalam urutan itu

Saya ingin tahu seberapa jauh kita bisa mendapatkan dengan runtime kustom alih-alih dukungan .NET 5 asli. Terutama pemangkas tautan harus dapat memotong banyak kode yang tidak perlu, mengurangi ukuran paket. Jika pendekatan runtime kustom tidak cocok, maka saya akan sangat mendukung dukungan .NET 5 asli. Seperti yang telah ditunjukkan orang lain, driver utama adalah fitur bahasa C# yang baru.

Waktu proses khusus seharusnya berfungsi, tetapi ada bug di waktu proses .NET di 5.0 RC1 yang berarti tidak berfungsi di AWS Lambda (lihat #730). Seharusnya bagus setelah RC2 dirilis.

Apakah menggunakan dan mempertahankan runtime khusus terlalu membebani tim? Saya belum melihatnya baru-baru ini, terakhir kali sepertinya banyak usaha, tapi itu untuk CoreRT.

Misalnya mengaturnya, menggunakannya, memperbaruinya, dll?

Bagaimana dengan dukungan AWS untuk mereka?

Dari pengalaman pribadi, satu-satunya overhead berkelanjutan yang saya miliki adalah menabrak paket NuGet dan SDK sebulan sekali untuk mengambil perbaikan terbaru dan/atau patch keamanan dan kemudian menyebarkan kembali.

Kalau tidak, saya pikir beralih ke runtime khusus membutuhkan waktu sekitar satu hari untuk refactor dan menguji semuanya dan mencolokkan paket Amazon.Lambda.RuntimeSupport .

Anda harus menulis sedikit lebih banyak kode dan tetap memperbaruinya, tetapi Anda dapat menggunakan fitur-fitur terbaru segera setelah tersedia. Jika Anda tidak memiliki bandwidth untuk memperbarui semuanya, dll., maka Anda dapat menggunakan runtime bawaan tetapi kemudian Anda harus menunggu berapa lama pun waktu yang dibutuhkan tim AWS Lambda untuk membuat runtime baru tersedia di antara semua proyek mereka yang lain kerja.

Untuk kasus penggunaan saya, saya merasa overhead layak untuk dapat diperbarui pada jadwal kami sendiri, daripada terikat dengan AWS'.

YMMV.

Kami saat ini berpindah dari Oracle ke Aurora Postgres, karena mereka memperlambat pengembangan kami karena kami tidak dapat berinovasi dengan teknologi terbaru. Karena Entity Framework Drivers untuk Oracle menargetkan .NET Core 3.X baru saja dirilis. Namun, kami menyadari bahwa kami harus tetap menggunakan LTS karena mereka. Tapi dukungan LTS tidak bisa datang beberapa bulan kemudian. Mengingat bahwa saya pikir .NET 5.0 juga merupakan pengecualian yang baik untuk rencana LTS, karena ini merupakan perubahan fungsionalitas yang monumental.

Adakah berita tentang ini sekarang setelah .NET 5 dirilis?

Minat utama saya adalah C# 9 dan semua pembaruan System.Text.Json .

Ingatlah bahwa Anda dapat menggunakan kemampuan Custom Runtime untuk menggunakan .NET 5 hari ini: https://aws.amazon.com/blogs/developer/net-core-3-0-on-lambda-with-aws-lambdas- kustom-runtime/

Saya belum mencobanya, tetapi dengan pemangkasan kode, yang baru di .NET 5, pengalamannya akan jauh lebih baik daripada dengan .NET Core 3.0.

Merupakan kebijakan tim layanan Lambda untuk mendukung runtime versi LTS. Kami, Tim .NET AWS, mencoba mencari alternatif kami untuk melihat cara terbaik yang dapat kami lakukan untuk mendukung .NET 5 dengan Lambda karena kami tahu ada banyak kegembiraan untuk itu.

Karena penasaran menjalankan .NET dalam perspektif Lambda, apa yang paling diminati orang dengan .NET 5? Ini membantu saya mendorong prioritas.

Apakah ini berarti menjalankan aplikasi lambda dengan .NET 5 hanya akan didukung setelah .NET 5.0 dipindahkan dari "saat ini" ke "LTS"?

.NET 5.0 tidak akan pernah menjadi LTS. .NET 6.0 akan menjadi versi LTS berikutnya.

.NET 5.0 tidak akan pernah menjadi LTS. .NET 6.0 akan menjadi versi LTS berikutnya.

Apa sebenarnya artinya ini sehubungan dengan lambda dan dukungannya untuk menggunakan .NET 5.0?

Ini berarti kita seharusnya tidak mengharapkan dukungan untuk .NET 5 di Lambda karena itu tidak akan menjadi LTS.

Ini berarti kita seharusnya tidak mengharapkan dukungan untuk .NET 5 di Lambda karena itu tidak akan menjadi LTS.

Terima kasih @bjorg . Jika ini kesimpulannya, bukankah seharusnya masalah ini ditutup dengan ini sebagai jawaban langsung?

Saya mengangkat ini dengan mengetahui bahwa .NET 5 bukan LTS dan bahwa tim AWS hanya mendukung LTS. Saya bertanya-tanya apakah pengecualian akan dibuat karena besarnya rilis dan fakta bahwa LTS berikutnya tidak akan sampai akhir 2021. Masalahnya, kami belum memiliki "ya" atau "tidak" yang eksplisit namun jadi saya tidak berpikir kita harus menutup ini dulu. Rilis .NET 5 telah datang dan pergi (seperti yang terjadi pada 3.1) dan kami tidak memiliki dukungan Lambda tetapi itu tidak berarti A) mereka tidak mengerjakannya atau B) mereka tidak berencana untuk melakukannya.

Jika orang-orang AWS telah memutuskan untuk tidak mendukung .NET 5 dan mereka menjelaskannya, maka mari kita tutup masalah ini. Jika demikian halnya, maka kita hanya perlu menunggu 12-18 bulan lagi untuk versi .NET yang didukung berikutnya.

Juga, saya mengerti bahwa ada sejuta hal lain untuk dikerjakan dan ini mungkin tidak sepele. Saya suka hal-hal baru yang mengkilap

Sebenarnya, mengingat kecepatan yang telah diputuskan Microsoft untuk diberikan kepada .NET, tidak masuk akal untuk menunggu rilis LTS setiap tahun. Karena bahkan rilis saat ini berbau seperti LTS ketika itu pasti akan bertahan selama 15 bulan (dukungan 1 tahun + 3 bulan).

Saya akan baik-baik saja jika AWS mendefinisikan LTS dan runtime saat ini sehingga kami, pelanggan, dapat memutuskan jalur mana yang ingin kami tetapkan.

Sejujurnya, saya akan baik-baik saja dengan runtime khusus yang sudah dimasak sebelumnya untuk runtime di jalur saat ini.

Sejujurnya, saya akan baik-baik saja dengan runtime khusus yang sudah dimasak sebelumnya untuk runtime di jalur saat ini.

Anda mengatakan itu, tetapi yang lain mungkin tidak begitu antusias untuk mendapatkan pemberitahuan dari AWS pada November 2021 yang memberi tahu mereka bahwa mereka memiliki waktu 3 bulan untuk memperbarui dari 5.x ke 6.0 sebelum Lambdas mereka keluar dari semua dukungan dari AWS.

Banyak yang bisa berubah dalam setahun dan tiba-tiba sebuah tim mungkin tidak memiliki bandwidth untuk bereaksi terhadap kebutuhan untuk memperbarui Lambda yang mungkin tidak tersentuh selama berbulan-bulan untuk tetap mendukung yang sebelumnya dilakukan atas nama mereka oleh Amazon memperbarui host runtime sesuai kebutuhan tanpa harus memikirkannya.

Tentu, mungkin ada runtime saat ini yang sudah dimasak sebelumnya dengan banyak peringatan dan peringatan di dalamnya, tetapi itu akan datang dengan kompleksitas dan nuansa dukungannya sendiri yang perlu dipahami pengguna.

Akan sangat bagus jika Lambda mendukung semua versi utama baru .NET pada hari mereka dirilis oleh Microsoft, tetapi saya membayangkan kepraktisan melakukan itu pada skala mereka adalah mengapa segala sesuatunya seperti sekarang ini.

Jika Anda benar-benar ingin menjadi yang terdepan dan memutakhirkan sesegera mungkin dan mendukung hal-hal sendiri dan melakukan hal Anda sendiri dan menerima semua konsekuensinya, maka untuk itulah runtime kustom.

Masalahnya, kami jelas tidak berada di ujung tombak. .NET Core bergerak cepat dan sangat stabil. Lihat di NuGet sekarang dan ada paket untuk 5.0.0. Mereka untuk konsumsi publik sekarang.

Meskipun saya belum mencoba memutakhirkan proyek DotNet Core 3.1 ke DotNet 5, sejauh ini, saya tidak mengalami masalah besar apa pun hanya dengan memutakhirkan (mis. dari 2.1 ke 3.1).

DotNet 5 mungkin merupakan binatang yang berbeda, tetapi runtime khusus bagi saya adalah untuk lingkungan yang lebih tidak biasa seperti C++ Lambda.

Saya lebih suka pembaruan dan pindah ke DotNet 5 Lambda lebih cepat daripada nanti. 2020 telah membuktikan bahwa setahun adalah waktu yang lama :-)

Saya melihat dari mana Anda berasal dari @martincostello.

Tapi ini adalah jenis pilihan yang harus ada pada pelanggan: going Current atau LTS.

AWS tidak merilis runtime di Current karena pelanggan yang memilihnya dapat menemukan dirinya dalam masalah karena itu adalah distorsi tanggung jawab AWS terhadap pelanggannya. Mereka harus menyediakan alat dan membiarkan semua orang memutuskan alat mana yang paling cocok untuk mereka.

Menambahkan apa yang dikatakan @genifycom , fungsi Lambda biasanya sangat sederhana dan seringkali kode mereka tidak bergantung pada fitur khusus dari suatu kerangka kerja sehingga menyulitkan untuk berpindah dari satu versi utama ke versi lainnya (jelas ada anomali) .

Di perusahaan saya, kami memiliki puluhan fungsi dan sebagian besar waktu kami memutakhirkannya dengan pencarian/penggantian di seluruh folder (sedikit lebih rumit ketika kami harus menghapus properti LambdaTools tertentu dari file proyek).

Saya juga ingin melihat dukungan transitif untuk dotnet 5 hingga versi LTS tersedia. (ini terjadi di masa lalu dengan versi lain)

Satu-satunya pilihan yang tersedia saat ini adalah:

• tetap dengan dotnet core 3.1 dan tunggu sampai dotnet 6 :(
• gunakan runtime khusus (yang dengan sendirinya akan baik-baik saja, karena kurangnya AOT asli yang cukup di dotnet 5, waktu startup kemungkinan akan terpengaruh sejauh itu akan mematikan ide pengembang https://medium.com/ @zaccharles/benchmarking-lambdas-new-custom-runtime-for-net-core-43ea79b5a35a)

Zac menindaklanjuti posting asli itu dengan detail lebih lanjut tentang cara meningkatkan kinerja startup untuk runtime khusus: https://medium.com/@zaccharles/net -core-3-0-aws-lambda-benchmarks-and-recommendations- 8fee4dc131b0

Saya harap dia memposting versi .NET 5, karena ada banyak perbaikan kompilasi di .NET 5 yang tidak ada di .NET Core 3.1, seperti pemangkasan kode, yang akan sangat berguna dengan runtime kustom.