Максим Березин, директор по развитию облачных услуг, КРОК
Термин «мультиоблачность» возник совсем недавно, и до сих пор среди участников рынка нет единого понимания, какие именно формы потребления вычислительных ресурсов могут попасть в категорию мультиоблачных. В частности, к ним нередко относят гибридные формы, подразумевающие подключение к публичному облаку ресурсов частной виртуальной инфраструктуры или даже коммерческого ЦОД, что в корне неверно. На наш взгляд, ничего сверхнового в объединении одним заказчиком возможностей двух и более облачных провайдеров нет. Подобная схема, пусть и не часто, но использовалась всегда с момента появления облачных услуг. Таким образом, «мультиоблачность» – это всего лишь маркетинговая оболочка для привычного явления, не более того.
Примечательно, что ни в России, ни в мире нет тренда на мультиоблачность. Мы в своей практике редко сталкивались с потребностью бок о бок работать с другим провайдером ради достижения какой-то конкретной цели заказчика. На Западе, по данным аналитиков, компании также предпочитают выбирать одного подрядчика. В частности, IDC говорит, что только 9% компаний готовы использовать услуги разных облачных провайдеров, а 34% европейских организаций не планируют в ближайший год мигрировать свои сервисы в новые облака.
Причина такого консервативного поведения кроется в существенных недостатках модели мультиоблачности, которые перекрывают все возможные плюсы.
Миф 1: О снижении цены на услуги
Один из доводов апологетов мультиоблачности – возможность гибко управлять стоимостью размещения данных и сервисов в облаке, заставляя поставщиков конкурировать друг с другом. Такое действительно возможно, но идет ли демпинг игроков на пользу заказчику? Мы сознательно не участвуем в конкурсах, где конечная стоимость услуг ниже нашей себестоимости, ибо принципы работы КРОК не позволяют предоставлять сервис с низким качеством. Однако можем предположить, что так действуют не все поставщики облачных услуг. Увлекаясь гонкой за контракт, они неизбежно ищут способы для уменьшения своих внутренних издержек. Такими способами могут стать использование старого, амортизированного и менее производительного оборудования, а также медленная реакция техподдержки на обращения ночью, в выходные и праздничные дни ввиду отсутствия нужного персонала. Кроме того, не секрет, что у компаний, оказывающих облачные услуги, работают инженеры с разными ставками. При заходе в проект с заведомо невыгодными условиями компании вынуждены привлекать менее квалифицированных сотрудников, которые, естественно, со своими задачами будут справляться хуже. Если заказчик стремится выбрать наиболее дешевые предложения из существующих, он должен помнить о классическом проектном треугольнике, включающем «качество», «сроки» и «стоимость». При низкой цене не бывает профессионального сервиса либо же сроки реализации проекта будут неудовлетворительными. На подобные риски при выборе поставщиков заказчикам всегда нужно обращать пристальное внимание.
Миф 2: О повышении отказоустойчивости и надежности
Компании принимают решение о выборе нескольких облачных провайдеров, чтобы снизить риски потери информации в случае возможных сбоев. Казалось бы, здравое решение, но и здесь не все так однозначно.
Рассмотрим типовые случаи, когда резервирование просто необходимо. Золотым правилом (best practice) является создание резервных ЦОД для mission и business critical систем. К первым относятся такие системы, простой которых в течение очень короткого времени (допустим, 10 минут или получаса) может привести к потере бизнеса. Это может быть, например, сервис отчетности, которым пользуются финансовые организации. Если по каким-либо причинам он недоступен, статистические данные не выгружаются и не предоставляются Центробанку в оговоренное время, то финансовая структура может лишиться лицензии. К системам business critical относятся сервисы, для которых допустим более длительный простой – в течение нескольких часов. Сверх этого времени неработоспособность бизнес-приложений чревата штрафами и потерей деловой репутации. Наконец, есть сервисы, которые для бизнеса некритичны, их потеря не повлечет существенных негативных последствий. Но, чтобы бизнес работал как часы и был максимально эффективен, такие сервисы и данные тоже необходимо застраховать, воспользовавшись услугой резервного копирования.
Собственно, и сервисы уровня mission и business critical, и некритичные приложения заказчики часто резервируют на базе облака КРОК. При этом мы рекомендуем для mission critical систем организовать работу двух наших облачных площадок по схеме active-active, когда каждая из них работает в боевом режиме. А для business critical процессов выбрать active-passive схему с менее скоростным переключением. Это позволяет снизить затраты на создание катастрофоустойчивой инфраструктуры с учетом критичности данных.
Использование еще одного стороннего облака для дополнительной гарантии отказоустойчивости сопряжено с некоторыми техническими сложностями, и применять такую схему мы не советуем. Основная проблема заключается в подборе двух поставщиков облачных услуг с фактически идентичными сетевыми инфраструктурами. Кто-то использует простые выделенные каналы, кто-то темную оптику, некоторые компании строят сетевые 2 MPLS облака. Существует масса вариантов по соединению площадок, но лишь на первый взгляд кажется, что можно легко подобрать наиболее подходящий, обеспечивающий хорошее соединение и низкие задержки. Как правило, создание таких неповоротливых инфраструктур на базе ресурсов двух провайдеров не только более дорогостоящее, но и менее надежное решение из-за размытия зон ответственности, о чем пойдет речь дальше.
Миф 3: Об использовании всех преимуществ аутсорсинга
Работа с одним провайдером подразумевает единую точку ответственности за все процессы, происходящие в инфраструктуре. Дополнительно этому поставщику облачных услуг можно передать целиком в режиме managed services (управляемые сервисы) такие задачи, как администрирование оборудования, сетей в облаке и на периметре, резервное копирование данных и даже обеспечение высокой доступности и катастрофоустойчивости. В результате заказчик снимает с себя всю рутину по обслуживанию аппаратной части инфраструктуры, может сконцентрироваться на более важных бизнес-задачах, снизить потребность в квалифицированных администраторах либо переориентировать их на другие внутренние проекты. Иными словами, воспользоваться всеми неоспоримыми плюсами аутсорсинговых услуг.
Что же происходит, если заказчик начинает работать с несколькими облачными провайдерами? Во-первых, возникают постоянные дискуссии на тему решения проблем на границах ответственности двух провайдеров. Во-вторых, увеличивается потребность в росте экспертизы внутри компании заказчика, требуется большее количество задействованного в облачном проекте персонала, который будет отслеживать соблюдение SLA не по одному, а по двум контрактам, контролировать взаимодействие двух поставщиков услуг, выполнять функции арбитра. Таким образом, заказчик остается полностью включенным в организационные и технические детали проектной деятельности.
Если заказчик не будет уделять должного внимания управлению этой объединенной облачной командой, инфраструктура начнет падать. Классический пример: межЦОДовый сетевой штурм, возникший из-за разниц в конфигурациях настроек маршрутизаторов и коммутаторов в двух облачных дата-центрах. При объединении двух сетевых инфраструктур началась генерация огромного количества пакетов, оборудование стало перезагружаться, в какой-то момент из-за высокой нагрузки и большого объема зацикленного мусорного трафика системы вышли из строя. Обе площадки «легли», потому что заказчик не отследил взаимного влияния двух инфраструктур провайдеров, каждая из которых работала по отдельности совершенно нормально.
Поэтому для всех участников, в первую очередь для заказчика, серьезные кросс-платформенные системы лучше размещать на базе территориально распределенных облаков одного провайдера с единой инфраструктурой, настройками, командой и зоной ответственности.
Миф 4: О простоте миграции в облако
Пожалуй, только небольшие компании с простыми и некритичными приложениями могут позволить себе менять поставщиков услуг как перчатки, чередуя их между собой в поисках идеала. Крупные компании, размещая тяжелые нагруженные системы в публичном облаке, осознают риски и здраво оценивают затраты на миграцию. Ведь для переезда на новую площадку нужно подвести новый канал связи, заплатить за его аренду, провести конвертацию виртуальных машин, которая тоже стоит денег. При переносе систем, скорее всего, произойдет даун-тайм, который может отразиться на бизнесе. Поэтому решение о смене облачного провайдера или подключении еще одного к реализации некой совместной бизнес-задачи крупные клиенты из числа банков, международных торговых сетей, крупных промышленных компаний принимают максимально взвешенно. Мы, в свою очередь, предлагаем им в течение месяца бесплатно воспользоваться всей функциональностью облака КРОК, чтобы в полной мере оценить все его преимущества.
