@mykolaim
PHP developer

В чем суть serverless подхода?

В общем недавно Lambda выкатила поддержку PHP, что довольно радостно.
Но у меня возникли некоторые вопросы по архитектуре проектов с ее использованием.

В контенксте Lambda+PHP я вижу следующие варианты использования:
1. Реализация микросервисной архитектуры ( где каждый микросервис выступает функцией)
2. Реализация монолитной архитектуры ( например закинуть монолитный Laravel как одну функцию )

На сколько этот подход оптимальный/верный/логичный в контексте serverless и AWS Lambda в часности ?
  • Вопрос задан
  • 387 просмотров
Решения вопроса 1
neuotq
@neuotq
full stack php, стартапы, прокрастинация
Начну с того, что если вы таки активный разработчик и не очень можете понять этот принцип, возможно он вам просто не нужен. И это не значит что вы плохой разработчик, просто не пересекались с таким видом проблем.
Что касается serverless, название больше отражает не факт отсутствия сервера и работы с ним как таковым, а скорее еще меньше возни с настройкой и поддержкой серверного окружения (даже меньше чем с докером после того как все настроено и поднято). Те это следующие шаг после условных микросервисов.
Его часто удобнее называть функция как услуга, так как де факто часто реализуется запуск именно функции по запросу.
Если кратко описать для чего это нужно, то представим себе что у нас есть микросервис у которого затраты на содержания его постоянного аптайма как то слишком велики относительно времени работы/потребления ресурсов в живую. Да и в целом сервис выходит как то слишком микро даже для микросервиса.
Вот тут мы и придумываем такую штуку, которая будет ОЧЕНЬ быстро(относительно старта минимальной виртуалки/образа и чего другого) запускаться, быстро делает свою маленькую работу и выключается.
Из ключевых особенностей отмечу что функции должно быть в целом пофиг на своего состояние, она не знает изначально о предыдущем запуске и тп(те быть stateless). Все что нужно приходит в запросе.
Ври значит если у вас есть задача, которая удовлетворяет этим условиям, можно использовать этот удобный сервис и для масштабируемости, и для экономии и для кучи других фич.
Примеры:
ресайз изображений.
Генератор статистических сайтов(через админку производим обновление статистических файлов, это бывает не часто).
Чат боты
Разные спец информеры с определенной логикой.
И тд и тп, что хорошо ложится в определенную относительно простую функцию с простым входом данных(или без) и простым результатом работы.
В целом это решение не панацея, более того нужно четко понимать насколько выгодно/невыгодно переделывать на серверлесс платформы свою функцию, ведь мы точно жертвуем той же производительностью(помним что сервис не висит и не ждет нас постоянно, а пусть и очень быстро, но запускается), понижается прозрачность исполнения и усложняется отладка и прочее.
Но в любом случае, достаточно часто плюсы перебивают минусы, популярность у этого принципа есть. люди активно пользуются, так что много шишок уже набито, в целом зрелая штука.
А и да, насчет конкретного вашего вопроса.
PHP AWS Lambda нативно не поддерживает, все через костыли, впрочем с почти вменяемой производительностью.
И так как все таки AWS Lambda все же ближе к самому популярному нынче принципу serverless - функция как сервис, я не уверен что это правильная идея будет запускать атм Ларавел.
Те мы имеем минусы: отсутствие нативной поддержки PHP и такие заточенность под что-то простое, в итоге .. ну не знаю.
Я думаю плюшки serverless в виде нет мороки с настройкой сервера/облака можно решить многими другими сервисами. Впрочем может быть это будет не так выгодно в вашем случае, нужно исходить и рассчитывать по вашему сценарию работы вашего приложения. А потом решать, что лучше подходит.
Ответ написан
Пригласить эксперта
Ответы на вопрос 2
@avkvl
Serverless - это очень урезанный docker контейнер со своим API и временем жизни до 5 минут. При этом 1 контейнер обслуживает 1 запрос. В течении 5 минут после исполнения контейнер остается "горячим", т.е. содержит все данные после прошлого исполнения. Соответственно, если у вас память течет, то под нагрузкой память освобождаться не будет, т.к. контейнеры переиспользуются.

Кроме того, если вы хотите обслуживать внешние запросы, то нужно еще использовать прокладку в виде api gateway (за это тоже нужно платить).

Мороки с настройками тоже свои есть. Мониторить лямбды тоже задача со своими нюансами. Если у вас просто сайт/api и более-менее регулярная загрузка есть, то я бы serverless не советовал. Elastic beanstalk на самом деле удобнее и практичнее. А вот для задач вроде selenium тестирования, когда нужно 1000 тестов параллельно запустить и потом до следующего билда вам мощности не нужны - serverless это очень хорошо.
Ответ написан
@ivorobioff
Software Engineer
Да тут разницы нет никакой будь то python, c#, java или php. Если ты знаешь для чего использовать lambda с java или python кодом, для того же можно использовать и php код. Все дело в эффективности реализаций программных решений.

Скажем у тебя команда работает над php проектом и тут появилась необходимость заюзать lambda, но оказывается (еще тогда) там не поддерживается php. Возможно не создало бы проблем пилить код для lambda на другом языке, но как же быть с кучу общих либ в проекте который можно было бы заюзать в lambda. Не переписывать их же на python или go. Остаются только микросервисы. Но и с ними забот хватает, что даже и lambda становится из-за этого менее выгодный вариант. Но так как появилась поддержка php теперь данная проблема может легко решиться.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы
Banzai.Games Москва
от 100 000 до 150 000 руб.
Serenity Санкт-Петербург
от 50 000 до 120 000 руб.
21 марта 2019, в 00:19
5000 руб./за проект
20 марта 2019, в 20:02
1000 руб./за проект