Комментарии 50
Прошу прощения за глупый вопрос. Где физически находятся сервера, на которых запускаются бессерверные вычисления?
Где угодно. Если я правильно понял, то основная идея бессерверного подхода в том, что приложение распилено на компоненты, завёрнутые в контейнера, связанные через сеть. Контейнеры запускаются в облаке где удобно, в том количестве которое сейчас нужно. Если железка сдохла — фиг с ней. Выключаем и запускаем новый экземпляр.
Автору больше не надо заботиться о том, что за операционка, установлены ли последние обновления и т.д. Главное чтобы контейнеры работали.
Но судя по тому, что написано в статье, всё может быть ещё глубже, облако может предоставлять ресурсы для выполнения отдельных функций, которые опять же не важно какой реальный сервер выполнит. Сделали вызов — пришёл результат.
Там круче, на самом деле вы ВООБЩЕ не знаете где они запустилися и ничего для этого не делаете.
Смотрите Amazon Lambda, к примеру
И вызов вы делаете не к ним, а через SQS или API Instance.
Сходство есть, но не полное. На shared hosting действительно администрирование взято на себя хостером. Но при этом вы лишь в ограниченных рамках можете контролировать версии необходимого вам ПО, вроде SQL-сервера, версий php. У вас нет отказоустойчивости, если сервер, на котором ваш хостинг лёг — вы ждёте когда поднимут. Ну и наконец вам не выделяются новые инстансы по мере роста нагрузки, наоборот ограниченную вычислительную мощность вы делите вместе со всеми соседями.

Покрутил недавно лямбды от авс — тоже весьма ограниченный набор версий того же python

Блин, да потому что это все просто булшит, эти все "бессерверные" решения не являются распределеными. Это те же самые сервера, только без нормального доступа к кишкам.

Не уверен. Возможность заниматься только своим кодом, отдав на откуп не только поддержку железа, но и всего остального софта, интересна и привлекательна. Другое дело, что разработка, поддержка и затраты на аренду серверного времени далеко не так бесплатны. Скорее всего подобный подход просто подходит далеко не всем. Очень не всем. Т.е. если вы не пишете что-то вроде собственного твиттера, то бессерверный подход окажется для вас слишком дорогим. Во всех смыслах.
С самого начала не понимаю хайпа, нагнанного вокруг так называемых «облачных технологий» (не без активного участия поставщиков данного рода услуг). Уже не раз был свидетелем ситуации, когда энтузиазм заканчивался где-то на 1-м счете от Amazon, после чего желание «платить только за реально потребляемые ресурсы» куда-то пропадало, а содержать ораву dedicated-серверов — со всеми их вседенно и всенощно молотящими NOPы многоядерниками — внезапно оказывалось очень даже дешево :)

Опередили. Хотел написать, что даже "серверные" облака далеко не всем подходят

> Уже не раз был свидетелем ситуации, когда энтузиазм заканчивался где-то на 1-м счете от Amazon

Несколько раз был участником разного размера проектов которые переехали в облако (амазон/гугл).
Аренда нормального железа тоже недешева, а когда новый сервер надо ждать неделю или выясняется что переткнуть кабели с первого раза не получается и нужно 2-3 попытки и несколько дней переписки или оказывается что 10гбит/с только внутри стойки а между ними шаред между клиентами без какого либо QoS и может быть 100мбит то вообще грустно… (не какойто дешевый нонейм, ракспейс).

И потом, сравнивать клауд с голым железом по цене — в корне не верно. Вы платите так же за апи, за возможности управления и мониторинга своей инфры, за менеджед сервисы которые убирают много головной боли.

P.S. даже если нужна просто молотилка — были кейсы когда сотня/тысяча серверов по spot pricing посчитать что то в течение недели обойдется дешевле чем контракт на аналогичное железо.
> бессерверный подход окажется для вас слишком дорогим. Во всех смыслах
это не так
например, мне нужно мониторить чужое апи — сделать запрос, распарсить json, положить несколько метрик в CloudWatch/tsdb и послать алерт.
В случае с сервером, это надо поднять сервер, его мониторить, мониторить саму функцию что она выполнилась, периодически ставить апдейты.
В случае с lambda/другим FaaS — я просто залил архив с кодом, поддержка самой инфры меня не беспокоит, и это все сильно дешевле аренды вм и ее поддержки.

Если же задача обрабатывать какое-то событие в инфраструктуре, например клиент залил файл в с3 бакет то вам без лямбд вообще грустно станет.

Если у вас сама задача сильно завязана на облачную инфраструктуру, то уже интегрированное в неё решение весьма вероятно окажется оптимальным. А вот если у вас обычная настроена, отлажена, отмониторина, а потом приходят и говорят а теперь делай лямбду и идёшь гуглить, а что это, что такое авс, как с ним работать…

потому, что требуется масштаб, диктующий сложности администрирования. Когда у вас близкий к реалтайму или просто HighLoad вам не до развертывания полноценных сред.
Верно приводили примерт Twitter, а еще есть Netflix и гугл типа YouTube.


Но это касается далеко не всех компонент, а только части эшелонирования системы. Раньше такими штуками, условно, назывались броккеры, которые стояли до основного сервера с логикой и БД и держали коннекшены пользователей. Теперь нам не важно на чем у нас хост, подняли контейнер с приложением/кодом и понеслось.

У Clouflare код клиентов исполняется на edge нодах в 200 городах. У Амазона тоже можно раскидать, но будет дороже простой Lambda.

Так это уже больше похоже на какие-нибудь транзакции к эфире, только без их плюсов.

Практически ни одно существующее приложение (архитектуру) нельзя перенести.

Вроде как почти любое PHP приложение можно перенести. Они и так заточены на модель пришёл запрос-подняли процесс-ответили-убили процесс. Да есть под капотом средства переиспользования процессов, но для приложения именно ответил-умер.

Будет проблема с хранением данных. Традиционные СУБД с динамическим масштабированием дружат плохо, а уж если там в хранимках бизнес-логика оказалась...


Кроме того, часто php-шники любят хранить состояние в локальных файлах, это тоже придётся переделывать. С другой стороны, тут-то архитектурных проблем с облачными решениями не будет, шардированные документ-ориентированные СУБД от локальных файлов в большинстве применений отличаются только протоколом доступа.

Я говорил о пхп-приложениях, а не об SQL-приложениях ) Тут проблема будет в другом — платить за лямбду надо будет и пока она ждёт ответа от какой-то RDS.


А локальных файлов давно не встречал, не считая заранее прогретых при деплое кэшей кодогенерации. Или пользовательских, которые надо просто взять и отдать как статику. Тут проблем быть не должно. Разве что сессии переключить на базу или kv

На самом деле не взлетело по той же причине, что и многопоточное программированние.
Просто для использования нужно высокую квалификацию, которой не обладают разработчики.

Нет квалификации — нет активного использования — не падают цены — не особо выгодно искать или приобретать нужные кадры.
Вы так говорите, что велосипедить это здорово. Каждый раз ssl разворачивать, базу, бекапы… а задачи — ну тупо код хостить прием ответ.
Так для этого есть те же API Endpoints, cloudflare и так далее.
А serverless это все же куча лишнего гемороя, который к тому же очень редко окупается.
Ну да, все разрабы поголовно тупы и ленивы настолько, что не в состоянии освоить перспективную технологию, даже если за неё будут лучше платить… А может дело в том, что это просто технология ради технологии, требует более высокую квалификацию но при этом не даёт соизмеримого повышения качества продукта?
Можно сколько угодно причитать про «индустрию, которую мы потеряли», в которой все были профессионалами высшего класса, и даже уборщики цитировали Кнута наизусть, но только в реальности вся индустрия всегда двигалась к тому, чтобы всё упрощать и удешевлять. Если вы начнёте продавать станок, для работы на котором нужна докторская по материаловеденью, он должен давать прямо на порядки лучший результат, чем станок, которым может управлять «обезьяна из ПТУ», а иначе для чего он нужен, кроме чесания ЧСВ оператора?
Так всё уже придумано есть же Erlang. Нафига надо было изобретать велосипед с квадратными колёсами?

Слишком дорого и сложно.
Я понимаю что многим хочется поиграть в крупный тырпрайз, но для большинства дедик-два за глаза.

Потому что дорого и неудобно и подходит для довольно ограниченного круга задач. Обычно проще взять обычный сервер/облако. Ситуаций, как в статьях, когда вам «вдруг» прилетел большой трафик и надо быстро развернуть 700% мощностей… да нет почти таких ситуаций. Пользоваться ущербным serverless ради мифического трафика — дорого.

Обычным проектам на самом деле даже авто-масштабирование кластеров не нужно. Проще купить сервера подешевле, чем пользоваться услугами хостеров с масштабированием.
Я точно могу подсказать ситуацию с «надо быстро развернуть 700% мощностей» и она часто наблюдается на хабре, имеет даже устойчивое название «Хабраэффект».
Скорее «медленный сайт на недорогом хостинге» эффект, но и это проходит, хабр-дудосерам всё реже удаётся этим покичиться.
Лямбды-функции – только подвид serverless. Да, запихнуть монолит туда не выйдет, но написать бота для телеги на раз-два. И это очень круто, когда вы думаете только о коде и и продукте, а вся инфраструктура вам достается в два клика (иногда и бесплатно).

Некоторые к serverless относят и k8s. В общем случае инженеры и разработчики тоже могут не знать где-что выполняется. В такой классификации даже странно вести речь про тупик, всё только начинается.

В целом было бы неплохо иметь возможность запускать/продолжать исполнять замыкания, но, боюсь, на "замыкание as a service" лопнет попа не только у гугла и амазона (У меня замыкание случайно захватило sql в 100Тб, ничего, что оно после yield поваляется в suspend пару лет?).

Д — дорого. Дешевле держать машину за 5-10$, а за 50$ уже с 32 GB RAM / 2 TB SSD в месяц, чем высчитывать сколько с тебя возьмут за выполнение 1 000 000 операций. А такой сервер спокойно держит и 1B операций в месяц.
В корне неверное сравнивать Serverless и on-premise по прямым затратам на вычислительные мощности. В таком случае, конечно, свое железо дешевле. Но не нужно забывать, что свое железо требует:
  • людей, которые будут за ним следить
  • людей, которые будут все это закупать
  • этих всех людей еще нужно нанять
  • отдельные слои документации и всякого ПО, которые надо поддерживать в актуальном состоянии
  • и еще много нюансов

Дополнительные люди — это замедление процессов: надо программисту развернуть дев окружение — пусть ждет, когда админы виртуалку поднимут. И хорошо, если есть запасной сервер, а то еще пару недель подождать надо, когда новый привезут. Все это тоже стоит денег.
Еще из плюсов Serverless и Managed облаков — оплата только за то, что используется в данный момент. Я работаю в геймдеве, у нас нагрузка на бэкенд в разы может отличаться в течение дня. В Амазоне есть автоскелинг, а в on-prem у меня была бы куча железа, которое бы простаивало полдня.


А в облаках не так? Нужно программисту развернуть дев-окружение — пучть ждёт пока те же админы не только виртуалку в облаке поднимут, но и бюджет на неё согласуют.

Мы используем AWS: разрабу/команде выдается отдельный ото всех аккаунт с ограниченным бюджетом в месяц ( + некоторые другие ограничения через Service Control Policies: ограничиваем регион, список доступных сервисов). Внутри пусть делают, что хотят, соседям ничего сломать не смогут. Прототипы можно без админов клепать, + на всякое попробовать новый сервис Амазон охотно дает бесплатные кредиты.

То есть разрабам ещё и в ценообразовании надо разбираться? А если вышел за бюджет, то до конца месяца только код без тестов на дев-енве писать? )

А амазоне и типы инстансов можно регулировать через SCP, не вижу в этом никакой проблемы

В Амазоне я умудрился потратить бесплатные кредиты, а потом влезть во вполне реальный минус в долларах, будучи уверенным, что этого мне не дадут сделать.

А у гугла, к примеру, ограничния бюджета не существует. Запустил разраб нечаянно бесконечный цикл чтения из firestore на своем dev окружении => обанкротилась ваша компания :)

Я не работал с гуглом, лишь пару виртуалок мышкой тыкал. Там есть возможность выделить отдельный аккаунт как в амазоне?
У тех, кто только проект в клауд перевез, а процессы оставил железячные — так. А если поправить процессы, то все можно заметно ускорить — бюджет выдать на команду, поэтому ваш менеджер может апрувнуть новую вм/окружение. Создать — руками в дев аккаунте или заслать PR с terraform/cloudformation кодом — в идеале через полчаса уже все будет поднято.

Процессы обычные — все траты одобрять должно высшее руководство по представленному детальному плану с обоснованием каждого пункта.

Попахивает микро-менджментом. Тут, конечно, никакое облако не спасет.

Любители on-prem считают, что все те люди, которые нужны чтобы поддерживать ДЦ в рабочем состоянии, уже есть (наняты, обучены, мотивированны, а главное эту мотивацию ни при каких условиях не теряют), а зарплата им берётся из воздуха.

С чего вы взяли? Это любители облаков считают, что все те люди, которые нужны чтобы поддерживать облачную инфраструктуру компании, уже есть (наняты, обучены, мотивированны, а главное эту мотивацию ни при каких условиях не теряют), а зарплата им берётся из воздуха). ))

Тут в дело в том, что возможности, предоставляемые облаком, для очень многих не нужны и или вообще не используются, или используются как "бесплатный" бонус при переплате за тот же инстанс AWS EC2 в несколько раз по сравнению с классическими провайдерами VDS. Сначала переехали в облако, потому что модно, стильно, молодёжно, а потом думаем какие из его возможностей можно использовать, чтобы снизить внезапно выросшую стоимость владения инфраструктурой.


То есть, если вам нужны HA, автоскейлинг и т. п., то прикинуть как их можно достичь в облаке имеет смысл. А вот перевозить туда монолиты для галочки...

Странный спор — on-prem vs cloud vs serverless

Вот, скажем, вам нужно яму выкопать. Что дешевле — нанять землекопов, нанять субподрядчиков, взять в аренду экскаватор, купить экскаватор, и т.д.

В зависимости от контекста возможны разные решения. Спорить о том, какой способ заведомо лучше другого — весьма странно. Все способы хороши в своих условиях.

Важно лишь уметь правильно определять приоритеты, и считать.

А пропихивают сначала cloud, теперь serverless как панацею. И если у вас не получается сэкономить значит просто не умеете их готовить

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.