Комментарии 13
Присматриваюсь к серверлесс-архитектуре, и пока что-то не пойму как применить это в свей реальной жизни так, чтобы потом не пришлось всё срочно переделывать.
Адепты этого подхода из каждого утюга кричат, что "подходит для всего" и "можно реализовать что угодно", но это очевидно… мягко говоря… хм… неправда.
Начать с того, что серверлесс он ещё и неизбежно стэйтлесс. Если разрабатываемая штучка обязана быть стейтфул, то серверлесс сразу мимо.
У меня есть архиполезный для бизнеса сервис, который стартут пять минут, зажирает 2ГБ оперативы, но после этого выдаёт ответы с ураганной скоростью. Очевидно, что из-за этих самых 2ГБ и пяти минут этот сервис не может быть серверлесс.
И ещё я понимаю, что слегка попервой накосячить и вызвать сход лавины вызовов (примерно как у ребят по приведённой Вами ссылке) — ну это просто святое. Когда такое происходит (а оно неизбежно происходит), в "обычной" архитектуре тестовый кластер просто покрасится красненьким, да и ничего страшного. Серверлесс же всё стерпит и пришлёт конский счёт за услуги.
Кстати, а кто-нибудь знает, как развернуть модельку серверлесс-среды у себя на локалке? Или предлагается сразу запускаться в очень платном облаке?
Если продолжить занудствовать, то уверен, наберётся ещё список на сорок листов архитектурных ограничений и тонкостей. Кто-нибудь об этом говорит? Кто-нибудь проводит инструктаж по технике безопасности? Как раз строго наоборот, "подходит для всего" и "можно реализовать что угодно".
Задача правильной декомпозиции разрабатываемых систем и так чудовищно сложная. А с учётом дополнительных архитектурных ограничений она становится кошмаром. А с учётом того, что эти ограничения ещё и старательно замалчиваются, всё превращается в какую-то совсем мерзкую липкую хтонь.
Так что пока у меня есть только ощущение, что вся эта история про то, чтобы доверчивого и падкого на диковинки клиента (т.е. меня) меньше кормить и больше доить. Охотно готов оказаться не прав.
Реализация через стэйтлесс функции это правильный путь использования и конечно он не всем подходит. Вопрос декомпозиции приложения всегда непростой. В идеале построить бизнес-процесс, где каждым этапом является вызов небольшой функции. В сложных случаях получается развесистая схема, но она того стоит. Особенно если вы понимаете что большая часть вызовов почти никогда не дергается.
Большую часть вопросов можно обсудить в комьюнити, в нем активно участвуют разработчики сервисов и могут пояснить за нюансы.
Спасибо что откликнулись. На сообщество пока подписываться не буду т.к. сидим на Ажуре и переезжать не планируем. Хотя кто знает. В Ажуре тоже есть функции, которые, догадываюсь, идейно есть то же самое. И вот смотрю на эти функции (вот они, рядом, нажимай кнопочку "add new" и получай неземное наслаждение) и не понимаю зачем мне это. Есть смутное ощущение, что может очень даже пригодиться, но как и зачем — no idea.
Можно я порассуждаю вслух? Если забреду куда-нибудь не туда, пожалуйста поправьте.
Итак, функция. Как мы уже выяснили, оно без вариантов должно быть стейтлесс. То есть данные в себе не хранит. Если нужно хранить, то пользуемся живущими вовне базами данных, файлохранилищами, кафками и прочими товарищами, которые уже не функции, потому что они стейтфул.
Ещё функция не должна выполняться слишком долго. 30 секунд максимум. Или сутки тоже нормально, если задача достойная?
И ещё она не должна пожирать слишком много оперативы. На какое ограничение ориентироваться?
Быстрый холодный старт. Т.е. если нужен длительный предрасчёт чего-то или кеширование куска БД, то функцию делать лучше не надо.
С кешированием, насколько я понимаю, у функций вообще всё странно — его невозможно применить эффективно т.к. экземпляры функций как попало рождаются и умирают. Да и вообще, любое кеширование это уже маленький такой безобидный стейтфул.
Что у нас с параллелизмом внутри функции? Однотредовую асинхронщину, если язык позволяет, однозначно можно, но что с многопоточностью? Можно? Нельзя? Можно, но не рекомендуется?
Насколько я понимаю, GPU — запретная тема для функций, сразу и навсегда. То есть нейросети и прочие ML-дела в любом виде, что обучение, что инференс, точно не про функции.
Что с аутентификацией/авторизацией? Всё плохо или наоборот, организация авторизованного доступа это как раз тот случай, когда имеет смысл в первую очередь подумать о функциях?
Пока что я вижу следующие сценарии использования функций:
- У нас настолько тупые клиенты, что не способны выполнить простейшую операцию типа сортировки массива или ресайзинга картинки, поэтому пусть платят за свою тупость необходимостью гонять данные через сеть.
- Обёртка вокруг существующего сервиса. То есть нам нужно превратить слишком сложное или слишком полное чьё-то API в нечто простое и урезанное "для народа". Функция, по сути, будет заниматься перекладкой JSONов: сначала в одну сторону, от клиента к серверу, а потом обратно.
- Мы переигрались в NoSQL, расщепили наши данные на зоопарк хранилищ и технологий, и теперь будем латать дыры методом написания 100500 функций, которые будут джойнить данные для нас. Но поскольку это всё без кеширования, производительность будет так себе, и мы согласны это терпеть.
- Наша команда разработчиков состоит в основном из джунов без профильного образования, работающих за еду. Единственное, что они могут из параллельного это запулить одновременно пачку POST-реквестов и собрать результаты (нам стоило больших усилий обучить их этому трюку, но, кажется, удалось). Просить их собрать что-то достойное на очередях и семафорах себе дороже. Пусть могучий и мудрый облачный провайдер разберётся с нашим параллелизмом.
- У наших джунов всё плохо с оптимизацией алгоритмов. Говоришь им про О-большое — смотрят пустыми глазами. Будем тушить пожар неограниченной мощью современных датацентров. И, ну да, деньгами.
- … что-нибудь ещё?
- очереди имя им легион;
- хранилище (например, S3 тут можно почитать материальчик о том как у нас такое сгородили);
- СУБД (например, есть Serverless решения — YDB, скоро небольшой материальчик жахну на эту тему).
Лучше декомпозировать задачу и автоматически у вас ограничится время выполнения. Если вы возьмете приложение и реально построите его в Serverless-стиле то много памяти вам для каждой отдельной функции и не понадобиться. При этом «предрасчет» или «кеширование» дает некий результат и именно этот результат может быть входом для следующей функции.
Прям для эксперимента возьмите алгоритм, накидайте блоков, прикиньте: что каждый блок реализует некую функцию, и вот у нее вход, вот выход, вот ветвления разных вызовов функций.
Для сложных, емких задач, которых не так много, лучше использовать специализированные инструменты. Например, для ML почти у каждого взрослого облака что-то есть, например Yandex DataSphere
Спасибо большое за статью и ответы. Наконец-то заставил себя поразбираться с этой штукой.
Немножко дополнительно погуглив, выработал для себя чёткий набор критериев, по которым можно определить, имеет ли смысл реализовывать задачу на серверлесс. Если хотите, могу поделиться.
Обещать не могу, но идея интересная.
Итак, как понять, что для реализации задумки годится серверлесс.
Во-первых, что логично, оно должно укладываться в архитектурные ограничения. Читаем доки по используемому облаку и, например, выясняем, что для того, чтобы завершиться, у функции есть не больше пяти минут. Если была идея сделать функцией какой-нибудь нудный и долгий ETL, то не судьба. Допустим, в ограничения укладываемся, потому что если нет, то здесь разговор закончен.
Во-вторых, сразу прикидываем, пугает ли нас привязка к конкретному облачному провайдеру. И если пугает, то насколько. А если не пугает, сразу пытаемся прикинуть, какова вероятность того, что мнение по этому вопросу не изменится. Допустим, всё ОК, не пугает и пугать не собирается, потому что иначе… ну, понятно.
Если эти два барьерчика пройдены, то дальше вопрос целесообразности, где у нас развилка на три семейства ситуаций.
(а) Нам надо выкинуть в облако нечто действительно простое. Например по запросу от фронтенда выдернуть немножко данных из базы, сунуть их в пандас, немножко там покрутить, скормить матплотлибу и отдать получившийся PNG клиенту. Уже есть готовый Юпитер-ноутбук, который это умеет делать, надо только опубликовать в виде сервиса. Погружаться в хтонь девопса со всеми этими терраформами, хельм-чартами и прочими тяжеловесными CI/CD нет ни сил, ни желания, ни квалификации. Предоставляемая функциями фича "NoOps" это как раз то, что нужно.
(б) Прямо противоположная ситуация. У нас всё сложно и мощно, и фича, которая нас интересует — автоскейлинг до небес на пиковых нагрузках. И вот здесь включаем голову и смотрим, что конкретно у нас является узким местом. Если всё тормозит, то это вовсе не значит, что оно тормозит процессором. В 99% случаев оно отдыхает на операциях ввода-вывода. В этом случае асинхронка поможет лучше автоскейлинга функций хотя бы потому, что можно накрутить дополнительных плюшек типа кеширования. Плюс к тому так будет легче контролировать транзитивную нагрузку и избежать того, что функция-то справилась, но сервер базы лёг. Короче, в этом сценарии функции применяются только для вычислений. И то только если уже перевели вычисления на быстрый язык, а не на эти ваши пандасы. Да, ещё на всякий случай убедимся, что сложность, с которой воюем это O(n). В случае с O(n^p) горизонтальный скейлинг всё равно счастья не принесёт. В сухом остатке: чисто вычислительные задачи сложности O(n), уже переведённые на гошечку или С++.
(в) Лепим халтуру, главное запуститься, подписать акт и успеть добежать с деньгами до канадской границы. Серверлесс поможет проскочить нагрузочные испытания, а дальше хоть трава не расти.
Мне ближе сценарий (б), но я отдаю себе отчёт, что это весьма редкая (хотя, конечно, меткая) ситуация. Ожидаю, что подавляющее большинство поделий будут по сценариям (а) и (в).
Вообще я очень насторожено отношусь к технологиям, которые развращают разработчиков, давая им ложное ощущение снятия ресурсных ограничений. В конце концов мы живём в физической реальности, и по-настоящему неограниченные у нас только глупость и жадность.
Free Tier… это, конечно, клёво, но вот как себе локально (или на dev-сервере в пределах офиса) собрать то же — непонятно.
Т.е. мы имеем некий подход (который проживет N лет, и будет вымыт новым, еще более революционным чем-то там — да-да, с переделкой всего и вся), в котором привязаны не только к облакам, а именно к реализации облаков именно у этого провайдера. Это такой вендор-лок, который врагу не пожелаешь: вообще вариантов нет уйти — нет, и не будет.
- За пять лет активно участвовал в 98 сервисах/микросервисах.
- Сейчас активно используется 25, я к ним уже не имею отношения.
- Язык проекта менялся у 62.
- Способ дистрибуции менялся у 97 проектов.
- После запуска проекта не менялся только один проект.
- Все проекты разрабатывались для запуска в облаках.
Я не показателен и нужно смотреть отрасль, окружение. Но если вы попробуете проанализировать ваше окружение то есть не нулевая вероятность что прийдете к следующим выводам. За три-пять следующих лет большая частью ваших проектов будет переписана, переделана и способ дистрибуции будет сменён. А еще есть вероятность, что и у значительной части проектов и язык разработки будет сменен.
Называть словом serverless (т.е. буквально дословно - бессерверный) архитектуру, в которой сервер никуда не делся, просто по другому работает - это пример настоящей тупости, которой не хотелось бы видеть в IT.
Serverless-архитектура сегодня: как бессерверные решения меняют разработку