ГОСТ Р ИСО/МЭК 19941-2021. Национальный стандарт Российской Федерации. Информационные технологии. Облачные вычисления. Интероперабельность и переносимость
9.3 Переносимость приложений для служб облачных вычислений с типом возможностей инфраструктуры
9.3.1 Переносимость необлачных приложений в службы облачных вычислений
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 Переносимость приложений между службами облачных вычислений
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.