Общие функциональные возможности CMS включают:

а) оркестрацию

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

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

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

б) планирование

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

в) мониторинг и проверку состояния

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

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

г) автоматическое масштабирование

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

д) управление ресурсами

Ресурс в CMS — это логическая конструкция, которую может создавать инструмент оркестрации и управлять ею. В качестве примера можно привести развертывание сервиса или приложения;

е) виртуальную сеть

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

ж) обнаружение сервисов

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

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

и) обновление и модернизацию

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

к) декларативную конфигурацию

Обычно CMS предоставляют команде специалистов DevOps средства для декларативной настройки конфигурации оркестрации приложения с использованием заданной схемы, написанной на таких языках программирования как YAML (yaml.org/) и JSON (www.ecma-international.org/publications-and-standards/standards/ecma-404/). Декларативная конфигурация обычно также содержит информацию о репозиториях контейнеров, сетевой конфигурации, средствах хранения и функциях обеспечения безопасности, которые поддерживает приложение. Декларативная конфигурация необходима для того, чтобы CMS могли автоматизировать процесс управления приложением и его компонентами. По сути, декларативная конфигурация указывает CMS нужную конфигурацию. CMS, в свою очередь, стремится создавать и поддерживать эту конфигурацию. Для этого она принимает решения в отношении действий, необходимых для достижения поставленной задачи, используя знания о целевых системах и внутренних стратегиях развертывания [из 7.4.2 Общие функциональные возможности CMS ГОСТ Р 70860—2023]

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

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

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

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

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

В бессерверных вычислениях часто используют модели оплаты за объем работы, выполненный облачным сервисом, а не за выделенные ресурсы (например, ВМ или контейнер). Поэтому оплата может производиться из расчета за один вызов API или, например, за один HTTP-запрос. Такую модель оплаты можно рассматривать как самый экстремальный вариант оплаты по факту потребления.

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

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

[из 8.1 Общие положения ГОСТ Р 70860—2023]

Распространенной формой бессерверных вычислений является форма «функции как услуга» (FaaS). FaaS представляет собой форму бессерверных вычислений, в которой функциональные возможности, используемые потребителем облачной службы, заключаются в выполнении кода приложения потребителя в виде одной или нескольких функций, каждая из которых запускается по выбранному потребителем событию. FaaS также является разновидностью формы «вычисления как услуга» (CompaaS) согласно определению по ГОСТ ISO/IEC 17788.

FaaS может выполнять код клиентского приложения, написанный на одном или нескольких языках программирования. Все облачные сервисы FaaS поддерживают приложения, написанные на одном или нескольких языках программирования, включая, помимо прочего, С#, Go, Java™, JavaScript, РНР, Python, Ruby, Swift. FaaS поддерживает функциональные возможности платформы как услуги в отношении предоставления программного стека среды выполнения, необходимого для выполнения кода приложения. Таким образом, потребителю облачной службы не нужно развертывать и поддерживать программный стек среды выполнения. Как правило, FaaS не требует написания кода приложения потребителя облачной службы для использования какой-либо конкретной среды разработки приложений. Кроме того, FaaS организует работу приложения и программного стека среды выполнения по требованию для обслуживания любых событий, которые запускают приложение.

Цель FaaS — сделать инфраструктуру невидимой для разработчиков приложений и сервисов. При использовании FaaS базовые серверы, ВМ и (или) контейнеры невидимы для пользователя сервиса. Разработчик не только не имеет к ним доступа, но и не может получить его, поскольку они автоматически управляются поставщиком облачной службы как часть облачного сервиса.

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

Автоматизированное управление, обеспечиваемое FaaS, является основной отличительной особенностью, т. к. высокая масштабируемость обеспечивается в автоматическом режиме. Если частота возникновения событий для данной FaaS растет, то объем ресурсов, выделяемых соответствующей облачной службе для обработки этих событий, автоматически увеличивается, а когда частота возникновения событий снижается, они удаляются [из 8.2.1 Обзор ГОСТ Р 70860—2023]