Почему Бессерверная Революция Застопорилась



Ключевые моменты

  • Вот уже несколько лет нам обещают, что бессерверные вычисления откроют новую эру без конкретной ОС для запуска приложений.

    Нам сказали, что эта структура решит многие проблемы масштабируемости.

    На самом деле все по-другому.

  • Хотя многие считают бессерверную технологию новой идеей, ее корни уходят в 2006 год с появлением Zimki PaaS и Google App Engine, которые используют бессерверную архитектуру.

  • Есть четыре причины, по которым бессерверная революция застопорилась: от ограниченной поддержки языков программирования до проблем с производительностью.

  • Бессерверные вычисления не так уж и бесполезны.

    Нисколько.

    Однако их не следует рассматривать как прямую замену серверов.

    Для некоторых приложений они могут быть удобным инструментом.

Сервер умер, да здравствует сервер! Это боевой клич бессерверной революции.

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

Как известно всем, кто работает в отрасли, и как мы также отмечали в нашей статье о состояние бессерверных вычислений , это не верно.

Несмотря на множество статей о достоинствах бессерверная революция , этого никогда не было.

Фактически, последние исследования показывают что эта революция, возможно, зашла в тупик.

Некоторые обещания бессерверных моделей, конечно, были реализованы, но не все.

Не все.

В этой статье я хочу рассмотреть причины такого состояния.

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

Что обещали адепты бессерверных вычислений Прежде чем мы перейдем к проблемам бессерверных вычислений, давайте посмотрим, что они должны были обеспечить.

Перспективы бессерверной революции были многочисленными и порой очень амбициозными.

Для тех, кто не знаком с этим термином, вот краткое определение.

Бессерверные вычисления определяют архитектуру, в которой приложения (или части приложений) запускаются по требованию в средах выполнения, которые обычно размещаются удаленно.

Кроме того, бессерверные системы можно размещать дома.

Создание отказоустойчивых бессерверных систем было серьезной проблемой для системных администраторов и SaaS-компаний в течение последних нескольких лет, поскольку (утверждается) эта архитектура предлагает несколько ключевых преимуществ по сравнению с «традиционной» моделью клиент-сервер:

  1. Бессерверные модели не требуют от пользователей поддержки собственных операционных систем или даже создания приложений, совместимых с конкретными ОС.

    Вместо этого разработчики создают общий код, загружают его на бессерверную платформу и наблюдают за его выполнением.

  2. Ресурсы в бессерверных платформах обычно оплачиваются поминутно (или даже посекундно).

    Это означает, что клиенты платят только за время фактического запуска кода.

    Это выгодно отличается от традиционной облачной ВМ, где машина большую часть времени простаивает, но за нее приходится платить.

  3. Проблема масштабируемости также была решена.

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

Короче говоря, бессерверные модели предоставляют гибкие, недорогие и масштабируемые решения.

Удивительно, что нам не пришла в голову эта идея раньше.

Это действительно новая идея? На самом деле идея не нова.

Концепция, позволяющая пользователям платить только за время фактической работы кода, существует с тех пор, как она была представлена Зимки PaaS в 2006 году, примерно в то же время, Google App Engine предложил очень похожее решение.

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

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

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

FaaS — это, по сути, вычислительно-ориентированная часть бессерверной архитектуры, но она не представляет собой всю систему.

Так в чем же весь этот шум? Что ж, поскольку уровень проникновения Интернета в развивающихся странах продолжает стремительно расти, одновременно растет и спрос на вычислительные ресурсы.

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

Именно здесь на помощь приходят платные бессерверные платформы.

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

проблемы.

Не поймите меня неправильно: я не говорю, что они плохи сами по себе или не приносят значительной пользы некоторым компаниям в определенных обстоятельствах.

Но главное утверждение «революции» о том, что бессерверная архитектура быстро заменит традиционную архитектуру, так и не материализовалось.

Вот почему.



Ограниченная поддержка языков программирования

Большинство бессерверных платформ позволяют запускать только приложения, написанные на определенных языках.

Это серьезно ограничивает гибкость и адаптируемость этих систем.

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

AWS Lambda и Azure Functions также предоставляют оболочку для запуска приложений и функций на неподдерживаемых языках, хотя это часто приводит к снижению производительности.

Поэтому для большинства организаций это ограничение обычно не имеет большого значения.

Но вот в чем дело.

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

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

Это подрывает одно из ключевых преимуществ бессерверной модели.



Привязка поставщика

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

Стандартизации в плане написания функций, развертывания и управления практически нет. Это означает, что миграция функций с одной платформы на другую занимает чрезвычайно много времени.

Самая сложная часть перехода к бессерверной модели — это не вычислительные функции, которые обычно представляют собой просто фрагменты кода, а то, как приложения взаимодействуют с подключенными системами, такими как хранилище объектов, управление идентификацией и очереди.

Функции можно перемещать, а остальную часть приложения — нет. Это полная противоположность обещанным дешевым и гибким платформам.

Некоторые утверждают, что бессерверные модели являются новыми, и еще не было времени стандартизировать их работу.

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



Производительность

Вычислительную производительность бессерверных платформ сложно измерить, отчасти потому, что поставщики склонны сохранять конфиденциальность информации.

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

Однако отдельные факты говорят об обратном.

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

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

Конечно, есть несколько способов обойти это.

Один из них — оптимизировать функции для любого облачного языка, на котором работает ваша бессерверная платформа, но это несколько подрывает утверждение о том, что эти платформы являются «гибкими».

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

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

Поставщики облачных услуг представили новые способы сокращения холодного запуска, но многие из них требуют «масштабирования до одного», что подрывает первоначальную ценность FaaS. Проблему холодного запуска можно частично решить, запуская собственные бессерверные системы, но это сопряжено с определенными издержками и остается нишевым вариантом для команд с хорошими ресурсами.



Вы не можете запускать целые приложения

Наконец, возможно, самая важная причина, по которой бессерверные архитектуры не заменят традиционные модели в ближайшее время: они (обычно) не могут запускать целые приложения.

Точнее, это непрактично с точки зрения стоимости.

Ваш успешный монолит, вероятно, не стоит превращать в набор из четырех десятков функций, связанных восемью шлюзами, сорока очередями и десятком экземпляров базы данных.

По этой причине бессерверная технология лучше подходит для новых разработок.

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

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

Это означает, что в подавляющем большинстве случаев бессерверные платформы используются в качестве дополнения к серверным серверам для выполнения ресурсоемких задач.

Это сильно отличает их от двух других форм облачных технологий — контейнеров и виртуальных машин, — которые предлагают целостный способ выполнения удаленных вычислений.

Это иллюстрирует одну из проблем перехода от микросервисов к бессерверным технологиям.

Конечно, это не всегда проблема.

Возможность периодически использовать огромные вычислительные ресурсы без необходимости приобретения собственного оборудования может принести реальную и долгосрочную выгоду многим организациям.

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

Да здравствует революция? Несмотря на все эти жалобы, я не против бессерверных решений как таковых.

Честно.

Разработчикам просто нужно понять — особенно если они впервые изучают бессерверные технологии, — что эта технология не является прямой заменой серверов.

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

Теги: #облачные сервисы #Облачные вычисления #Высокая производительность #Бессерверные #бессерверные вычисления #Google App Engine #FaaS #Zimki PaaS

Вместе с данным постом часто просматривают: