Pull to refresh

Comments 23

Звучит не плохо.
Андрей, ждем пример готовой реализации :)
Уже есть пара идей где применить:
  • для автоматизации удаления ресурсов, ассоциированных с инстансами, например, из мониторинга, шефа (но есть проблема: инстансы не поддерживаются как источник событий, но думаю API спасет)
  • для запуска кучи задач по расписанию, но тут проблема с джавой пока

а какие сейчас у вас проблемы с удалением инстансов из шефа и мониторинга?
вроде бы, и до лямбды было достаточно возможностей.
разве что, в перспективе, можно будет немного сократить расходы на iaas.
Проблем никаких. Чем меньше сервисов нужно администрировать, тем лучше. Мониторинг и шеф — просто пример. На проекте есть множество задач, которые запускаются по расписанию или событию. Минус в том, что нужно поддерживать серверы, на которых эти задачи выполняются.
UFO just landed and posted this here
Это всего лишь один из способов. Мне больше всего нравится делать чистку после получения сообщения в sqs.
в условиях большого динамически скейлящегося кластера у вас с такой реализацией будет приличный лаг типа «оно отвалилось, но мониторинг еще не убрал», а алерты уже все получили.
Не совсем так. Это зависит от мониторинга и реализации. Например, если мониторинг близкий к реальному времени, тогда да. Если же нет, то sqs-очередь проверять можно с большй частотой.

Например, я тут прикинул, если раз в секунду проверять очередь, то в месяц заплатим 1$ за SQS.
https://habrahabr.ru/post/309040/
Не совсем:
  • Модель тарифная у IronWorker не pay-as-you-go, а статическая цена в месяц с ограниченими по количеству воркеров и времени запуска
  • Нет интеграции с другими сервисам амазона. Т.е. формировать те самые ивенты нужно самому


Любобытно, что воркеры и очередь хостятся в AWS либо Rackspace.
А так, идея не нова, конечно же.
вообще pay-as-you-go тоже было (первоначально), но вы правы, для новых клиентов эти планы уже недоступны.
Воркеры хостятся и на амазоне и на ракспейсе и на азюре (очередь тоже)
азюре
— звучит мильенько так, в такой транскрипции. Извините не удержался.

Что касается IronWorker и IronMQ, то поддержка нескольких провайдеров — это преимущество, когда нужно избежать vendor lock.
Т.е. если мы делаем функцию, отдающую веб-страницу, и на основе этого строим CMS, то мы оплачиваем, грубо говоря, генерацию страниц (и работу в бек-энде, конечно).

Пусть сайт у нас посещают 5000 человек в сутки, это 30*5000 = 150000 запусков функции в месяц, плюс сколько-то еще страниц увидит (запросит) администратор сайта в админке. Знать бы скорость выполнения функции (она сильно зависит от окружения: видел как-то, как страница сайта генерилась секунд 30 из-за тупящей дисковой подсистемы), чтобы понять расходы, но на глазок эти пара баксов терпимы.

Но сайт — это не только страницы, это еще и статика, и ajax, который явно увеличивает число запросов (и вызовов функции).

В любом случае, идея неплохая!
Ну, кстати, может быть интересно использовать со «статичными» CMS. Каждый раз, когда что-то на сайте меняется, лямбда генерит новые html-ки и пихает их в кэш, из которого все и раздается. Вероятно, это будет выгодно для визиток, лэндингов, ряда SPA и прочих штук, не требующих сложной бэкенд-логики.
Да, точно.

Хочется все же понять, как быстро будет функция исполняться. Дорогого стоит, если страницы почти всегда будут не более 100 мс создаваться.
Обещают очень быстро. Из видио презентации: «в течение милисекунд ваша функция будет запущена»
Хм… Это лишь означает, что диспетчеризация события на экземпляр функции произойдет быстро, и что функция будет в состоянии «всегда готов».

Но вот сколь много мне выделят мощности CPU, и как долго я буду ждать ответы от других подсистем Амазона… Ну, вы поняли )
Нужно тестировать для конкретного приложения. Думаю, что всякие задачки по типу обработки картинок будут проходить быстро. Как хранилище данных можно использовать DynamoDB — скорость записи должна быть ок.
Хотя формально поддерживается только Node.js, но вместе с JS-файлами туда можно загружать произвольные ресурсы, в том числе и исполнимые файлы, написанные на других языках. И вызывать их потом из JS.

Вот тут пишут об успешном запуске Go-программы: blog.0x82.com/2014/11/24/aws-lambda-functions-in-go/

Go тут удобен тем, что он компилирует всё в один статический экзешник, поэтому неважно, в каком окружении его запустит Лямбда.
Круто! А сторонние библиотеки Go тоже компилирует в исполняемый артифакт?
Совсем сторонние, не на Go написанные — в общем случае нет, у них могут быть свои динамические зависимости. Тут надо отдельно на каждую либу внимательно смотреть.

И сама go-программа тоже не абсолютно автономна, для некоторых функций она обращается к системным библиотекам. Самая заметная такая функция — резолвинг DNS (см. коммент к тому посту blog.0x82.com/2014/11/24/aws-lambda-functions-in-go/#comment-1719377745). Но в данном случае это не мешает, т. к. системные либы в лямбда-окружении доступны.
Время астрономическое или машинное? Если машинное, как ввод/вывод считается?
А если функция создаст фоновый процесс, а сама завершится — как это будет считаться?
Sign up to leave a comment.