Комментарии 13
Если говорить о самом фреймворке — то нет, он заточен конкретно под AWS. Если же рассматривать сам принцип — то это от части aPaaS платформа с гораздо более расширенным функционалом — и да у нее есть аналоги такие как Google App Engine, Azure WebJobs или OpenSource hook.io.
Технически многие крупные Enterprise уровня компании иметь собственные аналоги для внутреннего использования.
Тогда в недостатки запишите чудовищный вендор-лок.
Проект — заложник Амазона. Если что пойдет не так, например, вырастут цены, то вы ничего не сможете сделать. Только выкинуть и написать с 0 другой командой — т.е. даже полноценной передачи знаний не будет. Это очень серьезный риск.
Я б сказал, не чудовищный а частичный. Все же лямбда это функция — а значит обезопасив себя парой слоев абстракции по обработке и выводу данных, в принципе код можно перенести на любую платформу в качестве REST API. Но естественно такие моменты как ивенты, и прочие native Amazon лочат Вас в Амазоне =)
Технически это уже не shared hosting, т.к. Enterprise выкупает «свое» оборудование в DC
Новый виток эволюции обьектно ориентированного програмирования с динамической оптимизацией ресурсов…
Если настроить разграничение прав в DynamoDB, можно вообще обращаться к БД напрямую с минимумом серверной логики.
AWS Lambda с одной стороны интереснейшая и мощная вещь, но с другой, именно холодный старт расстраивает. Бывали случаи, когда функция вообще не выполнялась (функция уровня hello world), только из-за того, что она стала холодной и к ней не обращался в течении ~7 минут.
Да — холодный старт это проблема, но проявляется она только в 2х случаях =) А именно при очень малом потоке пользователей (когда ламбда «засыпает») и при очень большом (когда происходит scale-out)
Некоторые библиотеки (аналоги описанной) решают эту проблему при помощи периодической задачи каждые 4 минуты — работает, на стоимость решения особо не влияет.

В моём случае с lambda всплыла другая проблема, когда сервису надо было устанавливать пару постоянных соединений при запуске и при классическом подходе это задержек запросов не создавало, а тут стало. Но это тоже решилось определёнными оптимизациями.
Еще из неудобных вещей — управление зависимостями + нативные библиотеки.
Все зависимости приходится явно загружать и класть рядом с фунцкиями, для доступа используя что-то вроде
sys.path.append(os.path.normpath(os.path.join(os.getcwd(), 'lib')))
sys.path.append(os.path.normpath(os.path.join(os.getcwd(), 'dependencies')))


Было бы круто если Serverless сама умела это делать, вроде есть pull request на эту тему.
С нативными библиотеками проблема серьезнее: невозможно просто взять и положить зависимость с локальной машины, т.к. в амазоне будеть линь, а локально Mac/Win. Тут отвещается решение данной проблемы. У себя используем Docker для сборки lxml и копированием в зависимости.

Как вы у себя решаете данные проблемы?
Честно сказать — решение у нас простое, мы собираем пакет на AWS AMI машине перед инсталяцией =) Что в принципе решает проблему совместимости. Конечно самое хорошее решение было бы «застатвить» lambda автоматически подргужать указанные нативные библиотеки…
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.