Мультиклауд: проблемы и перспективы

15.05.2020

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

Управление и учет
 
Несмотря на все преимущества мультиоблака, его использование сопряжено с целым рядом сложностей, которые важно учитывать (см. рисунок).
 
 
Даже при работе с одним облаком вести учет потребляемых ресурсов непросто, особенно на крупных предприятиях. Легко развернуть новые экземпляры виртуальных машин (инстансы), труднее понять, какие сервисы уже не нужны, и проконтролировать их отключение. Да и посчитать затраты на тысячи развернутых инстансов непросто, а с переходом к мультиоблакам задача усложняется еще больше.
 
Бесконтрольное использование облаков сильно сказывается на бюджете, и бизнес ограничивает его за счет бюрократических процедур. Но долгие согласования с контролирующими подразделениями и службами информационной безопасности сводят на нет одно из основных преимуществ облачных решений – быстроту предоставления инфраструктуры. 
 
Поэтому нужны автоматизированные системы для управления ресурсами в мультиоблаке. Попытки создания таких систем уже предпринимаются. Например, в мультиклаудном решении Cloud IQ компании Crayon единый биллинг и единая система управления позволяют заказчикам, работающим с несколькими видами облаков, получать всю информацию о подписках, их продлевать и расширять. Через единый интерфейс можно смотреть статистику, получать рекомендации о переносе тех или иных нагрузок между облаками, контролировать расход средств. Правда, пока такая система формируется для каждого конкретного заказчика и объединяет, к примеру, облака AWS и «Яндекса».
 
 
Пользоваться мультиоблаком удобно, если есть единый биллинг и общая панель управления. Это самые очевидные ценности, которые агрегатор может предложить клиентам. Но создание единой панели и биллинга потребует существенных инвестиций. Вернуть их получится либо за счет повышения цен, либо благодаря большим объемам оказываемых услуг. Однако заметная разница между расценками агрегатора и провайдеров, скорее всего, отпугнет часть потенциальных клиентов. А пока услуга остается нишевой, не приходится рассчитывать и на быстрое масштабирование бизнеса. Но даже если агрегатор сможет предложить единый биллинг и управление и сохранить конкурентные цены, это не гарантирует ему успеха. Потому что в такой системе есть единая точка отказа, и в случае проблем на стороне агрегатора клиенты не смогут управлять всеми частями своего мультиоблака. Подобные риски неприемлемы, например, при реализации катастрофоустойчивых сценариев.
 
Сергей Пимков, заместитель генерального директора, Selectel
 
Технические сложности
 
Приложения для мультиоблачных сред предъявляют повышенные требования к разработчикам. «Чтобы заниматься дизайном или редизайном приложений для работы в мультиоблачной среде, архитекторы и специалисты по DevOps должны владеть современным инструментарием разработки, тестирования и развертывания приложений, иметь новые архитектурные навыки, например, построения микросервисных архитектур», – предупреждает руководитель группы архитекторов по решениям Red Hat Владимир Карагиоз. 
 
Провайдеры публичных платформ ограничивают возможность построения доверительных отношений между платформами и зачастую не позволяют осуществить прозрачную интеграцию, например, с сохранением сетевой адресации. Технически сложной задачей является и прозрачная миграция виртуальных машин между различными системами виртуализации. 
 
У облачных провайдеров не хватает открытых API для управления их сервисами. На отечественном рынке такие API есть, но их мало. «Задача заключается в том, чтобы с этими сервисами состыковаться. Фактически каждому клиенту необходимо разработать свою интеграционную систему, но это и дорого, и сложно. ИТ-службы клиентов не будут самостоятельно изготавливать софт, а рынка подобных интегрирующих систем в РФ точно нет», – подчеркивает генеральный директор «Облакотеки» Максим Захаренко.
 
 
Контейнеры, в том числе под управлением Kubernetes, позволят сделать мультиклауд единым, поскольку поддерживают единый формат, де-факто стандартный для всех современных микросервисных приложений. Существуют решения, которые упрощают развертывание микросервисных приложений в мультиклауде. Однако проблема совместимости виртуальных машин на базе Hyper-V, VMware, KVM останется актуальной. Так что ключом к развитию мультиклауда будет возможность мигрировать из одного облака в другое, мобильность клиента без привязки к вендору. 
 
Илья Летунов, руководитель платформы, Mail.ru Cloud Solutions
 
Микросервисная архитектура рассматривается экспертами как фундамент мультиклауда, контейнеры – как основной инструмент управления. Следующий шаг – создание прямых CDN-сетей между облачными провайдерами.
 
Сейчас эта задача решается через сторонние компании – телеком-операторов. Например, «Ростелеком» может создать отдельный выделенный канал между облаками «Яндекса» и Mail.ru, но в идеале, как отмечает архитектор облачных решений компании Crayon Андрей Дубровин, нужно, чтобы между этими двумя провайдерами был их собственный канал. Это поможет избежать дополнительной финансовой нагрузки, которая в случае участия телеком-оператора ложится на плечи конечного потребителя. Кроме того, посредник снижает уровень безопасности мультиклауда, поскольку становится единой точкой отказа.
 
С увеличением числа облаков возрастают сложности в реализации политик безопасности, принятых в организации. Один из вариантов решения проблемы – создание отдельного слоя, транслирующего политики предприятия в подключаемые облака. Примером может служить Cisco Cloud ACI – комплексное решение для автоматического подключения к сети, согласованного управления политиками и упрощенных операций для сред с несколькими облаками.

Перенос данных
 
Узким местом при использовании мультиоблака является перенос между разными облаками больших объемов данных. Выходом из положения здесь может стать хранение массивов информации в отдельном частном или публичном облаке с возможностью переброски вычислительной нагрузки между сторонними облаками.
 
Например, с помощью технологий NetApp Data Fabric немецкий сервис-провайдер DARZ предлагает клиентам возможность практически мгновенного переноса рабочих нагрузок между облаками разных гиперскейлеров, в том числе AWS, Microsoft Azure, IBM Bluemix/Softlayer.
 
Используя свое конкурентное преимущество – доминирование на рынке СУБД, корпорация Oracle смогла заключить партнерское соглашение с компанией Microsoft, направленное на обеспечение совместимости облачных сред. В результате заказчики получат возможность перемещать критически важные рабочие нагрузки между Microsoft Azure и Oracle Cloud. Предприятия смогут беспрепятственно подключать облачные сервисы Azure, такие как Analytics и AI, к облачным сервисам Oracle Cloud, включая автономную базу данных Autonomous Database, и выполнять одну часть рабочей нагрузки в Azure, а другую часть той же рабочей нагрузки – в облаке Oracle Cloud. Таким образом, клиенту, хранящему данные в БД Oracle on-premise или в Oracle Cloud, при использовании сервисов Microsoft Azure не придется перебрасывать данные в облако Microsoft.
 
Провайдеры против клиентов
 
Клиенты заинтересованы в легкой смене используемых облачных сервисов. Но это противоречит интересам провайдеров, которые хотят привязать клиента к себе. Когда у одного из лидеров рынка появляется новый сервис, другие стараются повторить услугу в своем облаке, чтобы у клиентов не возникало соблазна перейти к конкуренту. У поставщиков облачных услуг не видно стимулов к созданию среды, в которой клиенту будет легко уйти  от их сервисов и сформировать собственное мультиоблако.
 
Зато облачному провайдеру есть смысл вступить в альянс с партнером, расширяющим клиентскую базу за счет предложения новых услуг. Примером служат партнерские отношения между лидерами рынка публичных облаков и по-прежнему занимающей ведущие позиции на рынке частных облаков VMware. Компания не рассматривается как конкурент – своих публичных облаков у VMware нет. Зато уже существуют гибридные облака VMware c Oracle, Azure, Google Cloud и AWS. 
 
В качестве третьей стороны, объединяющей облака, пытается выступать Veeam Software, перебрасывающая образы виртуальных машин на платформы гиперскейлеров AWS, Microsoft Azure и IBM Cloud. В качестве объединяющего узла можно рассматривать и клауд-брокеров – посредников между несколькими провайдерами и заказчиком, которые берут на себя функцию поиска и предоставления наиболее выгодного облачного сервиса.
 

 Для того чтобы в России появился устойчивый локальный рынок решений для мультиоблака, либо должно заметно усилиться присутствие гиперскейлеров (AWS, Azure, Google Cloud) в сегментах средних и крупных предприятий, либо возникнуть устойчивые и сравнимые по зрелости и функциональному охвату экосистемы сугубо российских провайдеров.

Артем Гениев, архитектор бизнес-решений, VMware в России и СНГ
 
А вот сами гиперскейлеры идут на объединение неохотно, разве что под давлением очень крупного заказчика. Возможно, что победа Microsoft в облачном тендере Пентагона на $10 млрд неслучайно совпала с заключением партнерства с Oracle. Практика покажет, как гиганты смогут согласовать свои стандарты и прямо конкурирующие сервисы, например, Azure Machine Learning и In-Database Machine Learning от Oracle.
 
«Общие проблемы – отсутствие стандартов в процессах и технологиях оказания облачных услуг. Например, нет типовых API для заказа услуг у провайдеров. Провайдерам это не нужно. Возможно, появление государственного облачного брокера начнет менять рынок, но я смотрю на это скептически», – говорит директор практики облачных решений AT Consulting Михаил Бараблин.
 
Перспективы в России
 
Простейший мультиклауд (мультиклауд 1.0) с несколькими не связанными между собой облаками широко используется в России. Хостинг веб-сайта в одном облаке, бизнес-приложение в другом, отправка отчетности в третьем… Но мультиклауд в современном понимании, с глубокой интеграцией облаков – дело будущего. «Мультиклаудная модель массовой в ближайшее время не станет, основная часть российских компаний делает только первые шаги в освоении облаков», – считает и директор по развитию бизнеса «Яндекс.Облако» Олег Коверзнев. 
 
Количество российских компаний, задействующих мультикладную модель, будет расти в сегментах наиболее активных пользователей облачных платформ – в ИТ, ритейле и финансовом секторе. Скажется и давление регуляторов, заставляющих все большее количество сервисов и данных переносить на территорию России и тем самым использовать и западные, и отечественные облака, а также облака с повышенными требованиями к безопасности. При этом перенос сервисов в российские облака ограничит применение передовых мультиклаудных технологий зарубежных гиперскейлеров, в которых отечественные провайдеры пока отстают. 
 
Взгляд в будущее
 
Продолжая сравнение облачных вычислений с электричеством, отметим, что полной стандартизации энергоснабжения не произошло. В одних странах напряжение 127 В, в других – 220 В. Туристам приходится искать переходники для различающихся электрических розеток, ЦОДам – очищать магистральное электричество от паразитных частот. 
 
 
Мы хорошо понимаем, что мульти­клаудная модель – наиболее перспективный путь применения облачных сервисов в бизнесе.

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