что такое бессерверные вычисления
Что такое Serverless(бессерверные вычисления)?
Прогноз ученых мужей из университета Berkeley о том как будут развиваться бэкенд технологии:
Предоставляя упрощенную среду программирования, бессерверные вычисления значительно упрощают использование облака, тем самым привлекая больше людей, которые могут и будут его использовать. Бессерверные вычисления включают в себя предложения FaaS и BaaS и знаменуют собой важный этап развития облачного программирования. Это избавляет от необходимости ручного управления ресурсами и их оптимизации, которые сегодняшние серверные вычисления навязывают разработчикам приложений, что походит на переход от языка ассемблера к языкам высокого уровня более четырех десятилетий назад.
Мы прогнозируем, что использование без серверов будет стремительно расти. Мы также прогнозируем, что локальные гибридные облачные приложения со временем будут сокращаться, хотя некоторые развертывания могут сохраняться из-за нормативных ограничений и правил управления данными.
Бессерверные вычисления станут стандартной вычислительной парадигмой в эпоху облаков, в значительной степени, заменив серверные вычисления и тем самым закрыв эру клиент-сервер.
Бессерверные вычисления — естественная для облака архитектура, которая позволяет передать большую часть операционной ответственности AWS и тем самым получить больше гибкости и инновационных возможностей. Бессерверные вычисления позволяют создавать и запускать приложения и сервисы, не беспокоясь о серверах. Они устраняют необходимость заниматься вопросами управления инфраструктурой — такими, например, как выделение серверов или кластеров, необходимых ресурсов, а также установка исправлений и обслуживание операционной системы. Их можно использовать практически для любого типа приложений или сервисов серверной части, при этом всё, что требуется для запуска и масштабирования приложения с высокой доступностью, выполняется без вмешательства клиента.
В нашем определении, чтобы услуга считалась беcсерверной, она должна автоматически масштабироваться без необходимости явной инициализации и оплачиваться в зависимости от использования.
Если очень по простому, то бессерверные (Serverless) означает не физическое отсутствие серверов, а отсутствие головной боли по управлению инфраструктурой и ее обслуживания.
Преимущества бессерверной архитектуры
В наше время существует множество способов создания приложения. Решения, которые принимаются на раннем этапе, могут и будут влиять не только на жизненный цикл приложения, но и на команды разработчиков и, в конечном счете, на компанию или организацию. В этой статье я выступаю за и излагаю способы создания ваших приложений с использованием бессерверных технологий и методологий. Но каковы преимущества создания приложения таким образом, и почему бессерверность становится настолько популярной?
Один язык программирования
С помощью современных инструментов и методологий, таких как AWS Amplify, один разработчик может использовать свой существующий набор навыков и знания единой платформы и экосистемы (например, JavaScript) для создания масштабируемых приложений, в комплекте со всеми функциями, которые в прошлом потребовались бы команды высококвалифицированных бэкэнд программистов и инженеров DevOps для сборки и обслуживания.
Единственное, что имеет ценность — это функция, которую предоставляет код, а не сам код. Когда вы находите способы предоставления этих функций, одновременно ограничивая объем поддерживаемого кода и даже полностью отказываясь от кода, вы снижаете общую сложность своего приложения.
Чем меньше сложностей, тем меньше ошибок, проще для новых инженеров и в целом меньше когнитивная нагрузка для тех, кто поддерживает и добавляет новые функции.
Разработчик может подключиться к этим сервисам и реализовать функции, не зная о фактической внутренней реализации, и практически не имея внутреннего кода.
Отсутствие необходимости управлять серверами
Не нужно выделять сервера или обслуживать их. Не требуется установка, обслуживание или администрирование программного обеспечения или среды выполнения.
Одним из основных преимуществ отсутствия сервера является масштабируемость из коробки. При создании приложения вам не нужно беспокоиться о том, что произойдет, если ваше приложение станет чрезвычайно популярным, и вы подключите большее количество новых пользователей, и облачный провайдер справится с этим за вас.
Облачный провайдер автоматически масштабирует ваше приложение, выполняя код в ответ на каждое взаимодействие. В бессерверной функции ваш код выполняется параллельно и индивидуально обрабатывает каждый триггер (в свою очередь масштабируется с учетом размера рабочей нагрузки).
Нет необходимости беспокоиться о масштабировании ваших серверов и баз данных.
При меньшем количестве функций скорость разработки увеличивается. Возможность быстрого развертывания типов функций, которые типичны для большинства приложений (базы данных, аутентификация, хранилище, API-интерфейсы), и при гораздо меньших предварительных затратах времени позволяет быстрее приступить к написанию основных функций и бизнес-логики для функции, которые вы хотите доставить конечному клиенту.
Если вы не тратите много времени на создание повторяющихся функций, вы можете экспериментировать легче и с меньшим риском.
При отправке новой функции вы часто оцениваете риск (время и деньги, связанные с созданием этой функции) с возможным возвратом инвестиций (ROI). Поскольку риск, связанный с испытанием новых вещей, снижается, вы можете испытать идеи, которые в прошлом, возможно, не видели свет.
Мы также можем гораздо проще протестировать различные идеи.
Безопасность и стабильность
Поскольку услуги, на которые вы подписываетесь, являются основной компетенцией поставщика услуг, вы получаете что-то гораздо более отточенное и обычно более безопасное, чем вы могли бы создать сами.
Представьте себе компанию, основная бизнес-модель которой сосредоточена на предоставлении первичной услуги аутентификации и которая уже много лет использует ее, решая и устраняя проблемы для тысяч компаний и клиентов.
Теперь представьте, что вы пытаетесь воспроизвести такой сервис в своей собственной команде или организации. Хотя это вполне возможно и осуществимо, есть вероятность, что выбор службы, созданной и поддерживаемой людьми, единственная задача которых состоит в том, чтобы создать и поддерживать эту точную вещь, является более безопасной и надежной ставкой.
Другой основной задачей этих поставщиков услуг является просто минимальное время простоя. Это означает, что они берут на себя бремя не только создания, развертывания и обслуживания этих сервисов, но и делают все возможное, чтобы обеспечить их стабильность и устойчивость.
Автоматический контроль доступности
Бессерверные вычисления обеспечивают встроенную высокую доступность и отказоустойчивость. Эти возможности не требуется специально проектировать, поскольку сервисы, запускающие приложение, предоставляют их по умолчанию.
При традиционном подходе вы часто платите за вычислительные ресурсы независимо от того, используются они или нет. Это означает, что если вы хотите убедиться в том, что ваше приложение будет масштабироваться, вам необходимо подготовиться к самой большой рабочей нагрузке, которую вы могли бы увидеть, независимо от того, достигла ли она этого уровня. В конце концов, этот традиционный подход означал, что вы платите за неиспользованные ресурсы большую часть срока службы вашего приложения.
С бессерверными технологиями вы платите только за то, что используете. С FaaS (Function-as-a-Service) вам выставляется счет на основании количества запросов на ваши функции и времени, которое требуется для выполнения кода вашей функции. С такими управляемыми сервисами, как Amazon Rekognition, вы платите только за обработанные изображения, минуты обработки видео и т. д., Опять же, платя только за то, что вы используете.
Счет от вашего облачного провайдера — это только часть общей стоимости вашей облачной инфраструктуры, а также заработная плата. Эта стоимость уменьшается, если у вас меньше оперативных ресурсов.
Есть также затраты на разработку. Создание приложений таким способом ускоряет вывод на рынок, сокращая общее время разработки и, следовательно, стоимость разработки.
Вообщем вы платите за стабильную пропускную способность или время исполнения, а не за количество используемых серверов.
Что такое serverless computing (бессерверные вычисления)?
Бессерверные вычисления — это метод предоставления серверных услуг на основе фактического использования сервисов. Бессерверный провайдер позволяет пользователям писать и развёртывать код, не беспокоясь о базовой инфраструктуре. Компания, которая получает бэкенд-услуги от бессерверного поставщика, платит по факту за используемые ресурсы и не должна резервировать и оплачивать фиксированную пропускную способность или количество серверов, поскольку услуга автоматически масштабируется. Конечно, для предоставления клиенту бессерверных вычислений используются физические серверы, но разработчикам нет необходимости думать об их конфигурации, производительности, ядрах, памяти и прочем.
На заре интернета любой, кто хотел создать веб-приложение, должен был физически владеть оборудованием, необходимым для запуска сервера. Это было дорого и неудобно, потому что оборудование требовало много места.
Затем пришли облачные вычисления, когда нужное количество серверов или часть серверного пространства можно было арендовать в облаке. Разработчики и компании, которые арендуют эти ресурсы, обычно приобретают мощности с некоторым запасом, чтобы гарантировать, что всплеск трафика или активности пользователей не превысит их месячные лимиты в облачной инфраструктуре и не выведет их приложение из строя. Это означает, что некоторая часть оплачиваемого серверного пространства может простаивает и не используется. Для решения этой проблемы облачные провайдеры предлагают модели автоматического масштабирования, но даже при такой модели выделения ресурсов нежелательный всплеск активности, вроде DDoS-атаки, может оказаться очень дорогостоящим.
Бессерверные вычисления позволяют разработчикам приобретать бэкенд-сервисы с оплатой по мере использования, что означает, что разработчикам нужно платить только за те услуги, которые они используют. Это похоже на переход с тарифного плана мобильного оператора с фиксированным ежемесячным лимитом на тариф, где плата взимается только за каждый фактически использованный байт данных.
Термин «бессерверный» несколько вводит в заблуждение, поскольку все ещё существуют серверы, предоставляющие эти внутренние сервисы. Но все проблемы, связанные с серверным пространством и инфраструктурой, решаются поставщиком. Бессерверный режим означает, что разработчики могут выполнять свою работу, вообще не беспокоясь о серверах.
Что такое серверные службы? В чем разница между фронтендом и бэкендом?
Разработка приложений обычно делится на две части: фронтенд и бэкенд. Фронтенд — это часть приложения, которую пользователи видят и с которой взаимодействуют, например, визуальный скелет страницы. Бэкенд — это часть, которую пользователь не видит. Она включает в себя сервер, на котором находятся файлы приложения, и базы данных, где хранятся пользовательские данные и реализована бизнес-логика.
Например, представим себе сайт, продающий билеты на концерты. Когда пользователь вводит адрес сайта в окне браузера, браузер отправляет запрос на внутренний сервер, который в ответ передаёт данные сайта. Затем пользователь видит интерфейс сайта, который может включать в себя текст, изображения и поля формы, которые пользователь должен заполнить. Пользователь может взаимодействовать с одним из полей формы на интерфейсе для поиска своего любимого музыкального исполнителя. Когда пользователь нажимает «отправить», это действие инициирует другой запрос к бэкенду. Внутренний код проверяет свою базу данных, чтобы узнать, существует ли исполнитель с таким именем, и если да, то, когда он будет выступать в следующий раз и сколько билетов доступно. Затем серверная часть передаст эти данные обратно, и интерфейс будет отображать результаты таким образом, чтобы это было понятно пользователю. Аналогичным образом происходит оплата — выполняется ещё один обмен данными между интерфейсом и сервером.
Какие серверные службы могут быть представлены бессерверными вычислениями?
Большинство бессерверных провайдеров предлагают своим клиентам услуги баз данных и хранилища, у многих есть платформы Function-as-a-Service (FaaS). FaaS позволяет разработчикам выполнять небольшие фрагменты кода на границе сети. С помощью FaaS разработчики могут создавать модульную архитектуру, делая кодовую базу более масштабируемой, не тратя ресурсы на поддержку бэкенда.
Каковы преимущества бессерверных вычислений?
Снижение затрат — бессерверные вычисления, как правило, выгодны, поскольку у многих крупных провайдеров облачных серверных услуг пользователь платит за неиспользуемое пространство или время простоя процессора.
Упрощённая масштабируемость — разработчикам, использующим бессерверную архитектуру, не нужно беспокоиться о политиках для масштабирования своего кода. Бессерверный поставщик выполняет все масштабирование по запросу.
Упрощённый внутренний код — с помощью FaaS разработчики могут создавать простые функции, которые независимо выполняют одну задачу, например, выполнение вызова API.
Более быстрый оборот — бессерверная архитектура может значительно сократить время выхода на рынок. Вместо того, чтобы требовать сложного процесса развёртывания для исправления ошибок и новых функций, разработчики могут добавлять и изменять код по частям.
В сравнении с другими моделями облачного сервиса.
Есть ещё пара технологий, которые часто путают с бессерверными вычислениями — это Backend-as-a-Service и Platform-as-a-Service. Хотя у них есть общие черты, эти модели не обязательно удовлетворяют требованиям бессерверности.
Backend-as-a-service (BaaS) — это модель обслуживания, в которой поставщик облачных услуг предлагает серверные службы (например, хранение данных), чтобы разработчики могли сосредоточиться на написании кода фронтенда. Но хотя бессерверные приложения управляются событиями и работают на периферии, приложения BaaS могут не соответствовать ни одному из этих требований.
Платформа как услуга (PaaS) — это модель, в которой разработчики по сути арендуют все необходимые инструменты для разработки и развёртывания приложений у облачного провайдера, включая такие вещи, как операционные системы и промежуточное ПО. Однако приложения PaaS не так легко масштабируются, как бессерверные приложения. PaaS также не обязательно работает на периферии и часто имеет заметную задержку запуска, которой нет в бессерверных приложениях.
Инфраструктура как услуга (IaaS) — это общий термин для поставщиков облачных услуг, размещающих инфраструктуру от имени своих клиентов. Поставщики IaaS могут предлагать бессерверные функции, но эти термины не являются синонимами.
Развитие бессерверных технологий
Бессерверные вычисления продолжают развиваться, поскольку бессерверные провайдеры предлагают решения, позволяющие преодолеть некоторые из их недостатков. Один из таких недостатков — холодный старт.
Обычно, когда определённая бессерверная функция не вызывалась в течение некоторого времени, провайдер её отключает, чтобы сэкономить энергию и избежать избыточного выделения ресурсов. В следующий раз, когда пользователь запустит приложение, которое вызывает эту функцию, бессерверному провайдеру придётся включить его заново и снова запустить эту функцию. Это добавляет некоторую задержку, известную как «холодный старт».
Как только функция будет запущена, она будет вызываться намного быстрее при следующих запросах (тёплый старт), но если функция опять не будет запрашиваться в течение некоторого времени, она снова перейдёт в неактивное состояние. И следующий пользователь, который запросит эту функцию, столкнётся с некоторой задержкой ответа из-за холодного запуска. Холодный старт — это необходимый компромисс при использовании бессерверных функций.
По мере того как устраняются все больше и больше недостатков использования бессерверных систем, можно ожидать рост популярность подобной модели предоставления вычислений.
Что ещё интересного есть в блоге Cloud4Y
Подписывайтесь на наш Telegram-канал, чтобы не пропустить очередную статью. Пишем не чаще двух раз в неделю и только по делу.
Как работают и где применяются бессерверные вычисления (Function-as-a-Service)
Serverless-вычисления и работающие на их основе решения Function-as-a-Service помогают разработчикам развивать продукты, ориентируясь на бизнес-фичи. Мы поэкспериментировали с этими технологиями и пришли к выводу, что для боевого применения существующие решения сыроваты. Пойдём по порядку.
Термин «бессерверные вычисления» отчасти вводит в заблуждение – конечно, в основе продукта сервера остаются, но разработчикам не приходится о них заботиться. По сути своей Serverless продолжает те же идеи виртуализации, что и более ранние aaS-технологии: позволить команде сосредоточиться на коде и развитии функций. Если IaaS – это абстракция оборудования, контейнеры – абстракция приложений, то FaaS – это абстракция бизнес-логики сервиса.
Идея в том, чтобы не паковать в контейнер сервер приложения, базу данных, средства балансировки нагрузки. Разработчики могут изолировать функцию в коде, загрузить её на облачной платформе и запускать её в тот момент, когда она нужна. Выделение инстансов, развёртывание кода и распределение ресурсов, запуск веб-интерфейсов, мониторинг работоспособности, обеспечение безопасности – всё это происходит автоматически.
FaaS обеспечивает максимальную гибкость в управлении производительностью – во время простоя функция вообще не потребляет ресурсы, а если потребуется, платформа быстро выделяет мощности, которых будет достаточно практически с любой нагрузкой. Обслуживает приложение одного пользователя или сразу сто тысяч – производительность системы с FaaS-архитектурой фактически не страдает, а у продукта с традиционной архитектурой обязательно начались бы проблемы.
Команда не беспокоится о бэкенде и процессах деплоя, В идеальных условиях реализация новой фичи сводится к загрузке одной функции на сервер. В результате разработка двигается быстрее, Time-to-Market ползёт вниз. А в компании в целом внедрение FaaS помогает развить платформенный подход – для Serverless-вычислений нужен либо пул облачных ресурсов от провайдера, либо Kubernetes-кластер.
Как это работает на практике
На рынке есть уже целый набор Serverless-платформ. Мы внимательно изучили два решения: Lambda от Amazon и KNative. Первое представляет собой проприетарный сервис для работы с облаком Amazon, второе работает поверх Kubernetes.
Amazon Lambda – вполне рабочий вариант со всеми возможностями, о которых мы говорили выше. Платформа выполняет все рутинные операции с продуктом, разворачивает приложения, мониторит работоспособность и производительность групп инстансов, обеспечивает отказоустойчивость и масштабирование.
Главное «но» – это проприетарный продукт, а значит вы ограничены амазоновским облаком и вынуждены использовать другие продукты их экосистемы. Если захотите сменить платформу, скорее всего, вам придётся сильно перестраивать продукт, поскольку в новой инфраструктуре правила могут сильно отличаться.
KNative – для нас решение более интересное, поскольку оно работает поверх Kubernetes.
В отличие от Lambda, в этом случае используется собственная платформа, приходится глубже погрузиться в архитектуру процесса. Выглядит она так:
Event source – сущность FaaS-платформы, которая взаимодействует с внешними источниками событий. Триггером может быть HTTP-запрос, сообщение от брокера сообщений, событие самой платформы
Broker – «корзина», которая принимает и хранит информацию о событиях от Event Source. Брокер может представлять собой модуль Kafka, работать в оперативной памяти и т.п.
Trigger – подписанный на Broker компонент, который достаёт сообщения из «корзины» и передаёт их на исполнение в Service.
Service – рабочая функция, изолированная бизнес-логика.
С точки зрения разработчика процесс выглядит практически так же, как с уже привычными контейнеризированными приложениями, меняется только объект: (1) написать функцию, (2) упаковать её в Docker-образ, (3) загрузить.
Главный недостаток KNative – нет средств логирования и мониторинга, а для FaaS-решений это критически важно. Если ваш продукт разбит на функции, без эффективного мониторинга и логирования быстро установить источник сбоя невозможно, поскольку придётся смотреть на каждую функцию отдельно.
Преимущества FaaS
Лучше всего подход показывает себя, когда не требуется мгновенный ответ пользователю и когда нагрузка может колебаться от 0 до 100%:
Задачи, которые выполняются по расписанию. Операции экспорта/импорта в системах финансовой отчётности, учётных системах, решениях для создания резервных копий.
Асинхронная отправка уведомлений пользователю (push, email, СМС).
Машинное обучение, Интернет вещей, системы ИИ – все эти отрасли точно оценят такие возможности. Serverless позволяет выполнять вычисления ближе к эндпойнту, т.е. к пользователю. А значит, у продукта уменьшается задержка, сокращается нагрузка на передачу данных.
Какие можно выделить недостатки Serverless:
Такая архитектура плохо подходит для долгосрочных процессов. Если функция используется в приложении практически постоянно, то и потребление ресурсов будет таким же, как у традиционных продуктов.
Лучшие платформы на данный момент привязывают компанию к тому или иному облачному провайдеру – будь то AWS, Microsoft Azure или Google Cloud. Решениям для Kubernetes ещё предстоит подрасти до этого уровня.
FaaS – это не «волшебная таблетка», с которой разработчики могут забыть об инфраструктуре и просто отправлять на прод фичи. Всё равно нужно продумывать архитектуру, проектировать функции и их взаимодействие с помощью DDD. Иначе продукт превращается в массу сильно связанных между собой функций, в которых будет сложно разобраться. Разработчики не смогут деплоить такие функции и менять по отдельности. В худшем случае при обработке пользовательских запросов пользователя придётся поднимать все функции.
Наш вывод – до эпохи Serverless ещё несколько лет
…При условии, что разработчики будут развивать это направление, в частности – развивать open source платформы до уровня того же Amazon Lambda.
Мотивацией таких проектов может быть сокращение затрат на ресурсы, улучшение управления большими энергозатратными продуктами. Но на данный момент разработчикам может быть проще работать «по старинке». Владение Serverless и умение использовать эти инструменты – это хороший багаж, до боевого применения компаниям стоит подождать пару лет.
Serverless-архитектура сегодня: как бессерверные решения меняют разработку
Привет, Хабр! В комментариях к статьям из нашего хаба часто спорят: полезна ли Serverless. Хочу поднять флаг миротворца — и сказать, что бессерверная технология меняет весь рабочий процесс и взгляд на разработку. Для этого есть несколько причин.
Serverless смещает оплату в сторону подхода pay-as-you-go: вы платите столько, сколько израсходовано процессорного времени (плюс-минус 100 мс). Вы не ждёте запуска сервера, не распределяете нагрузку и не заморачиваетесь с техобслуживанием. Задача написана — задача исполнена. С другой стороны, возникают проблемы холодного старта, а многим проектам не подходит отсутствие чёткого контроля контейнера. В этой статье я расскажу, в каких именно случаях может пригодиться Serverless и когда к ней надо присмотреться.
От микросервисов к бессерверности
Бессерверные технологии функционируют по принципам микросервисов. Сперва в глаза бросаются сходства — управление на основе событий. В обеих архитектурах используют автономные модули, которые запускаются для исполнения конкретных задач в логических контейнерах и скрыты от глаз конечного пользователя.
Разница в том, что микросервисы работают по системе «запрос-ответ». В Serverless же функции однонаправленные (только запрос или только ответ) и ставятся в очереди. Вместо одной прокси-функции в Serverless используются комплекс однонаправленных элементов. Если есть баг, приложение не упадёт, а не выполняться будет только одна функция вместо всего набора. Ошибку в этом случае легче найти и поправить.
Микросервисы также приходится масштабировать вручную при резком всплеске нагрузки. Даже если есть настройка автомасштабирования, с каждым сервисом приходится работать отдельно, задавая нужные параметры. Такой проблемы с Serverless нет — головная боль уходит провайдеру.
Набор микросервисов — это ещё не бессерверность. У Serverless свои преимущества, а работая по логике микросервисов, их очень просто упустить. Многие попались на эту удочку.
Лего для взрослых: как с помощью Serverless собрать любой проект
Создать сервис микроблогов? Да пожалуйста! Трекинг пульсометрии? Подержите моё пиво. Не обязательно смотреть в сторону масштабных проектов — тут вот недавно даже голосовую запись к врачу организовали.
Для простых ботов или микросервисов не обязательно вводить сразу все запланированные функции в приложение. Можно начать и добавлять по мере расширения. Масштабирование происходит автоматически и практически неограниченно.
Бессерверные технологии позволяют быстро интегрироваться в уже существующее приложение: на этот случай практически все платформы предоставляют API (через REST или очереди сообщений), с помощью которых можно разрабатывать дополнения независимо от ядра приложения.
Serverless, микросервисы, облака: что общего у ворона и письменного стола
Бессерверные технологии наследуют качества как облачных сервисов, так и микросервисов в целом.
В одах облакам всегда звучит примерно следующее: не нужно закупать оборудование, подбирать подходящее помещение и нанимать системного администратора — и хорошо, если только одного. А оплата идёт по мере использования.
Микросервисы любят за упрощённый внутренний код для простых функций (FaaS наше всё), быстрый оборот из-за возможности изменять и добавлять код по частям, не беспокоясь о том, упадёт ли проект целиком, и безграничный горизонтальный рост.
Это основы. А в чем вообще преимущества Serverless?
Изучение основ использования бессерверных технологий проходит проще и быстрее, чем обучение полноценной DevOps-разработке. Чем входной порог ниже, тем легче найти подходящего специалиста и тем скорее можно заняться непосредственно самим проектом.
Не нужно высчитывать пропускную потребность самостоятельно: бессерверные решения автоматически масштабируются вместе с поступающим трафиком.
Нет необходимости настраивать и поддерживать Kubernetes или контролировать состояние контейнеров. Правда, стоит быть внимательнее к конфигурации, иначе есть риск оказаться на грани банкротства, как случилось с разработчиками сервиса Announce.
Принципы взаимодействия бессерверных технологий с контейнерами напоминают докер — и то и другое отлично подходит для работы с микросервисами. Бессерверные технологии экономят время и нервы тем, кто не хочет беспокоиться об архитектуре, зато докер обеспечивает независимость от поставщика услуг и абсолютный контроль проекта на любой стадии. Что выбрать? Зависит от приоритетов — платформа ShoutOUT, например, перешла с докера на бессерверные технологии, чтобы снизить затраты и решить вопросы своего масштабирования и не только.
Где Serverless не подходит
Чаще всего критикуют холодный старт. Ради экономии ресурсов провайдер отключает функции, которые не вызывались в течение некоторого времени, поэтому при новом запуске функции провайдеру приходится включать её заново — и это вызывает задержку в несколько миллисекунд или даже секунд. Об этом можно почитать здесь.
Проблема решается несколькими способами — к примеру, можно запускать функции с некоторой периодичностью, чаще запускать сервис или держать часть контейнеров запущенными всё время, что сделает возможную задержку практически неощутимой. Или поддерживать минимальный размер пакетов для развёртывания — чем они меньше, тем быстрее загрузка. Некоторые провайдеры предлагают создание гибридной инфраструктуры, другие используют систему мониторинга, которая помогает оптимизировать процесс холодного запуска функций.
Как метод решения порой используется распределённая трассировка — например, AWS X-Ray. AWS X-Ray помогает анализировать приложения во время разработки и на стадии развёртывания, благодаря чему легче определить уровень производительности и найти ошибки, которые препятствуют его повышению.
При работе с Serverless важно сразу определиться с языком программирования, потому что набор поддерживаемых языков у всех провайдеров разный. К примеру, AWS поддерживает Java, Go, PowerShell, Node.js, C#, Python и Ruby, а Yandex.Cloud использует Python, PHP, Go, Node.js и Bash.
Вместе с тем AWS Lambda и Azure Functions дают возможность запуска на неподдерживаемых языках. Парадокс! Serverless продвигается как архитектура, состоящая из модулей, которые могут не так уж часто запускать, а они их не так уж часто пишут на распространённых языках программирования.
Проблема ограничений
Происходит привязка к поставщику облачных услуг. Сменить его с уже написанным приложением — дело сложное и трудоёмкое. Но возможное, и в нашем telegram чате мы обсуждаем такие случаи. На операционном уровне провайдеры не похожи, практически нет стандартизации, но по факту все ориентируются на крупных провайдеров — особенно тех, что предлагают совместимости. Например, Yandex.Cloud отлично сочетается с AWS и может использовать в числе методов интеграции HTTP API Amazon S3, SQS и DynamoDB. Помимо кода, приложения связаны с хранилищем, специфическим строением очереди и так далее. Во многих случая можно переместить не только функции. Хотя иногда проще написать новый продукт.
В качестве особенностей внесерверных платформ также упоминают отсутствие целостности приложения из-за дробления на автономные микросервисы. С одной стороны, Serverless пользуется плюсами микросервисов — структура позволяет быстрее выпускать обновления и дополнения, а ошибка в одном её фрагменте не приведёт к тому, что весь проект прекратит работу. С другой стороны, это означает, что уже готовый монолит приложения переносить на Serverless попросту слишком дорого и затратно. Бессерверные структуры сейчас часто служат как дополнение к монолиту, а не единый, готовый продукт.
Кроме того, как уже упоминалось, есть особенности, связанные с ограниченным доступом. Serverless предоставляет меньший контроль над вычислительными ресурсами: нельзя подключиться по SSH к вычислительным инстансам и выполнить настройки вручную.
Разница между провайдерами
Так как Serverless появилась на рынке относительно недавно и сильно зависит от поставщика, у каждого сервиса есть свои особенности, которые уже описывали на Хабре.
Amazon Web Services
Amazon Web Services считается самым большим и продуманным сервисом, а Amazon Free Tier позволяет начать совершенно бесплатно, и на Хабре рассказывали об опыте работы с этой платформой:
Microsoft Azure
Облачные службы Microsoft включают более двухсот различных решений. Можно использовать в любых непонятных ситуациях: например, чтобы интегрировать приложение Slack в качестве Serverless-бэкенда.
Google Cloud
Инфраструктура Google Cloud, которую платформа предлагает клиентам, точно так же используется для собственных продуктов Google, например Google Search и YouTube. Это внушает доверие, но платформа отказалась от обратной совместимости — и это приводит к некоторым любопытным последствиям. Ещё можно почитать про разбор вычислительного стека Google Cloud Platform.
Firebase
В 2018 году сервисы Firebase считались чуть ли не стандартом в индустрии разработки мобильных приложений. Сейчас их вспоминают. потому что они входят в пакет поддержки Google Cloud Platform. Интересные ссылки:
Yandex Cloud Functions
Классический представитель бессерверных технологий. Легко интегрируется с другими сервисами в Yandex.Cloud, так что, если захотите создать навык для Алисы — это ваш выбор. Интересные ссылки:
Куда идёт Serverless
Современная разработка требует быстрого внедрения новых функций, Serverless же позволяет быстро создавать и сразу тестировать новые фичи. Это даёт возможность оперативно добавлять к существующим монолитам новые функции.
Бессерверные технологии хороши в условиях пиковых нагрузок благодаря автоматическому масштабированию и модерации внешних взаимодействий — при необходимости их можно попросту отрезать от основного сервиса. Так приложение Auto.ru для тестирования по ПДД успешно выдержало участие более ста тысяч человек.
Высокую нагрузку создаёт не только наплыв пользователей, но и коннект с большим количеством устройств — и разработчик из Сиднея использовал бессерверные решения для реализации приложения, в котором как раз необходима интеграция с несколькими сторонними поставщиками, а также возможность подключения к устройствам IoT для обработки данных в полевых условиях.
Интернет вещей не лучшим образом поддерживает монолитные конструкции, поэтому Serverless в этом случае — отличный выбор. В будущем бессерверные технологии будут всё шире использоваться при работе с интернетом вещей, искусственным интеллектом, мобильными приложениями — везде, где монолитные конструкции скорее минус.
Лично я не жду, что процесс будет быстрым. Массовых отказов от старой архитектуры в ближайшее также не предвидится. Чтобы работать с Serverless, нужно не просто выучить пару новых штук, а изменить своё мышление под новый тип разработки. О новых шагах Serverless-сервисов, подробностях и нюансах разработки можно узнать в сообществе Serverless в Telegram: Yandex Serverless Ecosystem.