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

Термин «многооблачность»

Этот термин появился год или два назад в связи с тем, что многие организации уже использовали одно или несколько приложений в форме «ПО как сервис» (SaaS) для HR или электронной почты, платформу как сервис (PaaS) для разработки приложений и по крайней мере одну «инфраструктуру как сервис» (IaaS) для осуществления некоторых операций на виртуальных машинах.

«Клиенты все чаще используют несколько публичных облаков, поскольку некоторые облачные провайдеры в известной степени специализируются на определенных видах задач», — говорит Мэтью Чунг, директор по исследованиям Gartner Technology and Service Provider Research. Это может быть специализация на важнейших корпоративных приложениях, таких как SQL Server в случае с Microsoft Azure, или на подключении искусственного интеллекта и сервисов анализа данных в случае с Google Cloud. Облако Amazon Web Services (AWS) обладает множеством уникальных функций и сервисов и ежегодно добавляет сотни новых.

Отбор компонентов облака

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

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

Развенчание мифа о многооблачности

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

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

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

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

Обходные пути для переноса между облаками

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

«Предоставляющим сервис PaaS, собственно, совершенно нет дела до IaaS, — говорит Чунг. — Можно провести такую аналогию: не потребуется больших усилий, чтобы поднять дом целиком и перенести его в другое место при условии, что там имеется вся необходимая инфраструктура».

Примером является платформа приложений Red Hat OpenShift, которая позволяет создавать и развертывать приложения с помощью контейнеров Docker на собственной площадке предприятия, а также в облаках Microsoft Azure, AWS и Google Cloud. Теоретически возможен перенос кода приложения между всеми этими платформами.

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

Перспективы бессерверных вычислений

Помимо PaaS организации могут обратиться к бессерверным вычислениям. Это новая тенденция. Приложения создаются вокруг специфических функций. Оплачивается использование этих функций. Отсюда другое название — «функции как сервис». Примером служит Amazon AWS Lambda.

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

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

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

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

Управление многооблачностью

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

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

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

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