Мультиклауд: проблемы и перспективы
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 В. Туристам приходится искать переходники для различающихся электрических розеток, ЦОДам – очищать магистральное электричество от паразитных частот.
 Мы хорошо понимаем, что мультиклаудная модель – наиболее перспективный путь применения облачных сервисов в бизнесе. Олег Коверзнев, директор по развитию бизнеса, «Яндекс.Облако»
|
Не произойдет полной стандартизации и облачных услуг. Но тенденция к использованию общих стандартов, к возможности переноса вычислительной нагрузки с одной облачной платформы на другую, к интеграции облачных сервисов налицо. К ситуации, когда пользователь не станет задумываться, к какому облаку он подключен. Для него это будет большое облако, включающее сервисы всех провайдеров, – мультиоблако.
