Мне особенно интересно наблюдать за serverless (термин появился в 2012) движением и его развитием со стороны, с позиции скептика. В первую очередь меня беспокоила дороговизна и низкая прозводительность. Стоит также отметить и общий скепсис комьюнити на счет проектов, целиком построенных на serverless архитектуре. И сегодня я хочу поделиться двумя статьями по этой теме. Итак, насколько актуална для backend-разработчиков serverless архитектура?
Первая статья, в сегодняшнем обзоре - это публикация Бенджамина Пайла, одного из заментных лидеров AWS комьюнити в США, и одного из первых пользователей (early adopter), публикация под названием Does Serverless Still Matter?
Можно конечно сказать, что все началось с Google App Engine, который запустили в preview в начале 2008 года. Но широко понятие serverless архитектуры закрепилось после выхода AWS Lambda в 2014 году. AWS Lamda функция запускается по событию (HTTP запрос, планировщик, загрузка файла в S3 сторадж, обновление данных в DynamoDB и т.д.). Бесплатный план разрешает до 10е6 запросов. Но там не все так просто, нужно понимать как долго будет выполняться Lambda-функция, сколько она будет потреблять ресурсов.
Стоит различать два архитектурных решения: always on и event-driven. AWS Lamda и аналогичные облачные решения предлагали как раз событийную модель, при которой HTTP-запрос запускал Lambda-функцию.
Появление и некий рассвет serverless архитектуры совпал с популярностью микросервисной архитектуры и контейнеризации. В 2016 о serverless говорили почти из каждого утюга и это был самый настоящий хайп, т.е. тема была раздута комьюнити. И несмотря на задержку при холодном старте (старт фукнции, которая долгое время не вызывалась, занимал некоторое время на "разогрев"), находились энтузиасты, которые внедряли AWS Lambda в свои решения.
По мнению автора сейчас мы стали свидетелями заката serverless архитектуры, т.к. Amazon, Google и MicroSoft сместили фокус с serverless на AI инструменты.
Автор это сатьи занимался активно продвижением serverless архитектуры и это было модно, об этом говорили, создавали сообщества, а гагинты щедро инвестировали в эту нишу. Но как только фокус сместился в сторону AI, serverless перестал быть хайповой темой, то и тональность автора изменилась. По моему мнению как раз сейчас стоит обращать внимание на эти решения, когда нет хайпа. Именно сейчас будет яснее видны недостатки и преимущества решений на базе serverless. Плюс, благодаря ранним адоптерам, вроде автора этой статьи, сформировалась практика, которая позволит наступить на меньшее количество граблей.
Высокая цена ошибки. Вы можете написать скрипт с бесконечным циклом, который триггерит разные события и попасть на USD14000. И это еще небольшие проблемы, с которыми вы можете стокнуться.
Непредсказуемая инфраструктура. Движение serverless проходило под слоганом:
run code without worrying about infrastructure
На деле вы заменяли одни проблемы работы с инфраструктурой на другие, работой с незнакомой изменчивой закрытой средой. Т.е. время также уходило на то, чтобы заниматься настройкой, но теперь это CloudWatch, лимиты на время выполнения, мониторинг вашего баланса, отслеживание обновлений и т.д.
Инвестиции в изменчивые контракты. Понятно, что для бизнеса важна добавленная стоимость. Насколько высока ценность одного или другого решения и насколько это экономически эффективно? Мне хочется вкладываться в более проверенные надежные решения и предлагать их. И мне совсем не хочется тратить время на непровернные технологии. Изменчивый контракт AWS - это для меня ненадежный фундамент. Я предпочту инвестировать время в изучение оркестратора, чем в чтение документации о сервисах AWS.
Однако, serverless не ограничивается только AWS Lambda. В одном из следующих выпусков я подробно расскажу про немаленький банк в UK, который полностью работает в облаке Amazon. 1500 микросервисов, 9000 подов.
Amazon Prime Video - video-on-demand сервис, вроде Netflix'а. Команда отслеживания качества видео VQA (video quality analysis) изначально реализовала прототип своего серваса используя AWS Step Functions и AWS Lambda. Сервис автоматически обнаруживал и сообщал о проблемах с аудио-видео (битые блоки, синхронизация аудио/видео и т.д.).
Первое решение быстро уперлось в лимиты AWS Step Functions: анализу подвергается каждая секунда видео. Следущее узкое место - это передача файлов между Lambda-функциями. Одна лямбда разбивает видео на фреймы и сохраняет их на некоторое время в AWS S3, а другая лямбда скачивает эти фреймы из S3. С учетом высокой частоты таких запросов это тоже стоит дорого.
В итоге команда перешла к монолиту и равзернула его на AWS ECS (Elastic Container Service). Экономия на инфраструктуре при этом составила 90%.
Я бы сделал для себя следующий вывод, известный вам всем: лучше начинать с монолита. Переход к микросервисной архитектуре чаще сложнее и должен быть хорошо аргументирован.