Найти тему

Безсерверность v2019

Разбираемся, почему на октябрьской нью-йоркской конференции ServerlessConf 2019 ( https://nyc2019.serverlessconf.io/ ) захейтили сторонников контейнеров, и что из этого следует. Безсерверность, напоминаю, это довольно новая парадигма: https://vk.com/wall-152484379_227

Выступления в массе своей были скорее восторженные, нежели технические — типа, посмотрите, как круто у нас получилось. Действительно, многие проекты впечатляют. Аналогию тут такую можно провести (реальный стартап был) — корпоративные проекты начала 2000-х годов с тяжёлой инфраструктурой в середине этого десятилетия получалось быстро перетаскивать на шустрые SSD-диски и LiteSQL ))) В результате новая версия начинала работать в десятки раз быстрее, и в сотни раз дешевле. Сейчас serverless — тоже в некотором смысле упрощение, ну и удешевление хостинга в сто раз совершенно реально.

Общие позитивные мнения:
— всё работает очень прозрачно, понятно, за что платится каждый цент. Поэтому можно здорово оптимизировать не только технические аспекты, но и workflows;
— внутри безсерверных микросервисов хорошо удаётся разделять стеки для
stateful- и stateless- вычислений;
- serverless-вычисления отлично адаптируются под гетерогенные аппаратные платформы (GPU, TPU, ..);
— важную роль в оптимизации исполнения облачных функций будет играть машинное обучение.

Конкретные проекты:
— Gemological Institute of America, разработчик стандартов оценки качества бриллиантов, своё критически важное приложение полностью перенёс в безсерверное облако. А это основной источник их дохода! Детальные фотки камешков грузятся в микросервис, и клиенты получают отчёты, свёрстанные на GraphQL API и пушащиется через AppSync. Внутри в DynamoDB хранится 40 миллионов записей (56 терабайтов), время отклика три десятых секунды, аптайм 100% и ноль системных администраторов.

serverlessguru.com рассказал про свой безсерверный проект, в котором 70 тысяч строк кода эквивалентны миллионам строк классического проекта (экономия в скорости разработки в сто раз). Ежемесячно 240 миллионов вызовов Lambda-функций + 180 миллионов обращений к API Gateway + трафик 90 Тб через CloudFront. И обходится это всё чудо всего в две тысячи долларов!

— Accenture предложила энергетикам, чей легаси-сайт постоянно затыкался даже при средней нагрузке, безсерверный вариант с нормальной производительностью, и при этом в 100 раз дешевле. Новая система никогда не падает, и оповещения о перебоях с электричеством доставляются 10,000 пользователей мгновенно.

— CTO сайтов Company.com, и Forbes.com рассказал, что раньше хостинг на обычной виртуалке в ЦОДе обходился им ежемесячно в $12,000, а новая безсерверная версия кушает всего $1400.

— В целом на конференции явно прослеживалась выраженная категоричность. Например, Alex DeBrie (Serverless, Inc) заявил, что DynamoDB гораздо лучше подходит для безсерверных вычислений, нежели любая(!) реляционная СУБД — как в техническом плане, так и в плане ценовой политики. Отличный гайд, как начать использовать DynamoDB в безсерверном режиме: https://www.dynamodbguide.com/

— Nicki Klein (AWS) также утверждал, что безсерверность применима к абсолютно любому проекту. Он продемонстрировал Serverless Transcoder — параллельный MapReduce, выполнивший перекодировку часового видео за 11 секунд.

— Donna Malayeri (Google Cloud Platform) пыталась примирить безсерверных энтузиастов с классическими облачными подходами и модными контейнерами: да, всегда можно уйти в лямбда-функции, но многим нужны обычные виртуалки, потому что в компании обычно хорошо отработаны соответствующие технологии, и лучше говорить про гибридные проекты.

Ей довольно жёстко ответил Ben Kehoe из iRobot, в стиле тони роббинса раскритиковавший коллегу за кощунственное на такой конференции слово "контейнер" ))) "Если вы не хотите кодировать по-другому, используйте контейнеры блаблабла... Нет, я скажу так: "если вы ещё не можете кодировать по-другому, используйте контейнеры...". Я не думаю, что мы должны поощрять людей думать, что это нормально — не развиваться, даже если это пока происходит медленно из-за технических и организационных ограничений".

Он же предложил такое определение serverless — это инфраструктура-как-код. Это не только function-as-a-service, это и бесшовная связь всех подсистем; контейнеры же, очевидно, имеют выраженные границы, преодоление которых подразумевает определённые сложности. Основной месседж в отношении контейнеров был примерно такой: "Kubernetes — это перебор, это ненужное повышение статуса наименее интересной части вашей системы. Инфраструктура должна быть равномерно скучной".

Пока же главной технической проблемой, связанной и с безопасностью, в безсерверности — это конфигурационные конфликты. Ben Kehoe призвал относиться к конфигурационному языку YAML как к полноценному языку программирования и развивать его поддержку. Однако Tim Wagner, один из архитекторов AWS Lambda, призвал идти дальше. Он поддержал стартап www.stackery.io "Write Functions, Not YAML":
Select and configure services. Debug any AWS Lambda locally against your cloudstack. Manage your apps from architecture to production.
и пояснил, что ждёт безсерверность дальше: мы приложили все усилия, чтобы справиться с обработкой событий. У нас неплохо получаются мобильные и веб-бэкенды. Следующим этапом в развитии serverless станет параллельная обработка состояний и прямые (родитель-доча или пиринговые) взаимодействия между lambda-функциями. Уже начинают воплощаться в безсерверной реализации технологии бигдаты, машинное обучение, вычислительные библиотеки уровня NumPy, в чём в частности хорошо поможет
http://pywren.io/ — всем питонистам срочно изучать :)

Резюме такое, что категоричность тут всё же излишняя, но во-первых действительно не стоит смешивать в одном проекте микросервисы в контейнерах и микросервисы на базе FaaS. Во-вторых, если проект серьёзный, а раньше была практика только в монолитах, сразу бросаться в омут безсерверности не стоит. Если есть деньги, то лучше отдать на аутсорс тем, у кого такая практика уже есть (как сделал GIA), а если нету, то лучше сперва пройти путь с микросервисами через контейнеры. Потому что в serverless тоже есть свои подводные камни, которые при отсутствии опыта просто откопать негде: например, от знакомых ребят инфа, что в serverless-проектах 90% расходов может уйти на API Gateway, поэтому эту специфическую архитектуру тоже надо продумывать тщательно.

Tim Wagner
Tim Wagner

В-третьих, если посмотреть на фотку с конференции, где Tim Wagner выступает, там видно, что он говорит про некий "top of udt" (udt был 20 лет назад придуман), но ведь сейчас есть свежайший QUIC (самое крутое в нём, на мой взгляд — это streams as first-class citizens at the transport layer), когда все потоки гонятся через одно соединение, но при этом они друг от друга независимы. Тут же в тему отмечу, что уже Chrome, Mozilla, curl и Cloudflare выкатили хоть и экспериментальную, но вполне рабочую поддержку HTTP/3.
Ну и зачётный биндинг сетевой безсерверности — на питончике и плюсах)))