[Высокая производительность, Облачные вычисления, Облачные сервисы] Почему бессерверная революция зашла в тупик (перевод)
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Ключевые моменты
- Вот уже несколько лет нам обещают, что бессерверные вычисления (serverless) откроют новую эпоху без конкретной ОС для выполнения приложений. Нам говорили, что такая структура решит множество проблем масштабируемости. На самом деле всё иначе.
- Хотя многие рассматривают бессерверную технологию как новую идею, её корни можно проследить вплоть до 2006 года, когда появились Zimki PaaS и Google App Engine — в обоих случаях используется бессерверная архитектура.
- Есть четыре причины, по которым бессерверная революция зашла в тупик: от ограниченной поддержки языков программирования до проблем с производительностью.
- Бессерверные вычисления не так уж бесполезны. Отнюдь нет. Однако их не следует рассматривать как прямую замену серверов. Для некоторых приложений они могут быть удобным инструментом.
Сервер мёртв, да здравствует сервер!
Так звучит боевой клич адептов бессерверной революции. Достаточно бегло просмотреть отраслевую прессу последних нескольких лет, и можно легко прийти к выводу, что традиционная серверная модель мертва и что через несколько лет мы все будем использовать бессерверные архитектуры.
Как известно любому в отрасли, и как мы также указывали в нашей статье о состоянии бессерверных вычислений, это не так. Несмотря на множество статей о достоинствах бессерверной революции, она так и не состоялась. На самом деле, последние исследования показывают, что эта революция, возможно, зашла в тупик.
Некоторые из обещаний для бессерверных моделей, несомненно, были реализованы, но не все. Далеко не все.
В этой статье я хочу рассмотреть причины такого состояния. Почему отсутствие гибкости бессерверных моделей всё ещё является препятствием для их более широкого внедрения, хотя они и остаются полезными в конкретных, чётко определённых обстоятельствах.
Что обещали адепты бессерверных вычислений
Прежде чем перейти к проблемам бессерверных вычислений, давайте посмотрим, что они должны были обеспечить. Обещания бессерверной революции были многочисленными и — порой — очень амбициозными.
Для тех, кто не знаком с термином, вот краткое определение. Бессерверные вычисления определяют архитектуру, в которой приложения (или части приложений) выполняются по требованию в средах выполнения, которые обычно размещаются удалённо. Кроме того, бессерверные системы можно захостить у себя. В течение нескольких последних лет создание устойчивых бессерверных систем было главной заботой системных администраторов и SaaS-компаний, поскольку (как утверждается) эта архитектура предлагает несколько ключевых преимуществ по сравнению с «традиционной» клиент-серверной моделью:
- Бессерверные модели не требуют, чтобы пользователи поддерживали собственные операционные системы или даже создавали приложения, совместимые с определёнными ОС. Вместо этого разработчики создают общий код, загружают его в бессерверную платформу и наблюдают за его выполнением.
- Ресурсы в бессерверных фреймворках обычно оплачиваются по минутам (или даже секундам). Это означает, что клиенты платят только за то время, когда они фактически выполняют код. Это выгодно отличается от традиционной облачной VM, где машина большую часть времени простаивает, но за неё приходится платить.
- Проблема масштабируемости также решалась. Ресурсы в бессерверных фреймворках назначаются динамически, так что система легко справляется с внезапными всплесками спроса.
Короче говоря, бессерверные модели обеспечивают гибкие, дешёвые, масштабируемые решения. Удивительно, что мы не додумались до этой идеи раньше.
Это действительно новая идея?
На самом деле идея не нова. Концепция, позволяющая пользователям платить только за то время, когда код фактически запускается, существует с тех пор, как она была введена в рамках Zimki PaaS в 2006 году, и примерно в то же время Google App Engine предложил очень похожее решение.
На самом деле то, что мы сейчас называем «бессерверной» моделью, старше многих технологий, которые сейчас называют «нативными облачными», и которые обеспечивают почти то же самое. Как уже отмечалось, бессерверные модели по сути являются лишь продолжением бизнес-модели SaaS, которая существует уже несколько десятилетий.
Также стоит признать, что бессерверная модель не является архитектурой FaaS, хотя между ними есть связь. FaaS — это, по сути, ориентированная на вычисления часть бессерверной архитектуры, но она не представляет всю систему целиком.
Так к чему вся эта шумиха? Что ж, поскольку скорость проникновения интернета в развивающиеся страны продолжает стремительно расти, одновременно растёт спрос на вычислительные ресурсы. Например, во многих странах с быстро растущими секторами электронной коммерции просто нет вычислительной инфраструктуры для приложений на этих платформах. Вот тут-то и появляются платные бессерверные платформы.
Проблемы бессерверных моделей
Загвоздка в том, что у бессерверных моделей есть… проблемы. Не поймите меня неправильно: я не говорю, что они плохи сами по себе или не обеспечивают существенной ценности для некоторых компаний в некоторых обстоятельствах. Но главное утверждение «революции» — что бессерверная архитектура быстро заменит традиционную — никогда не реализуется.
Вот почему.
Ограниченная поддержка языков программирования
Большинство бессерверных платформ позволяют запускать только те приложения, которые написаны на определённых языках. Это серьёзно ограничивает гибкость и адаптивность этих систем.
Считается, что бессерверные платформы поддерживают большинство основных языков. AWS Lambda и Azure Functions также предоставляют оболочку для запуска приложений и функций на неподдерживаемых языках, хотя это часто сопряжено с затратами на производительность. Так что для большинства организаций обычно это ограничение не имеет большого значения. Но вот в чём дело. Предполагается, что одно из преимуществ бессерверных моделей в том, что малоизвестные, редко используемые программы можно использовать дешевле, поскольку вы платите только за время их выполнения. А малоизвестные, редко используемые программы часто пишутся на… малоизвестных, редко используемых языках программирования.
Это подрывает одно из ключевых преимуществ бессерверной модели.
Привязка к вендору
Вторая проблема с бессерверными платформами или, по крайней мере, с тем, как они реализуются в настоящее время, заключается в том, что они обычно не похожи друг на друга на операционном уровне. Практически нет стандартизации в части написания функций, деплоя и управления. Это означает, что миграция функций с одной платформы на другую занимает чрезвычайно много времени.
Самая трудная часть перехода на бессерверную модель — это не вычислительные функции, которые обычно представляют собой просто фрагменты кода, а то, как приложения связаны с подключёнными системами, такими как хранилище объектов, управление идентификацией и очереди. Функции можно переместить, но остальную часть приложения — нет. Это полная противоположность обещанным дешёвым и гибким платформам.
Некоторые утверждают, что бессерверные модели появились недавно, и не было времени стандартизировать их работу. Но они не так уж и новы, как я уже отмечал выше, и многие другие облачные технологии, такие как контейнеры, уже стали гораздо более удобными благодаря разработке и широкому внедрению хороших стандартов.
Производительность
Вычислительную производительность бессерверных платформ трудно измерить, отчасти потому, что вендоры стремятся сохранить информацию в тайне. Большинство утверждает, что функции на удалённых, бессерверных платформах работают так же быстро, как и на внутренних серверах, за исключением нескольких неизбежных проблем с задержкой.
Однако отдельные факты свидетельствуют об обратном. Функции, которые ранее не запускались на определённой платформе или не запускались в течение некоторого времени, требуют некоторого времени для инициализации. Вероятно, это связано с тем, что их код был перенесён на какой-то менее доступный носитель данных, хотя — как и в случае с бенчмарками — большинство вендоров не скажут вам о переносе данных.
Конечно, есть несколько способов обойти это. Один из них заключается в оптимизации функций для любого облачного языка, на котором работает ваша бессерверная платформа, но это несколько подрывает утверждение о том, что эти платформы являются «гибкими».
Другой подход заключается в том, чтобы обеспечить регулярное выполнение критически важных для производительности программ, чтобы они оставались «свежими». Этот второй подход, конечно, немного противоречит утверждению, что бессерверные платформы более экономичны, потому что вы платите только за время работы ваших программ. Облачные провайдеры внедрили новые способы сокращения холодных запусков, но многие из них требуют «масштабирования до одного» (scale to one), что подрывает первоначальную ценность FaaS.
Проблему «холодного запуска» можно частично решить путём запуска бессерверных систем своими силами, но это связано с собственными затратами и остаётся нишевым вариантом для хорошо обеспеченных ресурсами команд.
Вы не можете запускать целые приложения
Наконец, возможно, самая важная причина, по которой бессерверные архитектуры не заменят традиционные модели в ближайшее время: на них (как правило) нельзя запускать целые приложения.
Точнее, это нецелесообразно с точки зрения затрат. Ваш успешный монолит, вероятно, не стоит превращать в набор из четырёх десятков функций, связанных восемью шлюзами, сорока очередями и дюжиной экземпляров БД. По этой причине serverless лучше подходит для новых разработок. Практически ни одно существующее приложение (архитектуру) нельзя перенести. Вы можете мигрировать, но придётся начинать с нуля.
Это означает, что в подавляющем большинстве случаев бессерверные платформы используются в качестве дополнения к внутренним серверам для выполнения задач, требующих больших вычислений. Это очень сильно отличает их от двух других форм облачных технологий — контейнеров и виртуальных машин, которые предлагают целостный способ выполнения удалённых вычислений. Это иллюстрирует одну из трудностей перехода от микросервисов к бессерверным системам.
Конечно, это не всегда представляет собой проблему. Возможность периодически использовать огромные вычислительные ресурсы, не покупая собственное железо, может принести реальную и долговременную пользу для многих организаций. Но если некоторые приложения находятся на внутренних серверах, а другие — на бессерверных облачных архитектурах, то управление выходит на новый уровень сложности.
Да здравствует революция?
Несмотря на все эти жалобы, я не против бессерверных решений как таковых. Честное слово. Просто разработчики должны понимать — особенно если они впервые исследуют бессерверные модели — что эта технология не является прямой заменой серверов. Вместо этого ознакомьтесь с нашими советами и ресурсами по созданию бессерверных приложений и решите, как лучше всего применить эту модель.
===========
Источник:
habr.com
===========
===========
Автор оригинала: Bernard Brode
===========Похожие новости:
- [Open source, Amazon Web Services, Облачные сервисы, Копирайт] Разработчик заявил, что Amazon скопировал его проект с открытым кодом и запустил как свой сервис
- [GTD, Облачные сервисы, Звук] «Непрошеные рекомендации»: зачем учиться искать музыку без помощи стриминговых сервисов
- [Высокая производительность, Компьютерное железо, Смартфоны, Ноутбуки] Что такое память типа LPDDR5? — Разбор
- [PHP, Анализ и проектирование систем, Высокая производительность, Интерфейсы, Управление e-commerce] Как я за вечер написал быструю CMS для статических сайтов по правилам бизнес-логики в одном файлике
- [Криптовалюты, Децентрализованные сети, Высокая производительность, Распределённые системы] NEAR запустился! И теперь строить открытый и свободный интернет намного проще
- [Высокая производительность, D] Независимый HttpBench для D, или врут ли тесты TechEmpower? (перевод)
- [Высокая производительность, C++, Конференции, VueJS] Бесплатный IT-фестивальчик TechTrain: вторая волна
- [Help Desk Software, Service Desk, Управление продуктом, SaaS / S+S, Облачные сервисы] Ликбез по типам поддержки, задачам саппорта и вариантам автоматизации
- [Высокая производительность, GTD, Гаджеты, Удалённая работа] Лучший гаджет для продуктивности
- [Восстановление данных, Облачные вычисления, Резервное копирование] Hystax Cloud Migration: скачем по облакам
Теги для поиска: #_vysokaja_proizvoditelnost (Высокая производительность), #_oblachnye_vychislenija (Облачные вычисления), #_oblachnye_servisy (Облачные сервисы), #_serverless, #_besservernye_vychislenija (бессерверные вычисления), #_zimki_paas, #_google_app_engine, #_faas, #_vysokaja_proizvoditelnost (
Высокая производительность
), #_oblachnye_vychislenija (
Облачные вычисления
), #_oblachnye_servisy (
Облачные сервисы
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 14:00
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Ключевые моменты
Сервер мёртв, да здравствует сервер! Так звучит боевой клич адептов бессерверной революции. Достаточно бегло просмотреть отраслевую прессу последних нескольких лет, и можно легко прийти к выводу, что традиционная серверная модель мертва и что через несколько лет мы все будем использовать бессерверные архитектуры. Как известно любому в отрасли, и как мы также указывали в нашей статье о состоянии бессерверных вычислений, это не так. Несмотря на множество статей о достоинствах бессерверной революции, она так и не состоялась. На самом деле, последние исследования показывают, что эта революция, возможно, зашла в тупик. Некоторые из обещаний для бессерверных моделей, несомненно, были реализованы, но не все. Далеко не все. В этой статье я хочу рассмотреть причины такого состояния. Почему отсутствие гибкости бессерверных моделей всё ещё является препятствием для их более широкого внедрения, хотя они и остаются полезными в конкретных, чётко определённых обстоятельствах. Что обещали адепты бессерверных вычислений Прежде чем перейти к проблемам бессерверных вычислений, давайте посмотрим, что они должны были обеспечить. Обещания бессерверной революции были многочисленными и — порой — очень амбициозными. Для тех, кто не знаком с термином, вот краткое определение. Бессерверные вычисления определяют архитектуру, в которой приложения (или части приложений) выполняются по требованию в средах выполнения, которые обычно размещаются удалённо. Кроме того, бессерверные системы можно захостить у себя. В течение нескольких последних лет создание устойчивых бессерверных систем было главной заботой системных администраторов и SaaS-компаний, поскольку (как утверждается) эта архитектура предлагает несколько ключевых преимуществ по сравнению с «традиционной» клиент-серверной моделью:
Короче говоря, бессерверные модели обеспечивают гибкие, дешёвые, масштабируемые решения. Удивительно, что мы не додумались до этой идеи раньше. Это действительно новая идея? На самом деле идея не нова. Концепция, позволяющая пользователям платить только за то время, когда код фактически запускается, существует с тех пор, как она была введена в рамках Zimki PaaS в 2006 году, и примерно в то же время Google App Engine предложил очень похожее решение. На самом деле то, что мы сейчас называем «бессерверной» моделью, старше многих технологий, которые сейчас называют «нативными облачными», и которые обеспечивают почти то же самое. Как уже отмечалось, бессерверные модели по сути являются лишь продолжением бизнес-модели SaaS, которая существует уже несколько десятилетий. Также стоит признать, что бессерверная модель не является архитектурой FaaS, хотя между ними есть связь. FaaS — это, по сути, ориентированная на вычисления часть бессерверной архитектуры, но она не представляет всю систему целиком. Так к чему вся эта шумиха? Что ж, поскольку скорость проникновения интернета в развивающиеся страны продолжает стремительно расти, одновременно растёт спрос на вычислительные ресурсы. Например, во многих странах с быстро растущими секторами электронной коммерции просто нет вычислительной инфраструктуры для приложений на этих платформах. Вот тут-то и появляются платные бессерверные платформы. Проблемы бессерверных моделей Загвоздка в том, что у бессерверных моделей есть… проблемы. Не поймите меня неправильно: я не говорю, что они плохи сами по себе или не обеспечивают существенной ценности для некоторых компаний в некоторых обстоятельствах. Но главное утверждение «революции» — что бессерверная архитектура быстро заменит традиционную — никогда не реализуется. Вот почему. Ограниченная поддержка языков программирования Большинство бессерверных платформ позволяют запускать только те приложения, которые написаны на определённых языках. Это серьёзно ограничивает гибкость и адаптивность этих систем. Считается, что бессерверные платформы поддерживают большинство основных языков. AWS Lambda и Azure Functions также предоставляют оболочку для запуска приложений и функций на неподдерживаемых языках, хотя это часто сопряжено с затратами на производительность. Так что для большинства организаций обычно это ограничение не имеет большого значения. Но вот в чём дело. Предполагается, что одно из преимуществ бессерверных моделей в том, что малоизвестные, редко используемые программы можно использовать дешевле, поскольку вы платите только за время их выполнения. А малоизвестные, редко используемые программы часто пишутся на… малоизвестных, редко используемых языках программирования. Это подрывает одно из ключевых преимуществ бессерверной модели. Привязка к вендору Вторая проблема с бессерверными платформами или, по крайней мере, с тем, как они реализуются в настоящее время, заключается в том, что они обычно не похожи друг на друга на операционном уровне. Практически нет стандартизации в части написания функций, деплоя и управления. Это означает, что миграция функций с одной платформы на другую занимает чрезвычайно много времени. Самая трудная часть перехода на бессерверную модель — это не вычислительные функции, которые обычно представляют собой просто фрагменты кода, а то, как приложения связаны с подключёнными системами, такими как хранилище объектов, управление идентификацией и очереди. Функции можно переместить, но остальную часть приложения — нет. Это полная противоположность обещанным дешёвым и гибким платформам. Некоторые утверждают, что бессерверные модели появились недавно, и не было времени стандартизировать их работу. Но они не так уж и новы, как я уже отмечал выше, и многие другие облачные технологии, такие как контейнеры, уже стали гораздо более удобными благодаря разработке и широкому внедрению хороших стандартов. Производительность Вычислительную производительность бессерверных платформ трудно измерить, отчасти потому, что вендоры стремятся сохранить информацию в тайне. Большинство утверждает, что функции на удалённых, бессерверных платформах работают так же быстро, как и на внутренних серверах, за исключением нескольких неизбежных проблем с задержкой. Однако отдельные факты свидетельствуют об обратном. Функции, которые ранее не запускались на определённой платформе или не запускались в течение некоторого времени, требуют некоторого времени для инициализации. Вероятно, это связано с тем, что их код был перенесён на какой-то менее доступный носитель данных, хотя — как и в случае с бенчмарками — большинство вендоров не скажут вам о переносе данных. Конечно, есть несколько способов обойти это. Один из них заключается в оптимизации функций для любого облачного языка, на котором работает ваша бессерверная платформа, но это несколько подрывает утверждение о том, что эти платформы являются «гибкими». Другой подход заключается в том, чтобы обеспечить регулярное выполнение критически важных для производительности программ, чтобы они оставались «свежими». Этот второй подход, конечно, немного противоречит утверждению, что бессерверные платформы более экономичны, потому что вы платите только за время работы ваших программ. Облачные провайдеры внедрили новые способы сокращения холодных запусков, но многие из них требуют «масштабирования до одного» (scale to one), что подрывает первоначальную ценность FaaS. Проблему «холодного запуска» можно частично решить путём запуска бессерверных систем своими силами, но это связано с собственными затратами и остаётся нишевым вариантом для хорошо обеспеченных ресурсами команд. Вы не можете запускать целые приложения Наконец, возможно, самая важная причина, по которой бессерверные архитектуры не заменят традиционные модели в ближайшее время: на них (как правило) нельзя запускать целые приложения. Точнее, это нецелесообразно с точки зрения затрат. Ваш успешный монолит, вероятно, не стоит превращать в набор из четырёх десятков функций, связанных восемью шлюзами, сорока очередями и дюжиной экземпляров БД. По этой причине serverless лучше подходит для новых разработок. Практически ни одно существующее приложение (архитектуру) нельзя перенести. Вы можете мигрировать, но придётся начинать с нуля. Это означает, что в подавляющем большинстве случаев бессерверные платформы используются в качестве дополнения к внутренним серверам для выполнения задач, требующих больших вычислений. Это очень сильно отличает их от двух других форм облачных технологий — контейнеров и виртуальных машин, которые предлагают целостный способ выполнения удалённых вычислений. Это иллюстрирует одну из трудностей перехода от микросервисов к бессерверным системам. Конечно, это не всегда представляет собой проблему. Возможность периодически использовать огромные вычислительные ресурсы, не покупая собственное железо, может принести реальную и долговременную пользу для многих организаций. Но если некоторые приложения находятся на внутренних серверах, а другие — на бессерверных облачных архитектурах, то управление выходит на новый уровень сложности. Да здравствует революция? Несмотря на все эти жалобы, я не против бессерверных решений как таковых. Честное слово. Просто разработчики должны понимать — особенно если они впервые исследуют бессерверные модели — что эта технология не является прямой заменой серверов. Вместо этого ознакомьтесь с нашими советами и ресурсами по созданию бессерверных приложений и решите, как лучше всего применить эту модель. =========== Источник: habr.com =========== =========== Автор оригинала: Bernard Brode ===========Похожие новости:
Высокая производительность ), #_oblachnye_vychislenija ( Облачные вычисления ), #_oblachnye_servisy ( Облачные сервисы ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 14:00
Часовой пояс: UTC + 5