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

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

9.4.1 Переносимость необлачных приложений в службы облачных вычислений

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

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

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

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

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

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

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

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

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

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

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

 

Таблица 12

 

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

при переносе необлачных и облачных приложений, а также

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

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

 

Аспекты переносимости приложений	Примеры соображений при переносе приложений в службу облачных вычислений с типом возможностей платформы
	Из необлачной среды в службу облачных вычислений	Из службы облачных вычислений в службу облачных вычислений
Синтаксический аспект	См. 9.4.1.2	См. 9.4.2.2
Инструкции приложений	a) Определение и область применения стека приложения; 1) у необлачных приложений может быть длинная и потенциально мало документированная история в организации. Установление границ приложения и его составных частей может оказаться сложным b) Управление стеком приложения: 1) поскольку служба облачных вычислений предоставляет различные базовые сервисы, их архитектура и возможности фиксированы. Это, вероятно, потребует перепроектирование тех частей приложения, которое использует такие сервисы. c) Сервисы приложения. d) Вспомогательные сервисы приложения. e) Возможности разработки и тестирования: 1) эти возможности обычно соответствуют целевой службе облачных вычислений и могут значительно отличаться от эквивалентных возможностей в исходной среде, что потребует адаптации процессов разработки и тестирования.	a) Определение и область применения стека приложения: 1) может варьироваться в широких пределах в зависимости от исходного типа возможностей приложения. b) Управление стеком приложения. c) Сервисы приложения: 1) там, где это возможно, необходимо использовать существующие сервисы облачной платформы для уменьшения количества переносимого кода, что потенциально может принести деловые и технические преимущества. d) Вспомогательные сервисы приложения: 1) необходимо обеспечить перенос всех вспомогательных сервисов приложения в целевую службу облачных вычислений; 2) может потребоваться изменить общую границу приложения, чтобы включить в перенос другие вспомогательные сервисы. Кроме того, они могут быть заменены облачными сервисами, которые предлагаются в новой среде. Также возможно оставить эти службы на прежнем месте и вызывать их по мере необходимости из новой среды.
	f) Поддержка набора инструкций приложения: 1) это может являться важным фактором в зависимости от объема исходного кода, который нужно перенести, и поддержки конкретного языка или спецификации инструкций	e) Сервисы разработки и тестирования: 1) эти возможности соответствуют целевой службе облачных вычислений и могут значительно отличаться от эквивалентных возможностей в исходной среде, что потребует адаптации процессов разработки и тестирования; 2) тестирование в случае типа возможностей платформы отличается от случая типа возможностей инфраструктуры, где оно зачастую в значительной степени опирается на экземпляры виртуальных машин; 3) процесс разработки, в том числе упаковку и развертывание, будет отличаться для типа возможностей платформы. f) Поддержка набора инструкций приложения: 1) могут потребоваться трансляция или переработка кода в случае, если язык и версия не поддерживаются в новом окружении
Метаданные приложений	См. 9.4.1.4	См. 9.4.2.4
Поведение приложений	a) Тестовые сценарии ввода/вывода приложения. b) Технические тесты приложения: 1) производительность, защищенность и другие технические аспекты могут быть измерены и сравнены. c) Потоки бизнес-процессов: 1) дополнительные улучшения с точки зрения бизнеса, предоставляемые облачной платформой (наряду с другими причинами для переноса), могут быть измерены; 2) поскольку перенос в службу облачных вычислений с типом возможностей платформы зачастую определяется не столько техническими соображениями, сколько потребностями бизнеса, весьма вероятно, что бизнес пожелает внести изменения в общие бизнес-процессы, окружающие приложение. Таким образом, перенос подобного приложения может сопровождаться проектом по значительному изменению менеджмента
Политики приложений	См. 9.6

 

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 Переносимость приложений из одной службы облачных вычислений в другую службу облачных вычислений

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.