Comments 50
Автору больше не надо заботиться о том, что за операционка, установлены ли последние обновления и т.д. Главное чтобы контейнеры работали.
Но судя по тому, что написано в статье, всё может быть ещё глубже, облако может предоставлять ресурсы для выполнения отдельных функций, которые опять же не важно какой реальный сервер выполнит. Сделали вызов — пришёл результат.
Смотрите Amazon Lambda, к примеру
И вызов вы делаете не к ним, а через SQS или API Instance.
Кстати, есть хорошая, хотя и довольно поверхностная статья, где сравниваются эти реализации в 2020 medium.com/techmagic/aws-lambda-vs-google-cloud-functions-vs-azure-functions-what-to-choose-in-2020-6d5340b79d98
Блин, да потому что это все просто булшит, эти все "бессерверные" решения не являются распределеными. Это те же самые сервера, только без нормального доступа к кишкам.
Если у вас сама задача сильно завязана на облачную инфраструктуру, то уже интегрированное в неё решение весьма вероятно окажется оптимальным. А вот если у вас обычная настроена, отлажена, отмониторина, а потом приходят и говорят а теперь делай лямбду и идёшь гуглить, а что это, что такое авс, как с ним работать…
потому, что требуется масштаб, диктующий сложности администрирования. Когда у вас близкий к реалтайму или просто HighLoad вам не до развертывания полноценных сред.
Верно приводили примерт Twitter, а еще есть Netflix и гугл типа YouTube.
Но это касается далеко не всех компонент, а только части эшелонирования системы. Раньше такими штуками, условно, назывались броккеры, которые стояли до основного сервера с логикой и БД и держали коннекшены пользователей. Теперь нам не важно на чем у нас хост, подняли контейнер с приложением/кодом и понеслось.
У Clouflare код клиентов исполняется на edge нодах в 200 городах. У Амазона тоже можно раскидать, но будет дороже простой Lambda.
Практически ни одно существующее приложение (архитектуру) нельзя перенести.
Вроде как почти любое PHP приложение можно перенести. Они и так заточены на модель пришёл запрос-подняли процесс-ответили-убили процесс. Да есть под капотом средства переиспользования процессов, но для приложения именно ответил-умер.
Будет проблема с хранением данных. Традиционные СУБД с динамическим масштабированием дружат плохо, а уж если там в хранимках бизнес-логика оказалась...
Кроме того, часто php-шники любят хранить состояние в локальных файлах, это тоже придётся переделывать. С другой стороны, тут-то архитектурных проблем с облачными решениями не будет, шардированные документ-ориентированные СУБД от локальных файлов в большинстве применений отличаются только протоколом доступа.
Я говорил о пхп-приложениях, а не об SQL-приложениях ) Тут проблема будет в другом — платить за лямбду надо будет и пока она ждёт ответа от какой-то RDS.
А локальных файлов давно не встречал, не считая заранее прогретых при деплое кэшей кодогенерации. Или пользовательских, которые надо просто взять и отдать как статику. Тут проблем быть не должно. Разве что сессии переключить на базу или kv
Просто для использования нужно высокую квалификацию, которой не обладают разработчики.
Нет квалификации — нет активного использования — не падают цены — не особо выгодно искать или приобретать нужные кадры.
Можно сколько угодно причитать про «индустрию, которую мы потеряли», в которой все были профессионалами высшего класса, и даже уборщики цитировали Кнута наизусть, но только в реальности вся индустрия всегда двигалась к тому, чтобы всё упрощать и удешевлять. Если вы начнёте продавать станок, для работы на котором нужна докторская по материаловеденью, он должен давать прямо на порядки лучший результат, чем станок, которым может управлять «обезьяна из ПТУ», а иначе для чего он нужен, кроме чесания ЧСВ оператора?
Обычным проектам на самом деле даже авто-масштабирование кластеров не нужно. Проще купить сервера подешевле, чем пользоваться услугами хостеров с масштабированием.
Некоторые к serverless относят и k8s. В общем случае инженеры и разработчики тоже могут не знать где-что выполняется. В такой классификации даже странно вести речь про тупик, всё только начинается.
В целом было бы неплохо иметь возможность запускать/продолжать исполнять замыкания, но, боюсь, на "замыкание as a service" лопнет попа не только у гугла и амазона (У меня замыкание случайно захватило sql в 100Тб, ничего, что оно после yield поваляется в suspend пару лет?).
- людей, которые будут за ним следить
- людей, которые будут все это закупать
- этих всех людей еще нужно нанять
- отдельные слои документации и всякого ПО, которые надо поддерживать в актуальном состоянии
- и еще много нюансов
Дополнительные люди — это замедление процессов: надо программисту развернуть дев окружение — пусть ждет, когда админы виртуалку поднимут. И хорошо, если есть запасной сервер, а то еще пару недель подождать надо, когда новый привезут. Все это тоже стоит денег.
Еще из плюсов Serverless и Managed облаков — оплата только за то, что используется в данный момент. Я работаю в геймдеве, у нас нагрузка на бэкенд в разы может отличаться в течение дня. В Амазоне есть автоскелинг, а в on-prem у меня была бы куча железа, которое бы простаивало полдня.
А в облаках не так? Нужно программисту развернуть дев-окружение — пучть ждёт пока те же админы не только виртуалку в облаке поднимут, но и бюджет на неё согласуют.
То есть разрабам ещё и в ценообразовании надо разбираться? А если вышел за бюджет, то до конца месяца только код без тестов на дев-енве писать? )
А у гугла, к примеру, ограничния бюджета не существует. Запустил разраб нечаянно бесконечный цикл чтения из firestore на своем dev окружении => обанкротилась ваша компания :)
Любители on-prem считают, что все те люди, которые нужны чтобы поддерживать ДЦ в рабочем состоянии, уже есть (наняты, обучены, мотивированны, а главное эту мотивацию ни при каких условиях не теряют), а зарплата им берётся из воздуха.
С чего вы взяли? Это любители облаков считают, что все те люди, которые нужны чтобы поддерживать облачную инфраструктуру компании, уже есть (наняты, обучены, мотивированны, а главное эту мотивацию ни при каких условиях не теряют), а зарплата им берётся из воздуха). ))
Fair enough, как говорится. Но одно не отменяет другого.
Тут в дело в том, что возможности, предоставляемые облаком, для очень многих не нужны и или вообще не используются, или используются как "бесплатный" бонус при переплате за тот же инстанс AWS EC2 в несколько раз по сравнению с классическими провайдерами VDS. Сначала переехали в облако, потому что модно, стильно, молодёжно, а потом думаем какие из его возможностей можно использовать, чтобы снизить внезапно выросшую стоимость владения инфраструктурой.
То есть, если вам нужны HA, автоскейлинг и т. п., то прикинуть как их можно достичь в облаке имеет смысл. А вот перевозить туда монолиты для галочки...
Вот, скажем, вам нужно яму выкопать. Что дешевле — нанять землекопов, нанять субподрядчиков, взять в аренду экскаватор, купить экскаватор, и т.д.
В зависимости от контекста возможны разные решения. Спорить о том, какой способ заведомо лучше другого — весьма странно. Все способы хороши в своих условиях.
Важно лишь уметь правильно определять приоритеты, и считать.
Почему бессерверная революция зашла в тупик