serverless computing что это

Бессерверные вычисления (serverless computing) — что это такое и где используются

Бессерверные вычисления (их также называют serverless computing) — это набирающий популярность способ предоставления серверных услуг без аренды/покупки физического оборудования. Сервера в этом случае, разумеется, используются, но на стороне поставщика услуги. Именно он заботится о конфигурации физических серверов, их производительности, количестве CPU и RAM. Пользователь никак не взаимодействует с инфраструктурой и не обслуживает её, но при этом может писать и развёртывать код, используя готовые вычислительные ресурсы.

Оплачиваются эти ресурсы по факту потребления (модель pay-as-you-go). Резервировать и предоплачивать определённое количество серверов или пропускную способность канала не нужно. Объём потребляемых мощностей автоматически масштабируется.

Почему это востребовано? Когда интернет только начал развиваться, для запуска веб-приложения нужно было владеть оборудованием, позволяющим запустить сервер. Физическое оборудование занимало место, его нужно было обновлять и обслуживать. Это требовало много времени, денег и знаний.

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

Бессерверные технологии дали разработчикам возможность использовать бэкенд-сервисы с оплатой по мере потребления. Это можно сравнить со сменой тарифного плана с абонентской платой на тариф с побайтовой (посекундной) тарификацией.

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

Чем отличается фронтенд и бэкенд и при чём тут серверные службы

Разработку приложений можно разбить на две части: бэкенд и фронтенд. Бэкенд — это внутренняя инфраструктура. Та часть, которую пользователь не видит. Она состоит из сервера с файлами приложения и БД с пользовательскими данными. Там же реализована бизнес-логика. Фронтенд — это доступная пользователю часть приложения, которую он видит и с которой может взаимодействовать (например, интерфейс страницы).

Приведём пример. Есть сайт-агрегатор билетов на различные мероприятия. Когда пользователь вбивает в браузере нужный URL, браузер посылает запрос на внутренний сервер, получая в ответ данные этого сайта. В результате этого обмена пользователю показывается искомая страница. Допустим, там есть форма, которую нужно заполнить для поиска и покупки билета. Когда пользователь указывает в форме название мероприятия и нажимает «Отправить», формируется запрос к бэкенду. Внутренний код собирает информацию в БД, проверяя наличие мероприятия, когда оно состоится, есть ли билеты на него. Затем сервер возвращает эту информацию обратно, и фронтенд показывает результаты, трансформируя данные в понятный пользователю интерфейс. Покупка билетов выполняется по аналогичной схеме.

Какие серверные службы можно использовать как бессерверные вычисления

Как правило, провайдеры предлагают клиентам услуги баз данных и хранилища. Также существует платформа Function-as-a-Service (FaaS), благодаря которой разработчики имеют возможность формировать модульную инфраструктуру и не тратить деньги на поддержку бэкенда, что делает кодовую базу дешевле, но более масштабируемой.

Преимущества serverless computing

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

Похожие модели облачных услуг

Есть несколько технологий, которые иногда путают с бессерверными: Backend-as-a-Service, Platform-as-a-Service, Infrastructure-as-a-Service. Да, у них есть схожие черты, но это разные бизнес-модели.

Backend-as-a-service (BaaS). Облачный провайдер связывает приложения с серверным облачным хранилищем и создаёт условия для того, чтобы разработчики могли сконцентрироваться на работе с кодом фронтенда. BaaS является составляющей serverless технологии, но сам по себе бессерверным называться не может.

Platform-as-a-Service (PaaS). Модель «Платформа как услуга» предполагает, что разработчики арендуют у облачного провайдера инструменты для разработки и развёртывания. Это могут быть ОС, промежуточное ПО и т.д. Однако в случае с PaaS масштабирование идёт тяжелее, платформа не всегда работает на периферии и может запускаться с заметной задержкой, которой нет у serverless-приложений

Infrastructure-as-a-Service (IaaS). Модель «Инфраструктура как услуга» включает в себя много вариантов предоставления инфраструктуры. Провайдер может предлагать бессерверные решения в рамках IaaS, но эти понятия синонимами не являются.

Что ждёт бессерверные технологии

Serverless computing будут развиваться и дальше, поскольку поставщики работают над появлением новых услуг и устраняют имеющиеся недостатки. Например, решают проблему холодного старта. Вопрос заключается в том, что когда какая-либо бессерверная функция долго не вызывается, провайдер её отключает. Это делается для снижения объёма выделяемых ресурсов. И когда функция всё же понадобится, провайдеру требуется включить её заново и затем запустить. Это вызывает небольшую задержку, которая и получила название «холодный старт».

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

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

Источник

Serverless по стоечкам

Serverless ― это не про физическое отсутствие серверов. Это не «убийца» контейнеров и не мимолетный тренд. Это новый подход к построению систем в облаке. В сегодняшней статье коснемся архитектуры Serverless-приложений, посмотрим, какую роль играет провайдер Serverless-услуги и open-source проекты. В конце поговорим о вопросах применения Serverless.

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

А что если взять эфемерные контейнеры, в которых требуемые зависимости уже предустановлены, а сами контейнеры изолированы друг от друга и от ОС хоста? Монолит разобьем на микросервисы, каждый из которых можно обновлять и масштабировать независимо от других. Поместив код в такой контейнер, я смогу запускать его на любой инфраструктуре. Уже лучше.

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

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

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

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

Со стороны разработчика

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

Чтобы перейти к serverless, разбиваем приложение на микрозадачи. Под каждую из них пишем свою функцию. Функции независимы друг от друга и не хранят информацию о состоянии (stateless). Они даже могут быть написаны на разных языках. Если одна из них «упадет», приложение целиком не остановится. Архитектура приложения будет выглядеть вот так:

Деление на функции в Serverless похоже на работу с микросервисами. Но микросервис может выполнять несколько задач, а функция в идеале должна выполнять одну. Представим, что стоит задача собирать статистику и выводить по запросу пользователя. В микросервисном подходе задачу выполняет один сервис с двумя точками входа: на запись и на чтение. В бессерверных вычислениях это будут две разные функции, не связанные между собой. Разработчик экономит вычислительные ресурсы, если, например, статистика обновляется чаще, чем выгружается.

Serverless-функции должны выполняться за короткий промежуток времени (timeout), который определяет провайдер услуги. Например, для AWS timeout составляет 15 минут. Значит, долгоживущие функции (long-lived) придется изменить под требования ― этим Serverless отличается от других популярных сегодня технологий (контейнеров и Platform as a Service).

Каждой функции назначаем событие. Событие ― это триггер для действия:

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

Архитектуру проработали, и приложение почти стало serverless. Дальше идем к провайдеру услуги.

Со стороны провайдера

Обычно бессерверные вычисления предлагают провайдеры облачных услуг. Называют по-разному: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.

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

Провайдер на своей инфраструктуре построил и автоматизировал систему Function as a Service (FaaS):

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

Основное преимущество работы с провайдером ― возможность не беспокоиться об инфраструктуре (серверах, виртуальных машинах, контейнерах). Со своей стороны провайдер может реализовать FaaS как на собственных разработках, так и с помощью open-source инструментов. О них и поговорим дальше.

Со стороны open source

Последние пару лет сообщество open-source активно работает над инструментами Serverless. В том числе вклад в развитие бессерверных платформ вносят крупнейшие игроки рынка:

Фреймворки оставляют простор для конфигурации инструмента под свои нужды. Так, в Kubeless разработчик может настроить timeout выполнения функции (дефолтное значение ― 180 секунд). Fission в попытке решить проблему холодного старта предлагает часть контейнеров держать все время запущенными (хоть это и влечет затраты на простой ресурсов). А OpenFaaS предлагает набор триггеров на любой вкус и цвет: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NATs и другие.

Инструкции к началу работы можно найти в официальной документации фреймворков. Работа с ними подразумевает наличие чуть большего количества навыков, чем при работе с провайдером ― это как минимум умение запустить Kubernetes-кластер через CLI. Максимум, включить в работу другие open-source инструменты (допустим, менеджер очередей Kafka).

Вне зависимости от того, каким способом мы будем работать с Serverless ― через провайдера или с помощью open-source, мы получим ряд преимуществ и недостатков Serverless-подхода.

С позиции преимуществ и недостатков

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

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

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

Как и любая технология, Serverless имеет недостатки.

Например, таким недостатком может быть время холодного старта (в среднем до 1 секунды для таких языков как JavaScript, Python, Go, Java, Ruby).

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

Холодный старт может превратиться в теплый, когда функция переиспользует запущенный предыдущим ивентом контейнер. Такая ситуация возникнет в трех случаях:

Следующим недостатком Serverless называют короткое время жизни функции (timeout, за который функция должна выполниться).

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

Не все системы смогут работать по Serverless-схеме.

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

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

Со стороны применения

За 2018 год процент использования Serverless вырос в полтора раза. Среди компаний, которые уже внедрили технологию в свои сервисы, такие гиганты рынка как Twitter, PayPal, Netflix, T-Mobile, Coca-Cola. При этом нужно понимать, что Serverless ― не панацея, а инструмент для решения определенного круга задач:

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

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

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

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

Serverless и Selectel

В Selectel мы уже упростили работу с Kubernetes в виртуальном приватном облаке через нашу панель управления. Теперь мы строим собственную FaaS-платформу. Мы хотим, чтобы разработчики могли решать свои задачи с помощью Serverless через удобный, гибкий интерфейс.

Хотите следить за процессом разработки новой FaaS-платформы? Подпишитесь на рассылку об «Облачных функциях» Selectel на странице услуги. Мы будем рассказывать о ходе разработки и анонсируем закрытый релиз «Облачных функций».

Если у вас есть идеи, какой должна быть идеальная FaaS-платформа и как вы хотите использовать Serverless в своих проектах, поделитесь ими в комментариях. Мы учтем ваши пожелания при разработке платформы.

Источник

Бессерверные вычисления на AWS

AWS предлагает технологии для запуска кода, управления данными и интеграции приложений без управления серверами. Бессерверные технологии обеспечивают автоматическое масштабирование, встроенную высокую доступность и оплату по мере использования, чтобы повысить гибкость и оптимизировать затраты. Эти технологии избавляют от таких задач по управлению инфраструктуры, как предоставление ресурсов и исправлений, и вы можете сконцентрироваться на написании кода, который обслуживает клиентов. В начале бессерверных приложений лежит AWS Lambda, вычислительный сервис на основе событий, по умолчанию встроенный в более чем 200 сервисов AWS и приложений по модели «программное обеспечение как услуга» (SaaS).

Сделайте следующий шаг

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

Хотите дать своим командам разработчиков больше возможностей? Прочитайте эти аналитические отчеты IDC.

Нужно быстро создать продукт с минимальной функциональностью (MVP)? Узнайте, как получить доступ к учетным данным и разработайте свое первое приложение.

Источник

Облачные решения, Serverless и вот это все. Кому нужно, как работает и что выбрать для разработки в 2020

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

Давайте разбираться, кому и зачем это нужно, как это все работает и какие инструменты сегодня существуют.

Облачные технологии уже стали неотъемлемой частью разработки благодаря Amazon Web Services, Microsoft Azure и Google Cloud Platform. Так что serverless или бессерверная архитектура — логический следующий шаг в развитии облаков, цель которого — ускорение разработки и снижение издержек.

Рынок согласен с этим утверждением — каждый год сегмент serverless-услуг растёт на 75% и при развитии в таком темпе достигнет 7,7 миллиардов долларов к 2021 году. Только в 2018 году технологией стали пользоваться в 1,5 раза чаще: serverless использовали 36% опрошенных представителей компаний, а ещё 22% — экспериментировали на предмет внедрения.

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

Для работы приложения всегда выделяется ровно столько ресурсов, сколько нужно

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

Экономится время на настройку и обслуживание серверов

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

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

Infrastructure as code (IaC)

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

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

Привязка к сервису

Возможна ситуация, когда разработав и запустив serverless приложение на одной из платформ, вы не сможете переехать на другую без серьёзной переработки кода из-за различия в архитектуре сервисов и отсутствия поддержки нужных языков. Например, в системах управления баз данных — AWS использует DynamoDB, Azure — CosmosDB. AWS поддерживает язык Go, Google Cloud Platform — нет.

Повышенные расходы в некоторых случаях

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

Ограниченный срок жизни инстанса

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

Задержки из-за постоянных холодных стартов

Продолжение предыдущего недостатка — если процесс завершился к тому моменту, когда он понадобился снова — придётся тратить 1-3 секунды на запуск.

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

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

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

В 2020 году на рынке представлено около десятка компаний, которые предоставляют облачные сервисы для бессерверной разработки. Из них наибольшими ресурсами и популярностью обладают 3: AWS Lambda от Amazon, Azure Functions от Microsoft и Google Cloud Functions. Есть у них и перспективные конкуренты, например, IBM, Alibaba и несколько других. Но здесь и сейчас для разработки лучше выбрать кого-то из большой тройки.

Сервис-пионер для разработки бессерверных приложений появился в 2014 году и за счёт раннего старта занял самую большую долю на рынке. Поддерживает Node.js, Python, Java (Java 8), C #, Go, Visual Basic, F #.

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

Подробная документация и большое сообщество. Если у вас проблема — то с большой долей вероятности кто-то уже столкнулся с ней и предложил решение

Сервис номер 2, появился на рынке в 2016 году. Поддерживает C #, F #, Python, Java, Javascript, Node.js, PHP, Bash, Batch, PowerShell

Сервис был запущен в 2017 году, но долгое время находился в бета-стадии и отставал от двух других. Ситуация стала меняться в 2018 году, когда Google занялся активным развитием Cloud Functions. Несмотря на это, платформа до сих пор отстаёт от лидеров по количеству дата-центров, поддерживаемых языков и возможностей интеграции с другими продуктами. Поддерживает Node.js, Python.

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

Самым продвинутым и популярным на — данный момент является фреймворк Serverless — с таким же названием, как и сама технология. Он написан на Node.js и хорош своей универсальностью:

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

Также как и фреймворк Serverless, Terraform совместим с AWS, Azure и Google Cloud.

Источник