Aws-lambda-dotnet: دعم NET 5؟

تم إنشاؤها على ٢٦ أغسطس ٢٠٢٠  ·  26تعليقات  ·  مصدر: aws/aws-lambda-dotnet

أعتذر إذا تم طرح هذا السؤال من قبل ، فلا تتردد في الإغلاق وتوجيهي إلى الإجابة إذا كان الأمر كذلك. لقد ألقيت نظرة ولكن لم أجد الإجابة على أي حال.

لم يتم وضع علامة على .NET 5 على أنه إصدار LTS: https://devblogs.microsoft.com/dotnet/introducing-net-5/

أعلم أن سياسة فريق Lambda هي دعم إصدارات .NET LTS فقط ولكن هل ينطبق ذلك على .NET 5 أيضًا أم سيتم استثناء استثناء بالنظر إلى أنه كبير جدًا (توحيد NET Core و .NET Framework)؟ سيكون من العار إذا اضطررنا إلى الانتظار حتى أواخر عام 2021 / أوائل عام 2022 للحصول على إصدار .NET المدعوم التالي (.NET 6) وجميع الأشياء الجيدة الإضافية التي تأتي معه.

modullambda-client-lib

التعليق الأكثر فائدة

هل من أخبار عن هذا الآن بعد إطلاق .NET 5؟

ال 26 كومينتر

لدي فضول أيضًا بشأن هذا الموضوع ، خاصة وأن انتظار LTS (2021) التالي يبدو وكأنه فكرة (تجارية) سيئة للغاية.

تتمثل سياسة فريق خدمة Lambda في دعم إصدارات LTS من أوقات التشغيل. نحن ، فريق AWS .NET ، نحاول العمل من خلال بدائلنا لمعرفة أفضل السبل التي يمكننا من خلالها دعم .NET 5 مع Lambda لأننا نعلم أن هناك الكثير من الإثارة لذلك.

بدافع الفضول من تشغيل .NET في منظور Lambda ، ما أكثر الأشخاص الذين يهتمون بـ .NET 5؟ هذا يساعدني على دفع الأولويات.

بدء تشغيل سريع ، ومساحة منخفضة ، واستخدام أقل للذاكرة
تجميع ثابت لـ .NET (في وقت مبكر - AOT)
إمكانية التشغيل المتداخل مع Java - قد تكون هذه "ميزة قاتلة"

مرحبًا @ andyfurniss4 ،

مساء الخير.

يبدو أن normj قد قدم مدخلات حول هذا السؤال. يرجى تقديم المشورة إذا كان بإمكاننا إغلاق هذه المشكلة.

شكرا،
اشيش

بدافع الفضول من تشغيل .NET في منظور Lambda ، ما أكثر الأشخاص الذين يهتمون بـ .NET 5؟ هذا يساعدني على دفع الأولويات.

أريد حقًا الانتقال إلى C # 9 للسجلات ، وتسلسل Json الجديد ، والتعليقات التوضيحية من النوع Nullable ، و F # 5 - بهذا الترتيب

سأكون فضوليًا لمعرفة المدى الذي يمكننا الحصول عليه من خلال وقت تشغيل مخصص بدلاً من دعم .NET 5 الأصلي. يجب أن تكون أداة قطع الارتباط قادرة على قطع الكثير من التعليمات البرمجية غير الضرورية ، مما يقلل من حجم الحزمة. إذا لم يكن نهج وقت التشغيل المخصص مناسبًا ، فسأؤيد دعم NET 5 الأصلي كثيرًا. كما أشار آخرون ، سيكون المحرك الأساسي هو ميزات لغة C # الجديدة.

يجب أن يعمل وقت التشغيل المخصص ، ولكن هناك خطأ في وقت تشغيل .NET في 5.0 RC1 مما يعني أنه لا يعمل في AWS Lambda (انظر # 730). يجب أن يكون جيدًا بمجرد إصدار RC2.

هل استخدام وقت التشغيل المخصص والحفاظ عليه يمثل الكثير من النفقات العامة للفرق؟ لم أبحث في الأمر مؤخرًا ، في المرة الأخيرة بدا أنه بذل الكثير من الجهد ، ولكن كان ذلك من أجل CoreRT.

على سبيل المثال ، إنشاء واحد ، واستخدامه ، وتحديثه ، وما إلى ذلك؟

ماذا عن دعم AWS لهم؟

من التجربة الشخصية ، فإن النفقات العامة الجارية الوحيدة التي أملكها هي إرسال حزمة (حزم) NuGet و SDK مرة واحدة شهريًا لالتقاط أحدث الإصلاحات و / أو تصحيحات الأمان ثم إعادة النشر.

بخلاف ذلك ، أعتقد أن التبديل إلى وقت تشغيل مخصص استغرق مني يومًا تقريبًا لإعادة بناء واختبار كل شيء وتوصيل الحزمة Amazon.Lambda.RuntimeSupport .

يجب عليك كتابة المزيد من التعليمات البرمجية قليلاً وتحديثها باستمرار ، ولكن يمكنك استخدام أحدث الميزات بمجرد توفرها. إذا لم يكن لديك النطاق الترددي للحفاظ على تحديث الأشياء وما إلى ذلك ، فيمكنك استخدام وقت التشغيل المدمج ولكن عليك بعد ذلك الانتظار لفترة طويلة يستغرقها فريق AWS Lambda لإتاحة وقت التشغيل الجديد بين جميع مشاريعهم الأخرى الشغل.

بالنسبة لحالات الاستخدام الخاصة بي ، أشعر أن النفقات العامة تستحق أن تكون قادرًا على التحديث وفقًا لجداولنا الخاصة ، بدلاً من الارتباط بـ AWS.

YMMV.

نحن ننتقل حاليًا من Oracle إلى Aurora Postgres ، حيث أدت إلى إبطاء تطورنا حيث لم نتمكن من الابتكار باستخدام أحدث التقنيات. نظرًا لأن برامج تشغيل Entity Framework لـ Oracle التي تستهدف .NET Core 3.X فقد تم إطلاقها للتو. ومع ذلك ، أدركنا أننا بحاجة إلى البقاء على LTS بسببهم. لكن دعم LTS لا يمكن أن يأتي بعد شهور. بالنظر إلى أنني أعتقد أن .NET 5.0 يعد أيضًا استثناءًا جيدًا لخطة LTS ، لأنه يمثل تحولًا هائلاً في الوظائف.

هل من أخبار عن هذا الآن بعد إطلاق .NET 5؟

اهتماماتي الرئيسية هي C # 9 وجميع تحديثات System.Text.Json .

ضع في اعتبارك أنه يمكنك استخدام إمكانية وقت التشغيل المخصص لاستخدام .NET 5 اليوم: https://aws.amazon.com/blogs/developer/net-core-3-0-on-lambda-with-aws-lambdas- وقت التشغيل المخصص /

لم أجربها بعد ، ولكن مع اقتطاع الكود ، وهو جديد في .NET 5 ، يجب أن تكون التجربة أفضل بكثير من .NET Core 3.0.

تتمثل سياسة فريق خدمة Lambda في دعم إصدارات LTS من أوقات التشغيل. نحن ، فريق AWS .NET ، نحاول العمل من خلال بدائلنا لمعرفة أفضل السبل التي يمكننا من خلالها دعم .NET 5 مع Lambda لأننا نعلم أن هناك الكثير من الإثارة لذلك.

بدافع الفضول من تشغيل .NET في منظور Lambda ، ما أكثر الأشخاص الذين يهتمون بـ .NET 5؟ هذا يساعدني على دفع الأولويات.

هل هذا يعني أن تشغيل تطبيقات lambda باستخدام .NET 5 لن يتم دعمه إلا بعد نقل .NET 5.0 من "الحالي" إلى "LTS"؟

NET 5.0 لن يكون LTS أبدًا. سيكون .NET 6.0 هو إصدار LTS التالي.

NET 5.0 لن يكون LTS أبدًا. سيكون .NET 6.0 هو إصدار LTS التالي.

ماذا يعني هذا بالضبط فيما يتعلق بأمهات لامدا ودعمها لاستخدام .NET 5.0؟

هذا يعني أننا لا يجب أن نتوقع دعم .NET 5 على Lambda لأنه لن يكون LTS.

هذا يعني أننا لا يجب أن نتوقع دعم .NET 5 على Lambda لأنه لن يكون LTS.

شكرا لك bjorg . إذا كان هذا هو الاستنتاج ، ألا ينبغي إغلاق هذا الموضوع باعتباره الجواب المباشر إذن؟

لقد طرحت هذا مع العلم أن .NET 5 ليس LTS وأن فريق AWS يدعم LTS فقط. كنت أتساءل عما إذا كان سيتم إجراء استثناء بسبب ضخامة الإصدار وحقيقة أن LTS التالي لن يكون حتى نهاية عام 2021. الشيء هو أننا لم نحصل على "نعم" أو "لا" صريحين حتى الآن لا أعتقد أننا يجب أن نغلق هذا بعد. لقد جاء إصدار .NET 5 وذهب (تمامًا كما حدث مع 3.1) وليس لدينا دعم Lambda ولكن هذا لا يعني أ) أنهم لا يعملون عليه أو ب) لا يخططون لذلك.

إذا قرر شباب AWS عدم دعم .NET 5 وقاموا بتوضيح هذا الأمر بالتأكيد ، فلنغلق هذه المشكلة. إذا كان الأمر كذلك ، فسنضطر فقط إلى الانتظار من 12 إلى 18 شهرًا أخرى للحصول على إصدار .NET المدعوم التالي.

أيضًا ، أفهم أن هناك مليون شيء آخر يجب العمل عليه وربما لا يكون هذا أمرًا بسيطًا. أنا فقط أحب الأشياء الجديدة اللامعة 😋

الحقيقة هي أنه بالنظر إلى السرعة التي قررت Microsoft تقديمها لـ .NET ، فليس من المنطقي انتظار إصدار LTS كل عامين. لأنه حتى الإصدار الحالي تنبعث منه رائحة مثل LTS عندما يكون ملزمًا بالبقاء لمدة 15 شهرًا (دعم لمدة عام + 3 أشهر).

سأكون على ما يرام إذا حددت AWS LTS وأوقات التشغيل الحالية حتى نتمكن نحن العملاء من تحديد المسار الذي نريد البقاء فيه.

بصراحة ، سأكون بخير مع وقت تشغيل مخصص مطبوخ مسبقًا لأوقات التشغيل على المسار الحالي.

بصراحة ، سأكون بخير مع وقت تشغيل مخصص مطبوخ مسبقًا لأوقات التشغيل على المسار الحالي.

أنت تقول ذلك ، ولكن قد لا يكون الآخرون متحمسين للحصول على إشعار من AWS في نوفمبر 2021 يخبرهم أن أمامهم 3 أشهر للتحديث من 5.x إلى 6.0 قبل أن تنسحب Lambdas الخاصة بهم من كل الدعم المقدم من AWS.

يمكن أن يتغير الكثير في غضون عام ، وفجأة قد لا يكون لدى الفريق النطاق الترددي للرد على الحاجة إلى تحديث Lambda التي ربما لم يتم التطرق إليها لعدة أشهر للحفاظ على الدعم الذي كان يتم إجراؤه في السابق نيابة عنهم من خلال تحديث Amazon المستضاف وقت التشغيل حسب الحاجة دون الحاجة إلى التفكير في الأمر.

بالتأكيد ، يمكن أن يكون هناك وقت تشغيل حالي مطبوخ مسبقًا مع الكثير من التحذيرات والتحذيرات ، ولكن هذا قد يأتي مع تعقيدات الدعم الخاصة به والفروق الدقيقة التي يحتاج المستخدمون إلى فهمها.

سيكون من الرائع لو دعمت Lambda جميع الإصدارات الرئيسية الجديدة من .NET اعتبارًا من اليوم الذي تم إصدارها بواسطة Microsoft ، لكني أتخيل أن الجوانب العملية للقيام بذلك على نطاقها هي السبب في أن الأمور على ما هي عليه الآن.

إذا كنت حقًا تريد حقًا أن تكون في طليعة البرامج وترقيها في أسرع وقت ممكن وتدعم الأشياء بنفسك وتفعل ما تريد وتقبل كل العواقب ، فهذا نوع من أوقات التشغيل المخصصة.

المشكلة هي أننا لسنا في الطليعة بشكل واضح. NET Core يتحرك بسرعة وكان مستقرًا بشكل ملحوظ. ابحث في NuGet الآن والحزم متوفرة مقابل 5.0.0. هم للاستهلاك العام الآن.

على الرغم من أنني لم أحاول ترقية مشروع DotNet Core 3.1 إلى DotNet 5 ، إلا أنني لم أواجه أي مشكلات رئيسية في الترقية فقط (على سبيل المثال من 2.1 إلى 3.1).

قد يكون DotNet 5 وحشًا مختلفًا ، لكن أوقات التشغيل المخصصة بالنسبة لي مخصصة للبيئات الأكثر غرابة مثل C ++ Lambda.

أفضل الحصول على التحديثات والانتقال إلى DotNet 5 Lambda عاجلاً وليس آجلاً. أثبت عام 2020 أن العام هو وقت طويل جدًا :-)

أرى من أين أتيت منmartincostello.

ولكن هذا هو نوع الاختيار الذي يجب أن يكون للعملاء: الذهاب الحالي أو LTS.

لا تصدر AWS أوقات التشغيل في Current لأن العميل الذي اختارها قد يجد نفسه في مشكلة لأنه يمثل تشويهًا للمسؤولية التي تتحملها AWS تجاه عملائها. يجب عليهم توفير الأدوات والسماح للجميع بتحديد الأداة الأنسب لهم.

إضافة إلى ما قاله genifycom ، عادةً ما تكون وظائف Lambda بسيطة جدًا ولا تعتمد التعليمات البرمجية في معظم الأوقات على ميزات محددة لإطار عمل ، مما يجعل من الصعب الانتقال من إصدار رئيسي إلى آخر (من الواضح أن هناك حالات شاذة) .

في شركتي ، لدينا عشرات الوظائف ، وفي معظم الأحيان نقوم بترقيتها باستخدام بحث / استبدال على مستوى المجلد (كان الأمر أكثر تعقيدًا بعض الشيء عندما اضطررنا إلى إزالة خاصية LambdaTools المحددة من ملف المشروع).

أود أيضًا أن أرى دعمًا متعددًا لـ dotnet 5 حتى يتوفر إصدار LTS. (حدث هذا في الماضي بنسخة أخرى)

الخيارات الوحيدة المتاحة في الوقت الحالي هي:

  • ابق مع dotnet core 3.1 وانتظر حتى dotnet 6 :(
  • استخدم وقت تشغيل مخصص (والذي سيكون في حد ذاته جيدًا ، ومع ذلك ، نظرًا لعدم وجود عدد كافٍ من AOT الأصلي في dotnet 5 ، فمن المحتمل أن تتأثر أوقات بدء التشغيل إلى الحد الذي سيؤدي إلى إيقاف المطورين عن الفكرة https://medium.com/ @ zaccharles / benchmarking-lambdas-new-custom-runtime-for-net-core-43ea79b5a35a)

يتبع زاك تصل هذا المنصب الأصلي مع مزيد من التفاصيل حول كيفية تحسين أداء بدء التشغيل لوقت مخصص: https://medium.com/@zaccharles/net -core-3-0-أوس-امدا بمؤشرات قياس وrecommendations- 8fee4dc131b0

آمل أن ينشر إصدار .NET 5 ، لأن هناك الكثير من تحسينات التجميع في .NET 5 التي لم تكن موجودة في .NET Core 3.1 ، مثل اقتطاع الكود ، والذي سيكون مفيدًا جدًا مع وقت التشغيل المخصص.

هل كانت هذه الصفحة مفيدة؟
5 / 5 - 1 التقييمات