Комментарии 32
Можно попроще, без амазона, докера и вот этого всего?
Мммм, вы хотите serverless без облачного провайдера?
А что такое тогда serverless, по-вашему?
Я боюсь, ваше понимание не совпадает с тем, которое использует сам облачный провайдер, когда продает свои решения как серверлесс.
И где же это "бессерверное" выполняется?
И я так и не понял, почему «serverless»
Спросил у гугла…
Serverless computing is a cloud-computing execution model in which the cloud provider acts as the server
…
Как это… когнитивный диссонанс.
И я так и не понял, почему «serverless»
Формальный ответ звучит так: потому что вы не менеджите ресурсы сервера, и даже не знаете, сколько их там. Вы запускаете вычислительную задачу, а где она выполняется, на одном устройстве, на сотне — вас не волнует.
И в этом контексте AWS Lambda — честный serverless.
serverless лямбда без амазона и докера называется хранимки (stored procedure), но это 'фу' и плохо
А почему она serverless, если она выполняется на сервере БД?
понятие serverless подразумевает выделенный appserver, не клиентскую обработку (совсем без сервера)
Немного из собственного опыта:
локальная разработка на яве? дебаг (только JS?) появился совсем недавно, хотя самой лямбде уже лет 5+
unit тестирование? хорошо если integration test, и как следствие:
проверка совместимости версий ваших лямбд между собой и схемой базы? - скорей всего будет проще сказать, что в вашем проекте, этого не потребуется и закрыть вопрос
ограничение по времени - если вы думаете делать что-то, что занимает время (пакетная обработка, длительные транзакции) сразу нет
усложненный доступ - надо дополнительно конфигурировать (gateway) api
каждый вызов поднимает свою JVM, и новый коннект к базе -- кеширование (в памяти) и пулы коннектов - уже не модно.
У меня C#/.net (и немного питона), но отличия от Java должны быть пренебрежимы.
unit тестирование?
Я прекрасно гоняю юнит-тесты против кода, который ложится в лямбду.
каждый вызов поднимает свою JVM,
Так не должно быть. Новый инстанс поднимается только если (а) старый опустился из-за неактивности и/или (б) пришел запрос, когда старый инстанс занят, а лимит на конкурентность еще не выбран. Иными словами, если у вас есть стабильный поток запросов, у вас поднимется нужно число инстансов для его обработки, а дальше они будут теплыми пока поток не кончится.
я честно рад за C#/.net, но в JVM было вот так.
Я прекрасно гоняю юнит-тесты против кода, который ложится в лямбду.
а если не в VS, a в CI/CD Azure pipelines, Github Actions или в jenkins?
по другим вопросам возражений нет?
а если не в VS, a в CI/CD Azure pipelines, Github Actions или в jenkins?
Без проблем. Они гоняются стандартным раннером dotnet test, ничем не отличаются от любых других юнит-тестов.
я честно рад за C#/.net, но в JVM было вот так.
Вы проверяли, что у вас лямбда не успела лечь по таймауту? Пока я не настроил грелку, у меня тоже так было.
по другим вопросам возражений нет?
Ну, у меня нет проблем с совместимостью версий, но это потому, что у меня хранилище выкатывается тем же деплоем, что и сама лямбда, поэтому оно заведомо консистентно. И необходимость api gateway я не считаю усложнением — он позволяет делать много полезных штук, а когда они не нужны, есть другие способы развертывания кода, кроме лямбды, и другие способы вызвать лямбду, кроме HTTP.
А с остальным согласен, да, есть такие ограничения. Больше всего дебаг бесит, но для него, в принципе, есть решения тоже.
Вы проверяли, что у вас лямбда не успела лечь по таймауту?
что значит лечь? лямбда, как stateless функция и состояния между вызовами не держит, это относится к пулам коннектов, и кешам - их просто не будет. Это не такой хитрый аппсервер, а просто интерфейс к скриптам.
Ну, у меня нет проблем с совместимостью версий, но это потому, что у меня хранилище выкатывается тем же деплоем, что и сама лямбда, поэтому оно заведомо консистентно.
основной особенностью лямбд заявляется независимый деплой (как в микросервисах), а если деплоить все консистентно, то чем это отличается от монолита? ну кроме возможности интеграции с S3 events и прочим vendor lock
что значит лечь?
Значит "инстанс опустили".
лямбда, как stateless функция состояния между вызовами не держит, это относится к пулам коннектов, и кешам — их просто не будет.
Ммм, вы уверены? У для .net состояние между вызовами сохраняется, пока инстанс горячий. И для питона то же самое. Мне кажется странным, что для JVM исключение сделали.
То есть я вот прямо в логах вижу: инит лямбды тогда-то, вот у меня залогалось всякое там во время инита, а вот несколько вызовов без логов инита, они в тот же инстанс упали. Потом она уснула, выгрузилась, пришел вызов — снова инит.
Это не такой хитрый аппсервер, а просто интерфейс к скриптам.
Да нет, AWS Lambda — это как раз хитрый аппсервер, со своим собственным состоянием.
основной особенностью лямбд заявляется независимый деплой (как в микросервисах), а если деплоить все консистентно, то чем это отличается от монолита?
Неа, основной особенностью лямбд является то, что про сервер думать не надо при провижнинге. А вот деплоить можно так, как хочется.
Иными словами, дихотомия "микросервисы/монолит" — это другая дихотомия нежели "серверлесс/сервер-бейсд". Можно писать микросервисы без лямбды, можно писать лямбды для не-микросервисных архитектур.
А можно, кстати, выделять небольшие куски консистентности, которые деплоятся целиком, и поэтому внутри себя консистентны, а наружу говорят по заранее определенному контракту, поэтому проблемы версионирования решаются так, как они решаются для внешних контрактов.
лямбда, как stateless функция и состояния между вызовами не держит, это относится к пулам коннектов, и кешам — их просто не будет.
Даже документация с вами не согласна:
You can add initialization code outside of your handler method to reuse resources across multiple invocations. When the runtime loads your handler, it runs static code and the class constructor. Resources that are created during initialization stay in memory between invocations, and can be reused by the handler thousands of times.
Описанное поведение консистентно с тем, которое я вижу для .net и python.
ограничение по времени - если вы думаете делать что-то, что занимает время (пакетная обработка, длительные транзакции) сразу нет
у вас длительность выходила за максимальное время жизни лямбды? пробовали Fargate для длительных операций?
Пожалуйста, не используйте картинки с прозрачным фоном. Я вижу их вот так:
В следующих главах я разверну БД и научу свою функцию взаимодействовать с базой данных. Создам реализации и для других функций.
Я давно смотрю на serverless, но руки не доходили попробовать. Да и стимула не было пробовать, поскольку с ними совершенно непонятно что делать с CI/CD.
CI/CD упомянут Вами в статье. Будет здорово, если об этом будет что-либо в продолжении.
Я пока вижу это так:
развёртываем боевую отдельно и тестовую лямбду отдельно
на тестовую (может быть и на боевую) натравливаем тестирующий её код. При этом могут вноситься изменения в БД, если лямбда над БД
соответственно кажется, что нормальный CI/CD можно построить только при наличии serverless в docker, иначе придётся писать солидную инфраструктуру над serverless провайдера (или он её уже написал?)
В общем если кто-то взялся освещать информацию о serverless, то было бы крайне интересно увидеть примеры/ответы на эти вопросы.
в следующих частях рассмотрю вопросы, связанные с организацией окружений (стандартные dev,qa,stg и feature-branch), это не совсем про CI/CD, но думаю часть вопросов это снимет.
C CI/CD как-раз нет проблем, т.к. инфраструктура описывается одним из доступных способов (sam, serverless framework, pulumi и тд) и поднимается / обновляется по сути одной командой. Поэтому вы с легкостью можете поднимать и поддерживать разные стейджинги, хоть по бранчам для каждого dev, хоть интеграционные
Сделайте перекрёстное оглавление во всех статьях цикла.
Разработчик в стране Serverless: первые шаги, первая лямбда (Часть 1)