Данная статья расскажет о попытке подружить AWS Lamba и python в истинном смысле этого слова. Под истинным смыслом я понимаю возможность взаимодействовать c сервисом (создавать, обновлять и вызывать лябда-функции) непосредственно из пайтона. Если вам интересны AWS Lambda и python, представляю вашему вниманию proof-of-concept библиотеки lambdify.
В последнее время большой популярностью пользуется такой сервис как AWS Lambda. О том, что это такое и с чем его едят, уже писалось, например тут. В связи с этим, появилось много инструментов для работы с Lambda, в том числе, написанных на пайтоне, например Zappa, python-lambda и т.п. Но все их объединяет отсутствие возможности создавать лямбда-фунции динамически. Пользователю так или иначе приходится косвенно манипулировать файлами, содержащими код лямда-обработчиков, что мешает использовать их програмно.
В свою очередь, lambdify обходит это ограничение, позволяя, написав несколько строк кода, получить рабочую лямбда функцию.
Теперь Вы можете создать свою лямбда-функцию в 5 строчек кода:
Теперь, если зайти в AWS консоль, вы сможете увидеть новенькую echo лямбда-функцию. Одной из особенностей есть то, что сигнатура оригинальной функции автоматически приводится к сигнатуре, определенной в документации http://docs.aws.amazon.com/lambda/latest/dg/python-programming-model-handler-types.html.
Если вышеприведенный пример не показался слишком убедительным, то вот вам снипет для размышления:
… да-да, это лямбда, которая создает новые лямбды…
… и все это происходит в облаке. Правда, для этого нужно будет поиграться с ролями и политиками амазона, но это уже не входит в скоуп данной статьи.
А теперь вернемся в реальный мир. Пользователи, которые сталкивались с использованием очередей задач (далее ОЗ), таких как Celery или RQ, возможно, заметят некую аналогию с их интерфейсами. И будут правы: одной из целей lambdify является попытка соединить в себе удобство использования ОЗ для масштабирования системы, с теми преимуществами, которые предоставляет AWS Lambda, в частности, отсутствие необходимости администрировать воркеров и обеспечивать масштабирование (в отличие от традиционных ОЗ). Возможно, в будущем, данная тулза поможет кому-то мигрировать с использования ОЗ на AWS Lambda.
Конечно, стоит, заметить, что библиотека в альфа-версии: в планах куча импрувментов, новых фич, багфиксов и прочего. Целью же данной статьи было поделиться с читателями новым взглядом на Lambda с точки зрения мета-программирования и интроспекции пайтона. Надеюсь на то, что это послужит толчком для развития данного проекта.
Ссылки:
Дисклеймер
Данная библиотека является work-in-progress а также proof-of-concept, поэтому любой фидбек очень приветсвуется.
В последнее время большой популярностью пользуется такой сервис как AWS Lambda. О том, что это такое и с чем его едят, уже писалось, например тут. В связи с этим, появилось много инструментов для работы с Lambda, в том числе, написанных на пайтоне, например Zappa, python-lambda и т.п. Но все их объединяет отсутствие возможности создавать лямбда-фунции динамически. Пользователю так или иначе приходится косвенно манипулировать файлами, содержащими код лямда-обработчиков, что мешает использовать их програмно.
В свою очередь, lambdify обходит это ограничение, позволяя, написав несколько строк кода, получить рабочую лямбда функцию.
Установка
pip install awscli
aws configure
pip install lambdify
Теперь Вы можете создать свою лямбда-функцию в 5 строчек кода:
from lambdify import Lambda
@Lambda.f(name='echo')
def echo(*args, **kwargs):
return args, kwargs
# здесь, мы должны создать фунцию явно, хотя библиотека позволяет
# синхронизировать код функции с ее облачным инстансом автоматически
echo.create()
if __name__ == '__main__':
import getpass
echo(msg='Hello, {user}!'.format(user=getpass.getuser()))
Теперь, если зайти в AWS консоль, вы сможете увидеть новенькую echo лямбда-функцию. Одной из особенностей есть то, что сигнатура оригинальной функции автоматически приводится к сигнатуре, определенной в документации http://docs.aws.amazon.com/lambda/latest/dg/python-programming-model-handler-types.html.
Если вышеприведенный пример не показался слишком убедительным, то вот вам снипет для размышления:
@Lambda.f(name='meta')
def meta(name=None):
@Lambda.f(name=name or 'foo')
def foo(*args):
return 42
return foo.get()
… да-да, это лямбда, которая создает новые лямбды…
… и все это происходит в облаке. Правда, для этого нужно будет поиграться с ролями и политиками амазона, но это уже не входит в скоуп данной статьи.
А теперь вернемся в реальный мир. Пользователи, которые сталкивались с использованием очередей задач (далее ОЗ), таких как Celery или RQ, возможно, заметят некую аналогию с их интерфейсами. И будут правы: одной из целей lambdify является попытка соединить в себе удобство использования ОЗ для масштабирования системы, с теми преимуществами, которые предоставляет AWS Lambda, в частности, отсутствие необходимости администрировать воркеров и обеспечивать масштабирование (в отличие от традиционных ОЗ). Возможно, в будущем, данная тулза поможет кому-то мигрировать с использования ОЗ на AWS Lambda.
Конечно, стоит, заметить, что библиотека в альфа-версии: в планах куча импрувментов, новых фич, багфиксов и прочего. Целью же данной статьи было поделиться с читателями новым взглядом на Lambda с точки зрения мета-программирования и интроспекции пайтона. Надеюсь на то, что это послужит толчком для развития данного проекта.
Ссылки:
Комментарии (5)
random1st
08.04.2016 23:14Да, и практически самое важное забыл — а как же таймаут и «размер памяти»? С какими лямбда деплоится?
random1st
Как у Вас в пакете решена проблема бинарных расширений? У лямбд есть ограничение — не более 100 одновременно запущенных лямбд на аккаунт, Вы как-нибудь учитываете эту проблему? На лямбде не работает мультипроцессинг и файловая системв доступна только в размере 500 Мб в каталоге tmp, что произойдет при использовании Вашего декоратора на мультпроцессингой функции и функции, работающей с файловой системой. Лямбда позволяет вызывать себя асинхронно и синхронно, что предлагаете Вы? Короче, задумка интересная, но я думаю, что пилить смысла нет, слишком много тонкостей, в том числе и с настройкой event source, политик и ролей.
LeonExt
По-моему, все выше перечисленное также относится и к традиционным подходам в виде загрузки файла, содержащего функцию-обработчик. Ну а по поводу конфигурации и типов вызова, я уже писал, что это work-in-progress. А за фидбек спасибо
random1st
Я просто пытаюсь объяснить, что Ваш подход неверен. По итогу Вы напишете тот же питоновский SDK, но поддерживать Вам его придется самому. А еще Amazon постоянно пилит новые фичи, и поддерживать Вашу библиотеку с таким уровнем абстракции станет нереально сложно. Я Вам сходу могу набросать еще с десяток причин, почему такой подход нельзя использовать, но поверьте мне на слово, Вы просто плохо знаете этот сервис. Я могу сделать такой вывод хотя бы потому, что в коде у Вас просто скопирована из SDK функция создания лямбды с параметрами, приведенными для примера (Timeout=123, MemorySize=128).
Stas_K
LeonExt, вы все делаете правильно, не верьте на слово random1st. Все, что можно автоматизировать, нужно автоматизировать. Или переводить в удобное API для этого. Вы его и создали)