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

1 ПОДГОТОВЛЕН Обществом с ограниченной ответственностью "Информационно-аналитический вычислительный центр" (ООО ИАВЦ) на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 22 "Информационные технологии"

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 19 ноября 2021 г. N 1523-ст

4 Настоящий стандарт идентичен международному стандарту ИСО/МЭК 19941:2017 "Информационные технологии. Облачные вычисления. Интероперабельность и переносимость" (ISO/IEC 19941:2017 "Information technology - Cloud computing - Interoperability and portability", IDT).

ИСО/МЭК 19941 разработан Подкомитетом ПК 38 "Облачные вычисления и распределенные платформы" Совместного технического комитета СТК 1 "Информационные технологии" Международной организации по стандартизации (ИСО) и Международной электротехнической комиссии (МЭК)

5 ВВЕДЕН ВПЕРВЫЕ

6 Некоторые положения международного стандарта, указанного в пункте 4, могут являться объектом патентных прав. ИСО и МЭК не несут ответственности за идентификацию подобных патентных прав

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

Облачные вычисления определяются как парадигма предоставления сетевого доступа к масштабируемому и эластичному пулу разделяемых физических или виртуальных ресурсов с обеспечением самообслуживания и администрированием по требованию. ИСО/МЭК 17788 и ИСО/МЭК 17789 обеспечивают основу для понимания различных типов интероперабельности и переносимости, отношений между деятельностями, ролями и типами облачных вычислений. Интероперабельность, переносимость данных и переносимость приложений имеют важное значение для использования служб облачных вычислений. Целью интероперабельности является обеспечение взаимодействия между необлачными и облачными службами, между службами облачных вычислений, а также создание новых служб из композиции нескольких служб. Цель переносимости - позволить потребителям служб облачных вычислений перемещать свои данные или приложения между необлачными службами и одной или несколькими службами облачных вычислений, а также между службами облачных вычислений. Преимущества интероперабельности заключаются в снижении затрат на интеграцию и повышении ценности услуг за счет обогащения существующих или добавления новых функциональных возможностей благодаря композиции служб облачных вычислений. Преимущества переносимости заключаются в повышении эффективности за счет снижения затрат на миграцию. Как интероперабельность, так и переносимость предлагают больше возможностей для потребителей служб облачных вычислений благодаря уменьшению последствий привязки к конкретной службе облачных вычислений или поставщику службы облачных вычислений. Несмотря на то, что не существует никаких разногласий в том, что интероперабельность и переносимость являются преимуществами облачных вычислений, нет единого способа использования этих возможностей. Применение интероперабельности или переносимости без детального анализа того, что конкретно должно быть перенесено или должно быть совместимым, бессмысленно и не приводит к облачным решениям, которые отвечают бизнес-целям потребителя служб облачных вычислений и поставщика служб облачных вычислений. Это приводит к значительной и продолжающейся путанице в области облачных вычислений и требует разрешения.

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

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

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

Как определено в ИСО/МЭК 17788, переносимость - это способность потребителя служб облачных вычислений перемещать свои данные или приложения между двумя различными службами облачных вычислений по низкой цене и с минимальными потерями. Переносимость важна в облачных вычислениях, так как потребители служб облачных вычислений заинтересованы в том, чтобы избежать попадания в зависимость от поставщика при использовании служб облачных вычислений. Поэтому в контексте облачных вычислений переносимость может иметь несколько аспектов в зависимости от того, что переносится (перемещается) и какие службы задействованы. Для переносимости нет требования, чтобы исходная и целевая системы были непосредственно подключены коммуникационной инфраструктурой.

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

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

Настоящий стандарт связан с другими стандартами, а именно ИСО/МЭК 17788, ИСО/МЭК 17789, ИСО/МЭК 19086-1, ИСО/МЭК 19944, и, в частности, содержит ссылки на сквозные аспекты и компоненты, определенные в ИСО/МЭК 17788 и ИСО/МЭК 17789, соответственно.

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

В настоящем стандарте нормативные ссылки отсутствуют.

В настоящем стандарте применены следующие термины с соответствующими определениями.

ИСО и МЭК поддерживают терминологические базы данных для использования в области стандартизации по следующим адресам:

- МЭК Электропедия: доступна по адресу /template/go.php?url=https://www.electropedia.org/

- платформа ИСО для онлайн-просмотра: доступна по адресу /template/go.php?url=https://www.iso.org/obp

3.1.1 интероперабельность (interoperability): Способность двух или более систем или приложений обмениваться информацией и взаимно использовать эту информацию.

[ИСО/МЭК 17788:2014, статья 3.1.5]

3.1.2 облачная интероперабельность (cloud interoperability): Способность системы потребителя службы облачных вычислений взаимодействовать со службой облачных вычислений или способность одной службы облачных вычислений взаимодействовать с другими службами облачных вычислений путем обмена информацией в соответствии с предписанным методом для получения предсказуемых результатов.

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

3.1.3 интероперабельность на уровне транспорта (transport interoperability): Вид интероперабельности (3.1.1), при которой обмен информацией использует установленную коммуникационную инфраструктуру между участвующими системами.

3.1.4 синтаксическая интероперабельность (syntactic interoperability): Вид интероперабельности (3.1.1), позволяющей участвующим системам понимать форматы обмениваемой информации.

3.1.5 интероперабельность на уровне семантики данных (semantic data interoperability): Вид интероперабельности (3.1.1), позволяющей участвующим системам понимать значение модели данных в контексте предметной области.

3.1.6 интероперабельность на уровне поведения (behavioural interoperability): Вид интероперабельности (3.1.1), при которой фактический результат обмена достигает ожидаемого результата.

3.1.7 интероперабельность на уровне политик (policy interoperability): Интероперабельность (3.1.1), при которой соблюдаются требования законодательства, регламентов организаций и политик, применимые к участвующим системам.

3.2.1 переносимость данных (data portability): Возможность легко передавать данные от одной системы к другой без необходимости повторно вводить данные.

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

[ИСО/МЭК 17788:2014, статья 3.2.21]

3.2.2 облачная переносимость данных (cloud data portability): Переносимость данных (3.2.1) от одной службы облачных вычислений в другую службу облачных вычислений или между системой потребителя службы облачных вычислений и службой облачных вычислений.

[ИСО/МЭК 17788:2014, статья 3.2.6 изменена с добавлением фразы: "или между системой потребителя службы облачных вычислений и службой облачных вычислений"]

3.2.3 синтаксическая переносимость данных (data syntactic portability): Переносимость данных (3.2.1) с использованием форматов данных, которые могут быть декодированы в целевой системе.

3.2.4 семантическая переносимость данных (data semantic portability): Переносимость данных (3.2.1), при которой целевая система понимает значение модели данных в контексте предметной области.

3.2.5 переносимость политики данных (data policy portability): Переносимость данных (3.2.1), при которой соблюдаются требования законодательства, регламентов организаций и политик, применимые и к исходной, и к целевой системам.

3.3.1 переносимость приложений (application portability): Возможность переноса приложения из исходной системы в целевую систему.

3.3.2 облачная переносимость приложений (cloud application portability): Возможность переноса приложения от одной службы облачных вычислений к другой службе облачных вычислений или между системой потребителя службы облачных вычислений и службой облачных вычислений.

[ИСО/МЭК 17788:2014, статья 3.2.2 изменена с добавлением фразы: "или между системой потребителя службы облачных вычислений и службой облачных вычислений"]

3.3.3 переносимость синтаксиса приложений (application syntactic portability): Переносимость приложений (3.3.1), при которой формат артефактов приложения может быть декодирован в целевой системе.

3.3.4 переносимость инструкций приложения (application instruction portability): Переносимость приложения (3.3.1), при которой набор инструкций приложения выполняется в целевой системе.

3.3.5 переносимость метаданных приложений (application metadata portability): Переносимость приложения (3.3.1), при которой метаданные приложения сохраняются и корректно обрабатываются в целевой системе.

3.3.6 переносимость поведения приложения (application behaviour portability): Переносимость приложения (3.3.1), при которой выполнение в целевой системе дает результаты, эквивалентные полученным в исходной системе.

3.3.7 переносимость политики приложения (application policy portability): Переносимость приложений (3.3.1), при которой соблюдаются требования законодательства, регламентов организаций и политик, применимые и к исходной, и к целевой системам.

В настоящем стандарте использованы следующие сокращения:

API - прикладной программный интерфейс;

ASCII - американский стандартный код для обмена информацией;

ASN.1 - абстрактная синтаксическая нотация 1;

BPEL - язык описания бизнес-процессов;

BPML - язык управления бизнес-процессами;

CRM - управление взаимоотношениями с клиентами

CSC - потребитель службы облачных вычислений;

CSN - партнер службы облачных вычислений;

CSP - поставщик службы облачных вычислений;

CSV - значения, разделенные запятыми;

ERP - планирование ресурсов предприятия;

ESB - корпоративная служебная шина;

HCM - управление людскими ресурсами;

HTTP - протокол передачи гипертекста;

IaaS - инфраструктура как услуга;

ИКТ - информационно-коммуникационная технология;

JSON - нотация объектов JavaScript;

MIME - многоцелевые расширения почты Интернета;

MQTT - передача телеметрии очереди сообщений;

OVF - открытый формат виртуализации;

OWL - язык веб-онтологии;

PaaS - платформа как услуга;

REST - передачи репрезентативного состояния;

SaaS - программное обеспечение как услуга;

SDK - комплект для разработки программного обеспечения;

SOAP - простой протокол доступа к объектам;

UML - унифицированный язык моделирования;

VPN - виртуальная частная сеть;

XML - расширяемый язык разметки;

АУД - аутентификация и управление доступом;

ВМ - виртуальная машина;

ПДн - персональные данные.

Настоящий раздел содержит обзор и модели (известные как "модели аспектов"; подробные сведения приведены в 5.2.1, 5.2.2 и 5.2.3) облачной интероперабельности, облачной переносимости данных и облачной переносимости приложений. Существуют различные точки зрения на интероперабельность и переносимость. Такие точки зрения называются "аспектами".

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

ИСО/МЭК 17788 определяет интероперабельность как "способность двух или более систем или приложений обмениваться информацией и использовать эту информацию". В контексте облачных вычислений интероперабельность далее описывается как сквозной аспект, обеспечивающий системе потребителя облачной службы возможность взаимодействовать и обмениваться информацией со службой облачных вычислений в соответствии с предписанным методом и получать предсказуемые результаты (см. ИСО/МЭК 17788:2014, подраздел 6.6). Кроме того, интероперабельность включает в себя способность одной службы облачных вычислений взаимодействовать с другими службами (см. ИСО/МЭК 17789:2014, пункт 8.5.5). Взаимодействие в облаке происходит между приложением потребителя службы облачных вычислений и службами облачных вычислений, а также между службами облачных вычислений, как приведено на рисунке 1. Также следует отметить, что в обоих случаях, как правило, задействованы несколько интерфейсов, что обозначено на рисунке наличием нескольких стрелок.

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

При рассмотрении вопросов облачной интероперабельности необходимо учитывать множество факторов, в том числе:

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

- способность службы облачных вычислений работать с другими службами облачных вычислений;

- свойства, необходимые для обеспечения успешного взаимодействия между средствами ИКТ организации и службой облачных вычислений;

- роли и деятельности, определенные в ИСО/МЭК 17789;

- типы облачных возможностей, определенные в ИСО/МЭК 17788;

- интерфейсы между различными функциональными компонентами, определенными в ИСО/МЭК 17789:2014, подраздел 9.2.

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

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

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

Следует иметь в виду, что переносимость в облачных вычислениях редко ограничивается выбором между "возможно" и "невозможно". Чаще всего переносимость "возможна, но с учетом затрат на перенос". Для определения целесообразности переноса приложений и/или данных требуется анализ затрат и выгод. Таким образом, сходство систем потребителя службы облачных вычислений и поставщика службы облачных вычислений в отношении аспектов, описанных в 5.2.2 и 5.2.3, заключается скорее в снижении стоимости переноса, чем в "обеспечении" переносимости, поскольку практически любая переносимость возможна, если клиент готов к ней и способен заплатить за нее. Вопросы переносимости не ограничиваются затратами; они также сопряжены с некоторыми рисками и обычно влекут за собой затраты сил и времени потребителя службы облачных вычислений, а также возможный перерыв в обслуживании.

При рассмотрении переносимости в облачных вычислениях необходимо учитывать множество факторов, которые включают в себя:

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

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

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

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

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

5.1.3.2 Облачная переносимость данных

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

К факторам, связанным с облачной переносимостью данных, относятся:

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

- синтаксис данных. В идеальном случае синтаксис данных в исходной и целевой службах совпадает. Однако, если синтаксис данных различен, например, исходная система использует синтаксис JSON, а целевая система использует XML, можно произвести преобразование данных с помощью общедоступных инструментов;

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

5.1.3.3 Облачная переносимость приложений

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

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

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

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

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

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

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

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

Переносимость - это возможность переноса данных или приложений от одной службы облачных вычислений к другой или между системой потребителя службы облачных вычислений и службой облачных вычислений. Степень эффективности и результативности миграции рассматривается как способность выполнять приложение или использовать данные с минимальным количеством ручных операций в процессе миграции или без таковых, как описано в ИСО/МЭК 17788. Основное внимание в переносимости уделяется простоте миграции данных и приложений. Служба облачных вычислений, поддерживающая переносимость, не обязательно является интероперабельной.

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

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

Модель аспектов интероперабельности, приведенная в настоящем стандарте, определяет пять аспектов в контексте облачной интероперабельности. Эти аспекты приведены на рисунке 4: транспорт, синтаксис и семантика данных, поведение и политика. Данная модель получена путем объединения и абстрагирования европейской модели интероперабельности [13] и уровней концептуальной модели интероперабельности (LCIM) [14].

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

Модель аспектов интероперабельности, приведенная в настоящем стандарте, определяет пять аспектов в контексте облачной интероперабельности. Эти аспекты приведены на рисунке 4: транспорт, синтаксис и семантика данных, поведение и политика. Данная модель получена путем объединения и абстрагирования европейской модели интероперабельности [13] и уровней концептуальной модели интероперабельности (LCIM) [14].

5.2.1.2 Интероперабельность на уровне транспорта

Интероперабельность на уровне транспорта означает общность инфраструктуры связи, созданной для обмена данными между системами. В контексте облачных вычислений интероперабельность на уровне транспорта - это механизм передачи данных между различными компонентами облачных вычислений, либо между компонентами потребителя службы облачных вычислений и компонентами поставщика службы облачных вычислений, либо между компонентами различных поставщиков служб облачных вычислений. Примеры включают в себя: HTTP/S, SOAP, протокол расширенной очереди сообщений (Advanced Message Queuing Protocol, AMQP) и транспорт очередей сообщений телеметрии (Message Queuing Telemetry Transport, MQTT).

5.2.1.3 Интероперабельность на уровне синтаксиса данных

Интероперабельность на уровне синтаксиса данных - это способность двух или более систем или служб понимать структуру информации, которой они обмениваются и которая представляет собой кодирование понятий прикладной области, определенных аспектом семантики данных. Примеры синтаксисов кодирования включают в себя: JSON, XML и синтаксисы, описанные средствами ASN.1.

5.2.1.4 Интероперабельность на уровне семантики данных

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

Интероперабельность на уровне семантики данных основана на моделях данных обмениваемой информации во время этого обмена. На уровне инфраструктуры это касается виртуальных машин (ВМ), контейнеров, хранилищ и сетей и управления ими. На уровне платформы это относится к приложениям, средам выполнения и развертывания и управления ими. На уровне приложений концепции прикладной области продиктованы самими приложениями, такими как управление человеческим капиталом (Human Capital Management, HCM), управление взаимоотношениями с клиентами (Customer Relationship Management, CRM), планирование ресурсов предприятия (Enterprise Resource Planning, ERP) и т.д.

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

5.2.1.5 Интероперабельность на уровне поведения

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

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

Интероперабельность на уровне поведения определяется следующими терминами:

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

b) определение ожидаемых результатов в описании службы облачных вычислений включает в себя:

1) предусловия, указанные поставщиком службы облачных вычислений, которые должны быть выполнены до выполнения операции;

2) постусловия, которые отражают состояние службы по завершении операции;

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

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

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

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

5.2.1.6 Интероперабельность на уровне политики

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

5.2.1.7 Проблемы, влияющие на облачную интероперабельность

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

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

В случае транспортного аспекта интероперабельности, если одна система взаимодействует по протоколу REST HTTP, а другая система взаимодействует по протоколу MQTT, интероперабельность на уровне транспорта может быть достигнута посредством адаптера протоколов между системами, такого как сервисная шина предприятия (Enterprise Service Bus, ESB).

Аналогично, если две системы различаются по синтаксическому аспекту интероперабельности, то они могут взаимодействовать посредством транслятора синтаксиса; примером может служить преобразование синтаксиса между данными, закодированными в XML, и данными, закодированными в JSON.

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

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

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

Интероперабельность на уровне политики может быть одной из самых сложных и трудных задач. Если существует юридический запрет для потребителя службы облачных вычислений на использование некоторой службы, например, по причине того, что служба работает в другой юрисдикции, то потребитель не может использовать эту службу облачных вычислений, даже если все остальные аспекты интероперабельности удовлетворены. Политика потребителя службы облачных вычислений в отношении размещения данных, например, конфиденциальных данных, также может быть существенным препятствием для интероперабельности на уровне политики (см. ИСО 9241-171:2008, подраздел 3.2). Кроме того, корпоративные политики потребителя службы облачных вычислений необходимо принимать во внимание, например, в тех случаях, когда требуются определенные возможности доступности. В некоторых случаях потребитель может вести переговоры с поставщиком службы облачных вычислений, чтобы изменить способ предоставления службы облачных вычислений на такой, который преодолевает проблемы регулирования или политики; например, публичная служба облачных вычислений может быть альтернативно предложена в качестве частной службы (с выделенными ресурсами для этого клиента), чтобы соответствовать политике безопасности клиента.

5.2.1.8 Краткое описание модели аспектов облачной интероперабельности

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

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

Настоящий стандарт определяет три аспекта переносимости данных в контексте облачных вычислений. Эти аспекты, называемые соответственно политикой данных, синтаксисом данных и семантикой данных, приведены на рисунке 5. Данная модель основана на модели облачной интероперабельности, описанной в 5.2.1, адаптированной к особенностям облачной переносимости данных.

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

5.2.2.2 Синтаксическая переносимость данных

Синтаксическая переносимость данных определяется как передача данных от исходной системы в целевую систему с использованием форматов данных, которые могут быть декодированы в целевой системе, с использованием определенного синтаксиса для кодирования данных, такого как XML, или инкапсуляции данных в формат упаковки, такой как Открытый формат виртуализации (Open Virtualization Format, OVF) [3] или Zip [8].

5.2.2.3 Семантическая переносимость данных

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

5.2.2.4 Переносимость политики данных

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

5.2.2.5 Проблемы, влияющие на облачную переносимость данных

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

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

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

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

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

Независимо от предметной области, особое внимание должно уделяться персональной информации. Например, согласно ссылке [16], субъект данных имеет право получать персональные данные в машиночитаемых, структурированных и широко используемых форматах. Персональные данные можно описать несколькими категориями. Информация об этих категориях данных содержится в ИСО/МЭК 19944. Кроме того, данные в любой категории могут предоставлять или способствовать получению информации, которая связана с физическим лицом, именуемой в настоящем стандарте персональными данными (ПДн). То, насколько отдельные лица непосредственно идентифицируются по данным, и насколько легко связать набор характеристик с данными конкретного лица, важно для отдельных лиц, потребителей службы облачных вычислений и лиц, принимающих решения, при оценке использования этой категории данных. Поэтому спецификация данных часто включает в себя не только тип этих данных, но также описание того, насколько данные могут идентифицировать человека (ИСО/МЭК 19944:2017, подраздел 8.3).

Стандарты, определяющие семантику некоторых элементов данных, могут помочь обеспечить переносимость семантики. Например, схема Dublin Core [1] представляет собой глоссарий, описывающий веб-ресурсы.

5.2.2.6 Краткое описание аспектов облачной переносимости данных

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

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

Настоящий стандарт определяет пять аспектов облачной переносимости приложений в контексте облачных вычислений. Эти аспекты приведены на рисунке 6: синтаксис приложения, инструкции приложения, метаданные приложения, поведение приложения и политики приложения. Модель аспектов облачной переносимости приложений основана на модели аспектов интероперабельности облачных приложений, описанной в 5.2.1, и адаптирована к особенностям облачной переносимости приложений.

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

5.2.3.2 Переносимость синтаксиса приложений

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

5.2.3.3 Переносимость инструкций приложения

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

5.2.3.4 Переносимость метаданных приложений

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

5.2.3.5 Переносимость поведения приложения

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

5.2.3.6 Переносимость политик приложения

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

5.2.3.7 Краткое описание модели аспектов облачной переносимости приложений

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

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

Для обеспечения интероперабельности необходимо применять к интерфейсам между системами потребителя службы облачных вычислений и службой облачных вычислений средства обеспечения безопасности, например, определенные в стандартах серии ИСО/МЭК 27000. Эти средства включают в себя защиту связи между системами потребителя службы облачных вычислений и службой облачных вычислений, что обычно достигается использованием различных видов шифрования. В состав средств обеспечения безопасности могут входить протоколы шифрования, такие как HTTPS или протокол безопасности транспортного уровня (Transport Layer Security, TLS), или может использоваться виртуальная частная сеть (Virtual Private Network, VPN) между системами потребителя службы облачных вычислений и службой облачных вычислений. Существует ряд стандартов в области безопасности, которые обеспечивают возможность интероперабельности с точки зрения безопасности.

Вторая проблема, связанная с интероперабельностью, касается идентификации и управления доступом, подробно описанными в 5.3.3.

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

- содержат ли данные персональные данные;

- если данные являются персональными, насколько они конфиденциальны;

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

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

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

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

Если необходимо шифрование, следует рассмотреть форму шифрования, например, соответствует ли шифрование требованиям стандарта, такого как федеральный стандарт обработки информации США (Federal Information Processing Standard, FIPS) 140-2 [17], а также механизмам, используемым для обработки ключей шифрования. Обработка ключей шифрования может включать в себя службы хранения ключей и использование аппаратных модулей шифрования. Кроме того, возможности шифрования различаются между системами потребителя службы облачных вычислений и облачной службой или между облачными службами, и эти различия должны учитываться в процессе переноса.

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

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

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

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

Службы облачных вычислений применяют систему аутентификации и управления доступом для управления доступом к интерфейсам, предлагаемым службой, а также для управления доступом к ресурсам внутри службы облачных вычислений. Система АУД должна знать всех, кто пользуется службой облачных вычислений (люди, группы, организации и объекты). Следует иметь в виду, что аутентификация применяются не только к людям, но также требуется для других идентифицируемых объектов, таких как группы, отделы, списки рассылки/безопасности, рабочие роли, команды, проекты, компании, дочерние предприятия, устройства, компьютерные домены, политики и т.д. Полный набор возможных идентифицированных сущностей, представленных в системе, и формат персональных данных могут варьироваться от одной службы облачных вычислений к другой.

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

Интероперабельность АУД поддерживается рядом стандартов, такими, как упрощенный протокол доступа к каталогу (Lightweight Directory Access Protocol, LDAP) [18], OAuth [19] OpenID Connect [20] и язык разметки безопасности (Security Assertion Markup Language, SAML) [21]; они могут помочь в удовлетворении ключевых требований интегрированного управления персональными данными и единого входа (Single Sign-On, SSO).

В тех случаях, когда система АУД изменяется при переносе в службу облачных вычислений, потребитель службы облачных вычислений должен предпринять необходимые меры для миграции персональных данных пользователей к/от выделенной системы АУД службы облачных вычислений. При переносе персональных данных пользователей идентификаторы, используемые для конкретных объектов, могут изменяться.

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

При рассмотрении переносимости данных и приложений необходимо помнить, что файлы данных не являются самостоятельными, даже если они полностью соответствуют формату документа. У них имеются связанные с ними метаданные, такие как права владения объектами, списки управления доступом (access control list, ACL), история аудита, история изменений и т.д. У некоторых файлов документов будет подробная информация о том, кто вносил и какие изменения, кто создавал и читал комментарии и т.д. Все эти функции зависят от цифровых идентификаторов, управляемых системой АУД. Метаданные файлов могут оказаться непереносимыми, даже если сами файлы являются переносимыми.

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

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

1) все цифровые идентификаторы из исходной системы воссоздаются в целевой системе с теми же значениями цифровых идентификаторов (что также означает, что обе системы должны использовать один и тот же формат цифровых идентификаторов);

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

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

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

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

Кроме того, стоит вопрос о влиянии измененных цифровых идентификаторов, подробно рассмотренный в 5.3.3.

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

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

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

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

Для служб облачных вычислений в целом существует сравнительно немного стандартов, применимых к этим интерфейсам, что может затруднить интероперабельность. Для транспортного и синтаксического аспектов интероперабельности интерфейсов служб облачных вычислений на практике обычно используют протоколы TCP/IP и HTTP и форматы JSON или XML, а также принципы REST, что позволяет обеспечить интероперабельность по этим аспектам относительно просто.

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

В случае служб облачных вычислений с типом возможностей платформы для интероперабельности интерфейсов также нет глобального соглашения о поведенческих и семантических аспектах интерфейса службы. Бывают случаи, где различные поставщики служб облачных вычислений используют одинаковое базовое программное обеспечение для своих служб облачных вычислений, и в этих случаях элементы API службы могут совпадать для исходной и целевой служб облачных вычислений, хотя это - небольшая часть рынка. Контейнерные технологии, такие как Open Container Initiative <1>, могут упростить миграцию приложений, упакованных в их формате, даже если детали API службы, используемые для их развертывания и управления, различаются.

--------------------------------

<1> /template/go.php?url=https://www.opencontainers.org/

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

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

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

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

Чтобы понять техническую осуществимость и стоимость интероперабельности и переносимости по отношению к службам облачных вычислений, полезно сгруппировать сценарии и варианты использования, чтобы их можно было рассмотреть совместно с достаточной детализацией. В настоящем разделе описана структура такого рассмотрения, в которой используются типы возможностей служб облачных вычислений, определенные в ИСО/МЭК 17788, а также архитектурные концепции, описанные в ИСО/МЭК 17789. В данном разделе описывается, как общее пространство интероперабельности и переносимости служб облачных вычислений можно подразделить на категории, имеющие общие свойства.

Полезно начать с набора диаграмм функциональных компонентов, основанных на рисунке 9-2 ИСО/МЭК 17789:2014, в которые добавлены элементы, необходимые для понимания облачной интероперабельности, облачной переносимости данных и облачной переносимости приложений. Функциональные компоненты, приведенные на рисунке 9-2 ИСО/МЭК 17789:2014, не включают в себя дополнительные компоненты, представленные в настоящем разделе, см. рисунки 7, 8 и 9.

Рисунки 7, 8 и 9 упрощены для облегчения понимания.

Многоуровневые функции сведены к одному высокоуровневому компоненту, расположенному с правой стороны.

Уровень ресурсов и уровень доступа упрощены, чтобы увеличить доступное пространство для других уровней.

Рисунки 7, 8 и 9 расширены - в них добавлены компоненты, полезные для понимания облачной интероперабельности, облачной переносимости данных и облачной переносимости приложений:

a) в верхней части рисунков 8 и 9 добавлен блок "Необлачные системы потребителя службы облачных вычислений". Он представляет системы потребителя службы облачных вычислений, которые содержат приложения и наборы данных потребителя службы облачных вычислений;

b) на рисунке 8 приложение потребителя показано в функциональном компоненте "Функция пользователя" пользовательского уровня. В соответствии с подпунктом 9.2.1.1 ИСО/МЭК 17789:2014 следует: "В некоторых случаях функциональный компонент "Функция пользователя" может быть таким же простым, как и браузер, работающий на персональном компьютере. Однако в других случаях он может включить в себя сложную корпоративную систему, управляющую бизнес-процессами, приложениями, промежуточным программным обеспечением и связанной инфраструктурой". Таким образом, функция пользователя может содержать приложение, которое потребитель службы облачных вычислений хочет перенести в службу облачных вычислений;

c) на рисунке 8 приложение потребителя находится в блоке "Необлачные системы потребителя службы облачных вычислений", представляя собой приложение, изначально работающее в системе потребителя, не связанное с какими-либо облачными вычислениями, которое потребитель службы облачных вычислений может перенести в службу облачных вычислений;

d) на рисунке 9 компонент данных потребителя добавлен как в блок "Необлачные системы потребителя службы облачных вычислений", так и в компонент "Функция пользователя", тем самым представляя один или несколько наборов данных, которые потребитель службы облачных вычислений может перенести в службу облачных вычислений;

e) на рисунках 8 и 9 компонент "Возможности служб" на уровне служб расширен, чтобы предоставить пространство двум добавленным в него компонентам:

1) компонент приложения потребителя, представляющий приложение потребителя, перенесенное для запуска в службе облачных вычислений;

2) компонент данных потребителя, который представляет один или несколько наборов данных потребителя, перенесенных для размещения в службе облачных вычислений;

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

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

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

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

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

На рисунке 10 показан один потребитель службы облачных вычислений, взаимодействующий с двумя службами облачных вычислений: службой облачных вычислений 1 (слева) и службой облачных вычислений 2 (справа). Служба облачных вычислений 1 рассматривается как исходная служба, а служба облачных вычислений 2 - как целевая служба для переноса приложений и данных. Следует обратить внимание на то, что на рисунке 10 дополнительно упрощены уровень доступа и уровень службы для двух служб облачных вычислений, чтобы избежать загромождения рисунка компонентами, не относящимися к интероперабельности и переносимости.

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

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

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

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

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

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

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

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

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

a) явный API, являющийся частью интерфейса облачной службы;

b) API, который является частью интерфейса администрирования службы облачных вычислений;

c) поддержку службой облачных вычислений стандартного API передачи данных, такого как FTP или SFTP:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Зависимости типов облачной интероперабельности от типов облачных возможностей и типов интерфейсов, определенных в ИСО/МЭК 17789, приведены в таблице 4. В каждой ячейке таблицы на пересечении строк и столбцов приведена ссылка на пункт (подпункт), который описывает соображения для данного типа облачной интероперабельности.

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

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

Функциональные компоненты, имеющие отношение к интероперабельности служб облачных вычислений, приведены на рисунках 7, 8, 9 и 10. Взаимодействие осуществляется через три интерфейса между компонентами потребителя службы облачных вычислений и компонентами поставщика службы облачных вычислений:

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

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

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

Как указано в 6.2, понятия интероперабельности применяются отдельно к каждому из этих трех интерфейсов. Для большинства служб облачных вычислений три интерфейса почти наверняка используют разные API, возможно, с использованием разных транспортных протоколов, разных синтаксиса и семантики данных. Ключевая концепция заключается в том, что для достижения полной интероперабельности все действия подролей потребителя службы облачных вычислений, поддерживаемых компонентами "Функция пользователя", "Функция администрирования" и "Деловая функция", должны поддерживаться интерфейсом, который использует каждый компонент для взаимодействия со службой облачных вычислений, как приведено в ИСО/МЭК 17789:2014, пункт 9.2.2. Функциональные компоненты включают в себя:

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

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

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

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

Как правило, любые две не взаимодействующие между собой службы можно подключить друг к другу и заставить их работать вместе, но это зачастую может включать в себя дорогостоящие и трудоемкие одноразовые процедуры. Цель интероперабельности, с другой стороны, заключается в том, чтобы заставить две или несколько произвольных служб работать вместе. Для достижения этого необходимо определить точки взаимодействия, предоставляемые рассматриваемыми службами, например, через API, вызовы методов для удаленных объектов, запросы REST и т.д., и между которыми могут быть успешно выполнены определенные действия. Для того, чтобы служба облачных вычислений считалась интероперабельной, необходимо поддерживать необходимые действия всех необходимых подролей потребителя службы облачных вычислений (как приведено в ИСО/МЭК 17789:2014, пункт 8.2.2).

Практический подход к интероперабельности задействует потребителя службы облачных вычислений, который определяет деятельности, необходимые для поддержки каждой требуемой подроли потребителя службы облачных вычислений (ИСО/МЭК 17789:2014, рисунок 8-3), и рассматривает, какие функциональные компоненты используются для их поддержки, а также для поддержки функции пользователя, деловой функции и функции администратора, приведенных в ИСО/МЭК 17789:2014, рисунок 9-2.

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

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

Интероперабельность относится к приложениям потребителя службы облачных вычислений, которые реализуют каждую из пользовательских функций и функций администратора на пользовательском уровне, как описано в ИСО/МЭК 17789:2014, пункт 9.2.1, и к тому, как каждое из них взаимодействует с соответствующими интерфейсами, предлагаемыми уровнем доступом службы облачных вычислений.

Интероперабельность служб облачных вычислений также относится к функциональным компонентам, связанным с партнерами службы облачных вычислений, в частности к роли разработчика служб облачных вычислений. Как приведено на рисунке 11, компонент "Окружение разработчика" взаимодействует с компонентом "Доступ разработки" с использованием интерфейса(ов) разработки, предлагаемого(ых) компонентом доступа разработки. Подроль CSN:разработчик службы облачных вычислений выполняет различные виды деятельности, в том числе разработку, тестирование и сопровождение внедрения облачных служб.

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

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

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

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

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

Для упрощения кодирования и последующей передачи данных между системами были определены множество конкретных синтаксисов. Примерами могут служить XML, JSON и ASN.1. Выбор кодировки синтаксиса зависит от возможностей службы облачных вычислений; интерфейсы службы, деловой интерфейс и интерфейс администрирования могут использовать различные кодировки.

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

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

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

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

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

a) внутреннего поведения, которое включает в себя:

1) надлежащее использование в соответствии с описанием поставщика службы облачных вычислений;

2) инварианты, которые поддерживаются службами во время функционирования;

b) внешнего поведения, к которому относятся:

1) ожидаемые результаты, в соответствии с пониманием потребителя службы облачных вычислений и поставщика службы облачных вычислений;

2) предусловия, которые должны быть выполнены до операции;

3) постусловия, отражающие состояние службы после завершения операции;

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

5) ответ на операции управления.

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

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

Интероперабельность на уровне поведения может использовать формальные аннотации уровня кода, такие как пред- и постусловия, инварианты, утверждения (assertions) и вехи (milestones). Они позволяют выразить желаемое поведение.

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

7.1.5.3 Интероперабельность на уровне поведения для служб облачных вычислений с типом возможностей платформы

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

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

7.1.5.4 Интероперабельность на уровне поведения для служб облачных вычислений с типом возможностей приложения

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

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

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

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

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

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

Интероперабельность на уровне политики включает в себя регламенты или политики, которые касаются определенных возможностей служб облачных вычислений. Одним из главных факторов, вызывающих озабоченность, является безопасность. Существуют конкретные требования безопасности, основанные на характере данных и обработки; например, когда речь идет об информации о кредитных картах, может потребоваться, чтобы служба облачных вычислений соответствовала требованиям стандарта безопасности данных индустрии платежных карт (PCI-DSS) [22]. Могут предъявляться более общие требования безопасности в соответствии с политиками потребителя службы облачных вычислений, такие как требование сертификации службы облачных вычислений на соответствие стандартам, например, ИСО/МЭК 27001 и ИСО/МЭК 27017.

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

Примерами подключенных устройств являются мобильные устройства, такие как смартфоны и планшеты, и устройства интернета вещей (IoT).

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

Пользователи могут ожидать, что данные потребителей службы облачных вычислений будут доступны при переходе от одного устройства к другому, независимого от платформы устройства и соответствующего рынка приложений (см. ИСО/МЭК 19944). Это означает, что необходима интероперабельность между приложениями подключенного устройства и службами облачных вычислений, содержащими данные потребителей служб облачных вычислений.

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

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

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

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

Синтаксическая переносимость данных связана с форматом и кодированием данных в подходящие артефакты данных, которые могут быть переданы и декодированы другой системой, такой как служба облачных вычислений или система потребителя службы облачных вычислений. Чтобы быть переносимым, каждый артефакт должен быть закодирован с использованием такого формата обмена, который может быть декодирован целевой системой, что может потребовать преобразование форматов. Обычно артефакт помечается типом кодировки, который может быть указан расширением файла или типом MIME. Примерами являются файлы документов офисных приложений, изображения и фотографии, значения, разделенные запятыми (Comma separated values, CSV), и XML-файлы. Артефакт данных может содержать другие артефакты данных, закодированные в том же или ином формате. Примеры: zip-файл, содержащий другие артефакты данных, и иерархическая файловая система, содержащая каталоги артефактов данных.

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

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

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

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

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

Артефакты данных связаны с образами виртуальных машин, файловыми хранилищами, хранилищами медиа, базами данных и т.д. Единые форматы упаковки особенно полезны для переносимости данных инфраструктуры. Примерами могут служить открытый формат виртуализации (Open Virtualisation Format, OVF), Zip и tar. Конкретный формат упакованных объектов данных несущественен для службы облачных вычислений с типом возможностей инфраструктуры. Например, для того чтобы файл или объект данных можно было сохранить в инфраструктуре хранения в службе облачных вычислений, нет необходимости службе облачных вычислений знать что-либо о синтаксисе и формате данных файла или объекта данных. Вполне возможно, что содержимое такого файла доступно только компонентам приложения, принадлежащим потребителю службы облачных вычислений.

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

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

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

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

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

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

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

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

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

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

В отличие от артефактов данных инфраструктуры и платформы, форматы данных приложения не обязательно представлены посредством общепринятых форматов, таких как типы MIME, например. Даже если используется общий формат, могут быть определены дополнительные синтаксические правила, структурные и грамматические, которые дополнительно уточняют структуру содержимого артефакта данных. Специфичные для приложения форматы данных обычно выражаются посредством формата обмена данными, определенного на языках, которые предоставляют больше возможностей по структуризации, таких как схемы XML, Schematron (см. ИСО/МЭК 19757-3) и UML. Для того чтобы артефакты данных имели смысл при переносе данных между системой потребителя службы облачных вычислений и облачной службой, а также между службами облачных вычислений, необходима взаимная поддержка форматов обмена данными конкретными приложениями.

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

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

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

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

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

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

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

Для служб облачных вычислений с типом возможностей платформы модели данных относятся к приложениям, предназначенным для установки. Это включает в себя артефакты, связанные с кодом приложения, либо с исходным кодом, либо скомпилированными исполняемыми файлами и метаданными для сборки артефактов для выполнения. Также присутствуют данные потребителей служб облачных вычислений в хранилищах данных, таких как базы данных или файловые системы и хранилища объектов.

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

Для артефактов кода приложения семантические соображения рассматриваются в рамках облачной переносимости приложений для платформ в 9.4.

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

Понятия, терминология и отношения между понятиями совершенно необходимы для понимания модели предметной области и любых различий между приложениями, как необлачных, так и облачных служб. Если семантический перенос данных производится между приложениями, то требуется, чтобы приложения одинаково понимали модели предметной области. Документировать общее понимание можно посредством семантических языков, таких как OWL и Структуры описания ресурсов (Resource Description Framework, RDF), и нотаций моделирования, таких как UML и Язык управления бизнес-процессами (Business Process Management Language, BPML). Инструменты моделирования, поддерживающие такие нотации, как UML и BPML, как правило, определяют форматы обмена, которые могут использоваться на синтаксическом уровне переносимости данных. Помимо этого, различные специализированные области, например, науки о жизни, определили языки для выражения моделей предметной области <1>.

--------------------------------

<1> /template/go.php?url=https://www.w3.org/wiki/SemanticWebForLifeSciences

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

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

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

Производные данные службы облачных вычислений - это класс объектов данных, управляемых поставщиком службы облачных вычислений, которые получены потребителем службы облачных вычислений в результате взаимодействия со службой облачных вычислений (см. ИСО/МЭК 17788). Пример производных данных службы облачных вычислений: журналы взаимодействия пользователей со службой облачных вычислений.

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

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

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

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

Упомянутые выше внутренние данные ссылаются на данные, тесно связанные с программным/бинарным кодом в соответствии с проектом программного обеспечения. Примером таких внутренних данных могут служить данные конфигурации или настроек. Они отличаются от внешних данных, таких как например, файл фотографий в формате Совместной экспертной группы по фотографии (Joint Photographic Experts Group, JPEG), который открывает приложение-редактор фотографий для редактирования, что рассматривается как внешние данные, в то время как настройки технологического процесса для того же приложения были бы внутренними данными.

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

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

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

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

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

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

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

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

Модель для необлачных приложений, которые должны быть перенесены в среду облачных вычислений (см. рисунок 13), приведена в разделе 6. Следует сравнить данную модель с моделью, приведенной на рисунке 14 для типа возможностей инфраструктуры.

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

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

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

9.3.1.2 Переносимость синтаксиса приложений

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

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

9.3.1.3 Переносимость инструкций приложений

Переносимость инструкций приложения в определенной степени зависит от характера артефактов приложения и целевой среды выполнения. Например, приложения, созданные посредством интерпретирующих языков или использующих машинно-независимый байткод, таких как Node.js, Python, Java или C#, как правило, переносятся без изменений при условии, что целевая служба облачных вычислений поддерживает необходимую среду выполнения. Следует отметить, что в случае типа возможностей инфраструктуры вместе с артефактами инструкций приложения, как правило, переносится также сама среда выполнения.

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

9.3.1.4 Переносимость метаданных приложений

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

9.3.1.5 Переносимость поведения приложений

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

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

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

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

9.3.1.6 Переносимость политик приложений

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

- местоположение обработки.

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

- обработка третьими лицами.

Организация, обрабатывающая данные после переноса, может отличаться от исходного пользователя или оператора приложения;

- юрисдикция.

Юрисдикция, в которой работает приложение, может измениться;

- контракт.

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

Кроме того, см. 9.6.

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

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

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

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

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

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

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

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

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

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

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

Переносимость инструкций приложения аналогична случаю для необлачных приложений. См. 9.3.1.3.

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

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

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

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

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

Данный тип переносимости описан в 9.6.

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

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

Главная особенность служб облачных вычислений с типом возможностей платформы (таких, как PaaS) заключается в том, что они предоставляют среду для разработки, развертывания и эксплуатации приложений. К таким службам обычно относится предоставление разнообразной функциональности инфраструктуры прикладного программного обеспечения (так называемое "промежуточное программное обеспечение", middleware). Оно может включать в себя среду времени выполнения приложения, в том числе стек программного обеспечения, необходимый для выполнения кода приложения. Оно может также включать в себя предоставление существенных наборов сервисов, которые могут использоваться кодом приложения; сокращение объема кода, который должен быть написан, развернут и управляем заказчиком для достижения определенных бизнес-целей. Такие сервисы могут охватывать практически любые возможности; распространенными примерами являются системы баз данных, брокеры интеграции приложений, системы управления бизнес-процессами, механизмы правил и механизмы аналитики.

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

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

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

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

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

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

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

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

9.4.1.2 Переносимость синтаксиса приложений

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

Например, приложение заказчика может быть веб-приложением Node.js; как правило, целевая служба облачных вычислений поддерживает этот язык и тем самым принимает артефакты приложения, такие как файлы JavaScript, непосредственно без изменений.

9.4.1.3 Переносимость инструкций приложения

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

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

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

9.4.1.4 Переносимость метаданных приложения

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

9.4.1.5 Переносимость поведения приложения

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

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

9.4.1.6 Переносимость политик приложений

Описание переносимости политик приложений приведено в 9.6.

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

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

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

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

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

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

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

Это особенно актуально, если учитывать, что многие поставщики служб облачных вычислений предлагают похожие облачные службы с типом возможностей платформы, но при этом доступ к таким службам осуществляется через различные REST API и SDK. Абстрагирование внутренней логики приложения, которая получает доступ к компонентам со штриховой границей на рисунке 15, упростит адаптацию к функциональности другого SDK. Для этого требуется, чтобы было разделение между логикой приложения и нижележащими сервисами служб облачных вычислений (показанных как блоки со штриховой границей на рисунках 8 и 9). В идеальном случае логика приложения, используя уровни абстракции, не должна зависеть от того, на какой платформе служб облачных вычислений оно выполняется.

Типичными примерами распространенных шаблонов проектирования, реализующих подобные абстракции, служат:

- блоб, реляционное или NoSQL хранилище;

- управление кэшем;

- балансировка нагрузки;

- очереди обмена сообщениями между компонентами;

- аутентификация и управление доступом.

Другим сценарием переносимости является обращение приложения к службам, которые предоставляются поставщиком служб облачных вычислений посредством межоблачных механизмов взаимодействия посредничества, агрегации, федерации или арбитража (см. ИСО/МЭК 17789). Переносимость таких приложений зависит от наличия межоблачных механизмов после переноса приложения в целевую службу облачных вычислений, в противном случае затраты, усилия и риск переноса приложения возрастают из-за необходимости адаптации к использованию других служб.

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

9.4.2.2 Переносимость синтаксиса приложений

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

9.4.2.3 Переносимость инструкций приложений

См. 9.4.1.3.

9.4.2.4 Переносимость метаданных приложений

См. 9.4.1.4.

9.4.2.5 Переносимость поведения приложений

См. 9.4.1.5.

9.4.2.6 Переносимость политик приложений

Этот тип переносимости описан в 9.6.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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