Serverless paas что это

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):

Таким образом мы получаем Serverless «из коробки». Платить за услугу будем по модели pay-as-you-go и только за те функции, которые используются, и только за то время, когда они использовались.

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

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

Со стороны open source

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

Разработки ведутся и в направлении serverless-фреймворков. Kubeless и Fission разворачиваются внутри заранее подготовленных Kubernetes-кластеров, OpenFaaS работает как с Kubernetes, так и с Docker Swarm. Фреймворк выступает в роли своеобразного контроллера ― по запросу готовит внутри кластера среду выполнения, потом запускает там функцию.

Фреймворки оставляют простор для конфигурации инструмента под свои нужды. Так, в 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 с другой технологией.

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

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

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

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

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

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

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

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

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

Serverless и Selectel

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

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

Источник

Что такое Serverless Архитектура и в чём её преимущества?

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

Определение

Serverless computing is a cloud-computing execution model in which the cloud provider acts as the server, dynamically managing the allocation of machine resources. Pricing is based on the actual amount of resources consumed by an application, rather than on pre-purchased units of capacity.

Не волнуйтесь если не все понятно, скоро мы во всем разберемся. Но до этого прочитаем еще одно определение с Вики. На этот раз про FaaS, термин, неразрывно связанный с Serverless.

Function as a service (FaaS) is a category of cloud computing services that provides a platform allowing customers to develop, run, and manage application functionalities without the complexity of building and maintaining the infrastructure typically associated with developing and launching an app.

В этих определениях собраны три основные черты того, что называют Serverless:

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

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

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

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

Области применения

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

Это случаи отложенных, или фоновых задач. Например:

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

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

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

Автор статьи, может стать твоим ментором и научить всему этому и многому другому Нанять

Поставщики услуг

Один из лидеров рынка FaaS услуг в наши дни — это AWS с их сервисом AWS Lambda. У них есть поддержка большого числа языков программирования (включая Ruby, Python, Go, NodeJS, C# и Java) и огромного количества сервисов, которые позволяют вам использовать не просто Serverless computing, но также и Database as a service, очереди сообщений, API Gateway и прочие, которые значительно упрощают работу с этой моделью.

Помимо AWS стоит отметить Google Cloud и Microsoft Azure с их продуктами Google Functions и Azure Functions, с которыми лично у меня опыта меньше и, насколько я могу судить, они все же пока отстают от AWS в этой сфере. Например, Google поддерживает лишь NodeJS и Python. Azure поддерживает гораздо больше, но многие из них только в экспериментальном статусе.

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

Резюмируя преимущества

Перед завершением статьи я бы хотел еще раз отметить плюсы применения Serverless.

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

Полная абстракция от операционной системы или любого софта, использующегося для выполнения приложения. Вам неважно, запускаются ли ваши Serverless приложения на Линуксе, Винде или самописной OS. Всё, что вас волнует — это способность платформы выполнять Python/Java/Ruby/YouNameIt код и сопутствующие библиотеки для этого ЯП.

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

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

Не обойтись и без недостатков

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

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

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

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

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

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

Так называемый vendor lock. Функции, разработанные для AWS будет очень сложно портировать на, например, Google Cloud. Причем не из-за самих функций, JS он и в гугле JS, а скорее из-за того, что вы редко используете Serverless функции в изоляции. Помимо них, вы будете использовать БД, очереди сообщений, системы логирования и прочее, что совершенно точно отличается от провайдера к провайдеру. Однако при большом желании даже эту функциональность вы можете сделать не зависящей от облачного провайдера.

Заключение

Хоть минусов и получилось больше чем плюсов, это не значит, что Function as a Service это плохое движение и после прочтения этой статьи вам следует забыть про него навсегда. Совершенно напротив, многие риски могут быть или минимизированы, или просто приняты как факт. Например, можно прогревать функции, чтобы пользователю никогда не приходилось ждать, когда она запустится. Для дебага существуют подходы, которые делают его менее болезненным. Vendor lock не будет проблемой для большинства бизнесов.

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

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

Спасибо за внимание, если вам интересны Serverless и Microservices подходы, языки Ruby и JS, а также Cloud Infrastructure — буду рад быть вашим ментором. Если же у вас есть конструктивная критика или предложения — буду также рад вашим личным или публичным сообщениям.

Благодарю и желаю вам успехов в работе и образовании, дорогие читатели!

Источник

Облачные решения, 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.

Источник