Как стать автором
Обновить

Комментарии 18

Использую Лямбду AWS как дополнение к хранилищу S3 там, где EC2 избыточен.
В моем случае, например — для обработки загружаемых в S3 изображений, и создания нескольких изображений разных разрешений в соседнем S3 Bucket, которые потом подхватываются CDN'кой CloudFront.
Для таких небольших операций — Лямбда шикарна, тем более, что с прошлого года появилась поддержка GoLang.
Да, спасибо, я действительно не добавил примеры. Так что, кто юзает лямбду активно, можете предлагать свои варианты
Lambda обычно используется как бэкенд для Lex чатботов, Alexa Skills, AWS IoT
docs.aws.amazon.com/greengrass/latest/developerguide/config-lambda.html
и может запускаться локально на Greengras Core:
docs.aws.amazon.com/greengrass/latest/developerguide/lambda-functions.html
НЛО прилетело и опубликовало эту надпись здесь

Лямбду можно использовать как кастомный ресурс в cloudformation, тогда она сможет обрабатывать и менять параметры других создаваемых, обновляемых и удаляемых ресурсов в этом стеке (например, это нужно в связи с кривым API Cloudformation для Cognito Identity Pool).
Кроме этого лямбду можно использовать для автоматизации различных операций в облаке через boto3 на питоне. Boto3 уже находится в поставке питона (хотя и не последней версии, возможно потребуется создать свой слой с последней версией boto3).
Также можно слушать различные события и как-то на них реагировать (отправить сообщение в месседжер, что завершилась сборка в CodeBuild).

НЛО прилетело и опубликовало эту надпись здесь
Стоит отметить, что если вам нужен постоянно запущенный демон, то лямбда не подойдёт, ибо имеет таймаут.
Обычно демон/сервис просыпается и отрабатывает задачи по таймеру.
У лямбды тоже есть возможность сконфигурировать периодический вызов по таймеру.

Другое дело — работа в локальной сети.
Некоторые организации достаточно закрыты и использование Cloud services противоречит корпоративной политике. В этом случае демон/сервис.
Демон может быть запущен и например держать постоянные соединения с другими демонами/клиентами, ну там может вебсокеты какие.

Можно рекурсивно вызывать лямбду из лямбды, но перед тем, как так делать, стоит подумать — а надо ли оно.

Это все класно, но есть вещи о которых документация Amazon молчит.
Например.

Lambda функция настроенная на SQS ухитряется сделать МИЛЛИОН запросов на очередь вообще без нагрузки, за месяц

Встроенный редактор практически не работает в Firefox.

Функция может набросать в Cloudwatch логов на терабайт. Вы, естественно, об этом узнаете в конце месяца(ну и заодно узнаете о возможности warnings на использование от суппорта).

Чтоб настроить простейшую функцию надо минут 30 потратить, даже знаючи(всякие roles/permissions и так далее).
30 минут надо потратить первый раз. Второй и дальше — по минуте. Как и с любой новой технологией.

Террабайт логов и миллион запросов на очередь в месяц — так бывает, если выкатить что-то в продакшн и не обращать внимания на него месяц. Лямбда тут не лучше и не хуже любой другой технологии.

Встроенный редактор — задавная поделка для быстрого тестирования. Код лямбд (как и любой другой код) пишется в IDE, тестируется тестами, хранится в системе контроля версий и т.д.
Миллион запросов в очередь в месяц это был тестовый код от амазон в топике Lambda with SQS. Да, его оставили на месяц. Но блин, очередь то пустая была.
Не знаю, может вам кажется, что пара минут. У меня только каждая форма в консоле 20-30 секунд грузится. Я вот как раз засек прошлый раз, ровно 30 минут настройка.
У меня редактор работает в ФФ, но когда открываешь страничку, дефолный код не открывается, виснет на бесконечной загрузке. Но если закрыть файл и снова открыть его — всё нормально отображается.
Да, у всех так. Я ж и пишу «практически не работает». То работает то нет.
Честно говоря, это не то, что ожидаешь от продуктов компании уровня Amazon.
Оно очено стабильно и предсказуемо не работает :)
У AWS так вроде всё хорошо снаружи, но чуть копнёшь глубже и всплывают недоработки, которые не фиксятся годами или бардак в документации. С этим просто приходится мириться и находить обходные пути.

Можно ещё про медленный cold start вспомнить - делает всё малопригодным для синхронного выполнения, когда клиент ответа ожидает.

>> В следующей статье мы рассмотрим как эти два сервиса взаимодействуют друг с другом

Хорошие статьи, спасибо. Жаль, что не вышло продолжение.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории