Мультиоблачный подход к построению инфраструктуры базируется на использовании компанией ИТ-ресурсов и решений нескольких внешних исполнителей и подборе индивидуального портфеля «по параметрам» бизнеса из широкого спектра услуг всего рынка облачного предложения.
Мультиоблачность может являться как следующей ступенью после работы с одним провайдером, так и единственно возможной моделью организации проекта, для которого необходимы ресурсы разных провайдеров. Исполнители отличаются друг от друга по целому комплексу параметров: от физических характеристик и вендорного наполнения инфраструктуры до модели ценообразования и качества технической поддержки. В этом и заключается главная фишка мультиоблачности! Сами провайдеры негласно занимают определенные ниши на рынке, в каждой из которых кто-то разбирается лучше.
Девиз пользователей мультиоблачной модели: «взять лучшее от рынка».
При индивидуальных запросах каждого заказчика у единственного провайдера вряд ли найдется идеальный набор по всем потребностям. Решением может стать комбинация разных моделей. По этой причине поставщики облачных услуг в большинстве своем уходят от понятия «коробочное решение», так как стремятся сделать услугу «дискретной» для дальнейшей кастомизации под заказчика.
Часто, потратив время на поиск исполнителя сложного облачного проекта и разочаровавшись, компания берется за реализацию проекта собственными силами, несмотря на очевидные преимущества облачного «конструктора», с помощью которого можно справиться быстрее, дешевле и без лишней головной боли.
Примеры мультиоблачного подхода:
Например, для объектов КИИ заказчики выбирают аттестованное облако со зрелыми инструментами информационной безопасности, для систем бизнес-аналитики – производительную облачную среду или готовые решения SaaS, реплицируют базы данных с коммерческой информацией из частного облака на резервную инфраструктуру, а удаленную работу сотрудников организуют с помощью VDI – виртуальных рабочих столов в облаке. При мультиоблачном подходе они будут стремиться размещать все заказы у разных исполнителей.
Более глубоко парадигма мультиоблачности отражается, например, при разнесении частей одного типа сервисов с различным функционалом и уровнем критичности для бизнеса: архивные базы данных – в облачное хранилище S3, базы с персональными данными – в облако с защищенным контуром, а реляционные базы данных – на облачную платформу PaaS. И снова – у разных исполнителей.
Еще глубже модель можно проиллюстрировать на примере, когда для тестирования одного сервиса используют облака с разными техническими параметрами или реализуют свои сервисы через нескольких провайдеров по модели SaaS. Результатом тестирования может стать выбор одного наиболее подходящего облака. А в случае дистрибуции сервиса через провайдеров удастся покрыть максимально широкий сегмент конечных пользователей и синхронно актуализировать версионность сервиса на мультиоблачной платформе.
Особенности реализации и взгляд со стороны рынка:
Подход «Multicloud» далеко не новый, большинство пользователей корпоративных облаков уже планируют подключать множество облачных сред – в основном для повышения отказоустойчивости, но очевидного тренда и ярых адептов модели на российском рынке пока нет. Более того, провайдеры признаются, что редко сталкивались в своей практике с проектами, которые им приходилось делить с другими подрядчиками. За рубежом модель распространена больше – там есть провайдеры, сотрудничающие с гиперскейлерами, которые консультируют заказчиков по облачным проектам и управляют интегрированными Multicloud средами.
Модель очень специфическая, ее стоит рассматривать с точки зрения пользы для каждого конкретного случая. Универсальный ракурс – общие неочевидные преимущества и недостатки модели. Под вторым ракурсом и изучим модель в данной статье.
Мультиоблачность стимулирует бизнес-инновации, позволяя воплощать смелые идеи бизнеса, которых еще не видел рынок.
Если набор нескольких сервисов от одного провайдера в портфеле заказчика имеет некоторые ограничения, то мультиоблачность возносит эффект от сотрудничества с провайдерами на новый уровень, превращая облачный ассортимент в объемный «конструктор», закрывающий нетипичные задачи бизнеса. Инновации становятся конкурентными преимуществами, повышающими спрос как на продукты провайдеров, так и на предложение их заказчиков. При правильной реализации модели ценник за «мультиоблачный проект» с успехом окупается для заказчика за счет эффекта от масштаба.
Использование мультиоблачной модели может служить фактором повышения качества облачных сервисов при сохранении или снижении цены за них.
Конкуренция между исполнителями стимулирует их разрабатывать новые инструменты и облачные функции. А от опасений за свои позиции в рейтинге исполнителей проекта растет соблазн снижать цены для заказчика, чтобы урвать кусок побольше в «демпинговой гонке». Объединение нескольких поставщиков в едином проекте служит рычагом влияния заказчика на каждого из них, благодаря чему он может еще гибче управлять затратами на ИТ-аутсорсинг. Также по индивидуальным критериям можно выбрать платформы под каждую из частей единого сервиса. На менее критичных сервисах и их элементах можно оптимизировать бюджет.
Снижение цен влечет внутреннее снижение издержек провайдера, но их оптимизация часто происходит за счет ресурсов, качество которых сложно оценить объективно на стороне заказчика.
Примером такого ресурса являются компетенции и профессионализм выделенных специалистов. Очевидно, что в проектах, где приходится финансово «ужиматься», будут задействованы специалисты с меньшим опытом. Крайне нежелательно допускать экономии на инфраструктуре – это может сыграть злую шутку с заказчиком. Для получения качественного эффекта от мультиоблачной модели важно с холодной головой подходить к финансированию проекта. Это под силу крупным и средним компаниям, которые принимают «дорогостоящие» решения при участии зрелого финансового отдела. Любая уважающая себя компания должна выбирать качественный сервис для бизнес-процессов, которые отражаются на их репутации. Делать выбор в пользу дешевого решения считается моветоном в бизнес-среде.
«Мультиоблако» позволяет диверсифицировать риски и качественно изолировать облачные платформы физически, юридически, а также с точки зрения самих технических исполнителей с различающимся «бэкграундом».
Мультиоблачную модель можно применять в качестве инструмента минимизации рисков потери данных. Для бизнес-критичных приложений и сервисов – осуществлять резервирование инфраструктуры по модели «active-active», когда обе площадки работают под нагрузкой. Для менее критичных систем использовать резервный ЦОД или модель «active-passive», когда вся работа осуществляется на основной инфраструктуре, а в резервный ЦОД передаются только «срезы» рабочих профилей. В случае аварии на основной инфраструктуре реактивировать «холодный» резерв на площадке второго провайдера и восстанавливать работу с последней копии рабочего процесса. Такие модели чаще встречаются у одного провайдера, но при мультиоблачном подходе риски еще ниже, так как все ресурсы максимально изолированы друг от друга вплоть до юридического оформления услуги и специалистов, задействованных на проекте.
«Мультиоблачность как услуга» или «Multicloud» упрощает менеджмент многооблачной архитектуры на стороне заказчика.
Оркестрация обеспечивает совместимость идентичных инфраструктур, фреймворки – управляемость веб-приложениями в разных облаках, а контейнеризация – это оркестрация и централизованное управление cloud-native приложениями на платформах kubernetes, которые виртуализируют ОС с помощью контейнера, объединяющего в себе файлы приложения, конфигураторы и зависимое ПО. Но все эти технологии еще на стадии своего развития, и бизнес-среда не знакома со многими из них, в то время как менеджмент мультиоблака для заказчика может взять на себя провайдер.
На рынке развивается «мультиоблачность как сервис» – провайдер подключает к своему облаку ресурсы нескольких гиперскейлеров, с которыми у него партнерские отношения. За интеграцию облачных ресурсов отвечает этот провайдер. Благодаря централизации облачных сред у одного провайдера возможна организация мультиоблачной информационной безопасности, которая для заказчика по сути ограничивается только юридическими аспектами. Провайдер объединяет ресурсы гиперскейлеров в единый пул без оркестрации с помощью брокера облачных сервисов или консоли, к которой дает доступ заказчику по принципу «самообслуживания».
Возможность тестирования различных решений на различных облачных платформах.
Предположим, компания работает с собственным ПО, согласованным с внутренними бизнес-процессами и щедро проинвестированным. Со временем инструмент теряет в производительности, устаревает морально и не успевает за рынком, и из-за этого страдает эффективность завязанных на нем бизнес-процессов. Перед компанией встанет выбор: мигрировать имеющуюся систему в облако по дорогостоящей модели IaaS или воспользоваться альтернативным бюджетным решением SaaS, но при этом вложиться в «форматирование» бизнес-процессов организации и переобучение сотрудников. Стратегия мультиоблака в данном случае решает проблему, давая возможность протестировать оба варианта и выбрать из них наиболее прижившийся. Почему именно мультиоблако? – ведь у одного провайдера можно найти оба решения, оптимальные по соотношению цена/качество. Размещая заказы у разных провайдеров, можно добиться кристальной объективности в сборе результатов тестирования. Еще один плюс – это возможность выбирать нишевых поставщиков, лидирующих в своих сегментах.
ВЫВОДЫ:
«Мультиоблако» – это инструмент, требующий оправданного использования и множества компромиссов. Перед его внедрением стоит произвести детальный анализ затрат и эффекта. Каждый облачный проект, а мультиоблачный в частности, должен быть ассимилирован из потребностей бизнеса – актуальных и прогнозируемых нужд – только тогда удастся эффективно распределять ресурсы и инвестиции. Мультиоблачный подход очень гибкий и в то же время довольно хрупкий – он идеально подойдет для реализации проектов с непрогнозируемой потребностью ресурсов – например, для тестирования новых решений. Принципы работы DevOps должны способствовать интеграции сервисов в «диверсифицированных» облаках.
При работе с несколькими исполнителями, как только проблемы возникают на границе их зон ответственности, головная боль заказчика, от которой он так надеялся избавиться с помощью аутсорсинга, возвращается, да еще и с большей силой. Если граница проведена по бизнес-критичным граням бизнеса, никто из исполнителей не признает вину и не возьмется на свой страх за решение проблемы, так как принцип «инициатива наказуема» особенно актуален в области, которая документируется от и до. Более того, в штате необходимо больше человеческих ресурсов для менеджмента мультиоблачного портфеля. Обычно целый отдел выступает в роли арбитра, который следит за соблюдением SLA по нескольким договорам. Крайне нецелесообразно оставлять облачный проект без контроля, а мультиоблачный – тем более.
Мультиоблачная модель более неповоротливая, чем облачная. Все решения по первичной конфигурации мультиоблачных решений нужно принимать взвешенно в соответствии с истинными техническими потребностями бизнеса, иначе расходы на исправление ошибок могут быть не по карману компании.
На рынке существуют облачные провайдеры, реализующие «Multicloud» как услугу при поддержке гиперскейлеров, с которыми у них заключены партнерские отношения:
В таком случае, во-первых, мультиоблачность не становится непосильной задачей для заказчика – он приобретает пул разнородных сервисов в качестве целостной услуги от единого провайдера, который администрирует и несет ответственность за всю интегрированную инфраструктуру от смежных подрядчиков. Провайдер полностью погружается в проект и осуществляет помощь и консультирование на 360 градусов по вопросам управления мультиоблачной средой заказчика через единую консоль, а гиперскейлер реализует через партнера-провайдера свои ресурсы.
Во-вторых, провайдер уже понимает возможные схемы реализации проектов, сам синхронизирует облака и обладает необходимыми компетенциями, позволяющими обходить подводные камни в процессе, имеет больше понимания в выстраивании мультиоблачной системы информационной безопасности. То есть консультационная поддержка становится главным преимуществом провайдера для заказчика. Благодаря этому удается снизить риски управленческой ошибки и грамотно оценить их стоимость, а также предусмотреть потенциальные варианты и инструменты защиты интегрированных сред, которые в дальнейшем можно предложить заказчику в составе услуги.
В-третьих, ресурсы гиперскейлера, приобретенные через провайдера, не дороже, чем рыночное предложение гиперскейлера. С такой моделью больше не надо решать дилемму, где на одной чаше весов – ценник, а на другой – качество. Благодаря партнерским отношениям, каждая сторона имеет свои преимущества.
Более того, каждый гиперскейлер, понимая возможности конкурентов, с которыми работает их заказчик, будет стремиться совершенствовать свои сервисы, повышая их качество. Заказчик тоже вносит свою лепту в равномерное развитие сегментов мультиоблака: его пользовательский опыт в форме обратной связи служит импульсом к модернизации сервисов и поиска решений для нестандартных задач.
Подведем итог, опираясь на мнение аналитиков Gartner, которые советуют выбирать стратегического партнера для реализации глобальных задач и оставить возможность участия нескольких поставщиков облачных сервисов для иных задач или пилотных проектов. Однако не стоит относиться к облакам как к товарам, каждый из провайдеров обладает инновациями, и синергетического эффекта можно добиться только при партнерском сотрудничестве, – не потребительском!
