Aws-lambda-dotnet: Поддержка .NET 5?

Созданный на 26 авг. 2020  ·  26Комментарии  ·  Источник: aws/aws-lambda-dotnet

Приносим извинения, если об этом спрашивали раньше, не стесняйтесь закрыть и укажите мне ответ, если так. Я посмотрел, но все равно не нашел ответа.

.NET 5 не отмечен как выпуск LTS: https://devblogs.microsoft.com/dotnet/introduction-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 .

Имейте в виду, что вы можете использовать возможность Custom Runtime для использования .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? Это помогает мне расставлять приоритеты.

Означает ли это, что запуск лямбда-приложений с .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, но это не означает, что A) они не работают над этим или B) они не планируют этого.

Если ребята из AWS решили не поддерживать .NET 5 и ясно дали понять это, давайте закроем эту проблему. Если это так, то нам просто нужно подождать еще 12-18 месяцев до следующей поддерживаемой версии .NET.

Кроме того, я понимаю, что есть еще миллион вещей, над которыми нужно поработать, и это, вероятно, нетривиально. Мне просто нравятся блестящие новинки 😋

Правда в том, что, учитывая темп, который Microsoft решила придать .NET, не имеет смысла ждать выпуска LTS каждые два года. Потому что даже текущий выпуск пахнет LTS, когда он должен оставаться в течение 15 месяцев (1 год + 3 месяца поддержки).

Было бы хорошо, если бы AWS определила LTS и текущее время выполнения, чтобы мы, клиенты, могли решить, по какому пути мы хотим остаться.

Честно говоря, меня бы устроила заранее подготовленная пользовательская среда выполнения для сред выполнения по текущему пути.

Честно говоря, меня бы устроила заранее подготовленная пользовательская среда выполнения для сред выполнения по текущему пути.

Вы так говорите, но другие могут не проявить такого энтузиазма, чтобы получить уведомление от AWS в ноябре 2021 года, в котором говорится, что у них есть 3 месяца на обновление с 5.x до 6.0, прежде чем их Lambdas прекратят поддержку со стороны AWS.

За год многое может измениться, и внезапно у команды может не хватить пропускной способности, чтобы отреагировать на необходимость обновления лямбды, которую, возможно, не трогали в течение нескольких месяцев, чтобы поддерживать поддержку, которая ранее выполнялась от их имени 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 , лямбда-функции обычно очень просты, и в большинстве случаев их код не полагается на особенности, специфичные для фреймворка, поэтому переход от одной основной версии к другой затруднен (очевидно, есть аномалии) .

В моей компании есть десятки функций, и большую часть времени мы обновляем их с помощью функции поиска / замены для всей папки (это было немного сложнее, когда нам приходилось удалять конкретное свойство 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-aws-lambda-benchmarks-and-рекомендации- 8fee4dc131b0

Я надеюсь, что он опубликует версию .NET 5, потому что в .NET 5 есть много улучшений компиляции, которых не было в .NET Core 3.1, например обрезка кода, которая была бы очень полезна с настраиваемой средой выполнения.

Была ли эта страница полезной?
5 / 5 - 1 рейтинги