Как стать автором
Поиск
Написать публикацию
Обновить

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

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

Всего голосов 1: ↑1 и ↓0+1
а какие сейчас у вас проблемы с удалением инстансов из шефа и мониторинга?
вроде бы, и до лямбды было достаточно возможностей.
разве что, в перспективе, можно будет немного сократить расходы на iaas.
Всего голосов 2: ↑2 и ↓0+2
Проблем никаких. Чем меньше сервисов нужно администрировать, тем лучше. Мониторинг и шеф — просто пример. На проекте есть множество задач, которые запускаются по расписанию или событию. Минус в том, что нужно поддерживать серверы, на которых эти задачи выполняются.
Всего голосов 1: ↑1 и ↓0+1
НЛО прилетело и опубликовало эту надпись здесь
Это всего лишь один из способов. Мне больше всего нравится делать чистку после получения сообщения в sqs.
Всего голосов 1: ↑1 и ↓0+1
в условиях большого динамически скейлящегося кластера у вас с такой реализацией будет приличный лаг типа «оно отвалилось, но мониторинг еще не убрал», а алерты уже все получили.
Всего голосов 1: ↑1 и ↓0+1
Не совсем так. Это зависит от мониторинга и реализации. Например, если мониторинг близкий к реальному времени, тогда да. Если же нет, то sqs-очередь проверять можно с большй частотой.

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


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

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

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

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

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

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

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

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

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

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

Ваш аккаунт

Разделы

Информация

Услуги

Техническая поддержка
© 2006–2024, Habr