ГОСТ Р ИСО/МЭК 19941-2021. Национальный стандарт Российской Федерации. Информационные технологии. Облачные вычисления. Интероперабельность и переносимость

6.4 Функциональные компоненты переносимости приложения

6.4.1 Общие положения

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

Примечание - На основании ИСО/МЭК 17789:2014, рисунок 9-2.

 

 

Рисунок 12 - Уровень службы, уровень ресурсов

и многоуровневые функциональные компоненты эталонной

архитектуры облачных вычислений

 

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

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

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

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

Некоторые артефакты, зависимости служб и ресурсы двух приложений приведены на рисунке 12, который получен из ИСО/МЭК 17789:2014 (рисунок 9-2). Зависимости приложений от служб обозначены пунктирным контуром, обозначающим, что это только требования, и необходимо сделать выбор в отношении того, как эти зависимости реализуются в различных сценариях. Такая нотация расширяет нотацию из ИСО/МЭК 17789. В примере, приведенном на рисунке 12, фактические экземпляры функциональных компонентов, которые обеспечивают эти требования, обозначены сплошными контурами.

Зависимости приложения от служб реализованы:

- внутри самого приложения;

- другими поддерживающими приложениями;

- внутри самого уровня службы;

- уровнем ресурсов;

- сочетанием всего вышеперечисленного.

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

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

Артефакты приложения включают в себя:

- наборы инструкций: это логика, которая определяет выполнение приложения и может включать в себя исходный код или объектный код компьютерного программирования, такой как C++, Perl, Java или Python, или определения набора команд, таких как BPEL;

- наборы данных: приложение может само использовать данные, такие как список дней недели, стран мира или другую информацию, которую оно использует при выполнении;

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

У приложений существует несколько зависимостей, которые обычно не являются частью самого приложения, и могут включать в себя:

- среду исполнения: эти среды интерпретируют исходный или промежуточный код или запускают скомпилированный код. Для разных типов наборов инструкций могут быть разные среды исполнения. Таким образом, если приложение состоит из некоторого кода Java, а также инструкций BPEL, для этого приложения, вероятно, будет несколько сред исполнения;

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

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

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

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

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

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

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

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

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

6.4.2 Функциональные представления на основе типов возможностей

Подобно рисунку 12, функциональные представления, приведенные на рисунках 13, 14, 15 и 16, показывают различные реализации приложений из необлачного окружения, а также реализации облачных вычислений на основе различных типов возможностей. Служебные зависимости для приложения 1, приведенные на рисунке 13, в этих реализациях являются лишь ориентировочным подмножеством зависимостей, так как вполне вероятно, что фактический список зависимостей для любого приложения намного больше. Эти зависимости могут удовлетворить поддерживающие приложения или другие функциональные компоненты, развернутые, как приведено на рисунке 13.

 

 

Рисунок 13 - Необлачное приложение

 

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

 

 

Рисунок 14 - Пример приложения, выполняющегося в службе

облачных вычислений с типом возможностей инфраструктуры

 

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

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

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

 

 

Рисунок 15 - Пример приложения, выполняющегося в службе

облачных вычислений с типом возможностей платформы

 

 

 

 

Рисунок 16 - Пример приложения, выполняющегося в службе

облачных вычислений с типом возможностей платформы

с первичным и вторичным поставщиками службы

облачных вычислений

 

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

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

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

Рассмотренный пример показывает, что итоговое приложение может использовать широкий спектр сервисов от многих поставщиков.

 

 

Рисунок 17 - Приложение, использующее несколько служб

облачных вычислений и необлачный центр обработки данных