Комментарии 19
Безсерверным решение было если бы картинки обрабатывались на клиенте. А так все на сервере, только в облаке.
Статья годная, но название и акценты на «безсерверность» всё впечатление портят.
Как иронично, что статью, фактически основанную на использовании ресурсов амазон вы как раз успели перевести к моменту, когда его нормальное употребление в РФ стало невозможным.
* отладкой
* тестированием
* контролем версий
* dev/stage/production окружением
- oтладка/тестирование. Код лямбды — обычная функция. Чтобы протестировать, импортируем ее, вызываем с желаемыми параметрами и проверяем результат в коллбэке. Абсолютно так же, как вы бы тестировали ее, если бы это была часть традиционного приложения. Есть библиотеки, которые берут на себя часть бойлерплейта. Например, тут: https://www.npmjs.com/package/lambda-local#use-lambda-local-to-mock
- контролем версий — Лямбда — это код. Нет никаких проблем хранить его в СКВ.
- dev/stage/production окружение. Мы делали отдельную функцию для каждого окружения. Допустим
process-image-prod,process-image-dev.
А зачем разворачивать вручную? Все автоматизируется.
Можно банально написать свой скрипт, который деплоит через aws api. Можно воспользоваться готовыми утилитами наподобие https://github.com/motdotla/node-lambda.
Ну то есть опять же — ничем принципиально не отличается от деплоя на EC2 или ECS.
По поводу отладки — нетривиальные функции часто работают с БД, S3 и прочим. Можно ли такие вещи отлаживать локально или надо обязательно размещать функцию в облаке?
кликать нужно три раза, для каждого окружения
Создание лямбд (как и любых других инфраструктурных ресурсов) можно (и нужно) описать в виде кода. Например, с Terraform.
Допустим, у вас код деплоится не в лямбду, а в EC2, ECS, CodeDeploy, etc — как вы убедитесь, что различные окружения (дев, прод) настроены одинаково? Вот точно так же это делается и с лямбдой.
Можно ли такие вещи отлаживать локально или надо обязательно размещать функцию в облаке
А как вы это делаете без лямбды, с обычным приложением? Точно так же поднимаете локальную базу, прописываете ее в конфиге для вашего локального окружения. Не вижу никакой разницы с лямбдой. Задача сводится к тому, чтобы подсунуть ей правильный конфиг.
- oтладка/тестирование. Код лямбды — обычная функция. Чтобы протестировать, импортируем ее, вызываем с желаемыми параметрами и проверяем результат в коллбэке. Абсолютно так же, как вы бы тестировали ее, если бы это была часть традиционного приложения. Есть библиотеки, которые берут на себя часть бойлерплейта. Например, тут: https://www.npmjs.com/package/lambda-local#use-lambda-local-to-mock
- контролем версий — Лямбда — это код. Нет никаких проблем хранить его в СКВ.
- dev/stage/production окружение. Мы делали отдельную функцию для каждого окружения. Допустим
process-image-prod,process-image-dev.
В функции вы пишете log.error и на этом всё. Дальше это как-то мониторится/где-то видно. Есть механизм повтора преобразования (с или без исправления кода функции)?
По стоимости достаточно сложно подсчитать, но на сколько в процентах (?) вырос счёт на эту часть после введения лямбды? Я смотрел в сторону managed MySQL в AWS, и он где-то на 40 процентов дороже, чем просто такая же EC2. Наверняка что-то подобное и с лямбдами. Да, оплата идёт только за использование, но она дороже, чем для обычных виртуалок. При заметном объеме и учете того, что все равно управляете другими EC2, возможно, будет заметно дешевле поднять ASG с соответствующими обработчиками SNS.
Уж было подумал, что перевод статьи того же Девида Хейнемейер Ханссона, но нет.
В оригинале «Being a Ruby on Rails developer...» я бы предложил более корректно перевести как «Будучи разработчиком на фреймворке Ruby on Rails...» или «Будучи Ruby on Rails разработчиком...»
Как повысить производительность, используя бессерверную архитектуру