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

Понять термин «бессерверные вычисления» (serverless computing) нелегко. По своей сути он указывает на то, чего нет в технологии, и даже в этом случае он не передает весь ее смысл. Бессерверные вычисления не означают отсутствия серверов, они есть, выполняют вычисления и оперируют битами, пока мигают светодиоды и жужжат вентиляторы. Просто они находятся вне поля зрения, за занавесом, как Волшебник из страны Оз. В данном случае «отсутствие сервера» скорее говорит об отсуствии необходимости заботиться о поддержании работоспособности оборудования: обновлении ОС, настройке брандмауэра и драйверов и т. п. Идея бессерверной технологии заключается в том, что она снимает этот груз с плеч пользователя.

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

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

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

1. Императивная бессерверная функция

Первое поколение бессерверных инструментов позволяло взять старый код и спрятать его за одной функцией, которая выполняла роль триггера. После ее вызова он указывал компьютеру, что именно делать с данными. Например, лямбда-функции Amazon могут быть написаны на Java, Go, PowerShell, Node.js, C#, Python или Ruby. Если этого недостаточно, вы можете создать собственную среду выполнения практически для любого языка. Слово «императив» употребляется сообществом разработчиков для описания ситуации, когда программист указывает компьютеру, что именно нужно делать. Некоторые люди шутят, что единственная реальная разница заключается в том, что разработчики, применяющие императивное программирование, пишут циклы, а все остальные — нет.

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

2. Декларативные приложения

Термин «декларативный» противопоставляют императиву, и обычно он ассоциируется с переходом к более абстрактной модели программирования. Вместо того чтобы указывать компьютеру, что именно нужно делать, вы просто декларируете, что должно произойти, а компьютер заполняет детали. Это правило действует только тогда, когда компьютер обучили для решения проблемы, чтобы он знал, как справиться со всем остальным. Поставщики бессерверных решений употребляют этот термин, когда у них есть сложный вспомогательный слой. Azure, например, предлагает более «декларативный» подход к некоторым вызовам API. Новая среда программирования, Ripple, упрощает способ определения проблемы, поскольку она достаточно «умна», чтобы знать, как и когда вызывать параллельную обработку.

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

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

3. Бессерверные базы данных

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

Часть самых первых облачных API, например, Amazon S3, хранят и извлекают байты на основе их имен, абстрагируясь от файловой системы, репликации или резервного копирования.

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

4. Наносервисы

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

5. Макросервисы

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

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

6. API

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

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

7. Сеть доставки контента

Статические ресурсы — это не совсем подходит для бессерверной функции, потому что они обычно доставляются без изменений. Но разработчики больше заинтересованы в скорости сети доставки контента (CDN), проектируя свои приложения таким образом, чтобы они были как можно более статичными. Некоторые преобразуют некогда динамические системы, такие как Drupal или WordPress, используя генератор статических сайтов для предварительного расчета ответа для всех возможных URL. Это, возможно, самое легкое и простое проявление философии бессерверной функции.

Если ваш сайт или приложение можно свести к набору файлов HTML, CSS, JavaScript и нескольких изображений, то CDN, безусловно, является самым дешевым бессерверным решением. Генераторы статических сайтов позволяют создавать некоторые многофункциональные варианты, которые технически все еще являются просто статическими коллекциями файлов.

8. Базовый хостинг

Одним из самых ранних способов создания веб-сайта было получение аккаунта на виртуальном оборудовании — вариант на базовом стеке LAMP. По этой модели были созданы многие из самых ранних динамических веб-сайтов. Некоторые создавали целые PHP-приложения, а другие основывались на решениях с открытым кодом, таких как WordPress и Drupal. Развертывание приложения LAMP на виртуальном сервере старого образца мало чем отличается от развертывания в качестве «официального» бессерверного варианта. Основное отличие состоит в тарификации, которая в первом случае обычно представляет собой фиксированную месячную подписку, тогда как в большинстве бессерверных вариантов применяется модель оплаты за вызов.

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

Стеки LAMP и PHP могут показаться древними технологиями, но классические виртуальные серверы часто являются хорошими и дешевыми решениями для базовых приложений. Они позволяют многое сделать. Если ваш список задач соответствует набору функций классических инструментов, таких как Drupal или WordPress, то, рассматривая их как бессерверные варианты, вы можете получить довольно много проверенных временем возможностей.

Привязка к одному поставщику как услуга?

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

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

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

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

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

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

Вопрос выбора

Существует ли идеальный выбор? Возможно. В зависимости от ситуации вы захотите расставить приоритеты с языком и структурой, чтобы расширить свои инвестиции в тот или иной язык. Возможно, вы захотите выбрать императивную структуру, которая обеспечивает гибкость. Не исключено, что вы даже захотите расширить свои инвестиции в БД, используя ее в качестве бессерверного варианта. Или же вас могут привлечь возможности, которые открываются благодаря некоторым декларативным фреймворкам, которые предлагают функции и оптимизации, соответствующие вашей задаче.

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

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