Как хостинг-провайдер может заработать на переходе от аренды «железа» к работе в облаке? Кто и почему будет покупать услуги дата-центра по подписке?
Вообще, когда говорят об аутсорсинге в сфере ИТ, обычно подразумевают или работу различных центров компетенций, или услуги «1С»-программиста, или эпизодическое участие админа-фрилансера в жизни небольшой компании. Но с развитием концепции XaaS («что угодно как сервис») понятие аутсорсинга меняется. И к традиционным услугам дата-центров — колокейшену, аренде серверов, стоек и периметров — добавляются новые услуги, основанные на облачных решениях, внедренных провайдером и позволяющих существенно расширить коммерческое предложение. Именно о них мы поговорим в этой статье.
Кто вне игры?
Есть несколько типов клиентов, которые не будут заинтересованы в услугах, возникающих при внедрении коммерческим хостером облачных продуктов.
Крупные корпоративные клиенты. В первую очередь, это крупные корпоративные клиенты, арендующие периметры или целые залы у провайдеров инфраструктуры хостинга, таких как DataPro. Они крайне редко становятся клиентами коммерческих хостинг-провайдеров. Последние зачастую сами арендуют площадки у провайдеров инфраструктуры, но предоставляют клиентам не столько инфраструктуру, сколько услуги по обслуживанию оборудования, которое клиент ставит к ним или арендует у них.
Поскольку акулы бизнеса имеют возможность вкладываться в специалистов с необходимыми компетенциями и в «железо», услуги коммерческих хостеров их не интересуют. Все, что им нужно чаще всего, — это стойки, климат-контроль, надежные каналы связи и высокий уровень физической безопасности объекта, предоставляющего инфраструктуру. При наличии всего перечисленного они сами себе хостинг-провайдеры.
Потребители традиционного хостинга. Есть сравнительно небольшие компании и частные лица, заинтересованные в ресурсах для размещения сайтов, процессинга потокового видео, игр и т. п. Они являются основными потребителями услуг, которые принято сегодня называть хостингом: аренда виртуальных или физических выделенных серверов, колокейшн. Это довольно стабильный рынок с ограниченным потенциалом роста. Просто потому, что цена чека невелика, а обслуживание мощностей, необходимых для существенного расширения клиентской базы, стоит дорого и делает этот бизнес низкомаржинальным. Вряд ли развитие данного направления позволит бизнесу конкретного хостера вырасти в
К слову, про контекст: типичным потребителем традиционных сервисов можно считать предприятия розничной торговли, проще говоря, магазины. Но последнее время ритейл обращает внимание на предложения IaaS. Согласно исследованию TAdviser, посвященному развитию рынка автоматизации ритейла и логистики в 2016 году, возможность заниматься собственным бизнесом, не отвлекаясь на решение задач по поддержанию и развитию ИТ-инфраструктуры, кажется продавцам привлекательной. Вообще, ритейл сегодня стремится экономить на всем — их собственный рынок сужается.
Итак, интерес к IaaS проявляют даже консервативные пользователи. Неайтишные бизнесы (логисты, финансисты, ритейлеры) стараются сократить расходы — у них кризис. Поиски наименее затратных ИТ-решений заставляют самые осторожные сегменты рынка экспериментировать с передовыми технологиями: PaaS, SaaS, IaaS... Все эти загадочные аббревиатуры ласкают слух делового человека, обеспечивая реальную экономию на поддержании высокотехнологичной инфраструктуры, сокращение капитальных расходов и прочие мелкобуржуазные радости.
Остановимся чуть подробнее на IaaS. В большинстве случаев это сугубо инфраструктурное облако, которое может быть реализовано на различных платформах, включая милый нашему сердцу OpenStack. Это облако имеет инструменты управления виртуальными машинами и системами хранения, которые связаны с этими виртуальными машинами, и отдельно объектное хранилище (Ceph, Swift — не принципиально). К этому же классу решений можно отнести виртуальные рабочие столы, которые обеспечивают одновременно возможность стандартизации рабочих мест пользователей, сохранность корпоративных данных и экономию на приобретении и обслуживании рабочих станций. Даешь тонкий клиент массам трудящихся!
Проблема в том, что современный IaaS — это, как правило, ИТ-инфраструктура для ИТ-компаний. Потребителями такого рода услуг являются разработчики программного обеспечения, создатели игр. Они сами по себе технологичны и не оперируют большим объемом данных: клиентскими базами, «тяжелыми» файловыми системами, инструментами бизнес-аналитики... Типовой сценарий для таких клиентов — нагрузочные тесты, требующие время от времени выделения существенных вычислительных ресурсов. Тест прогнали — ресурсы освободили. Все это задачи, которые не связаны с трансфером больших данных между своими и/или арендованными дата-центрами. Таких компаний не очень много, и конкуренция за право оказать им услуги высока.
Кто в игре? Неайтишные предприятия
Наконец, есть ИТ-отделы не-айтикомпаний. Таких, которые можно было бы назвать «pure enterprise». Очевидно, задачу, которую решает сегодня любой коммерческий хостинг-провайдер, можно сформулировать так: что предложить корпоративному клиенту (условному «мясокомбинату» или «кондитерской фабрике»), у которого уже есть действующая ИТ-инфраструктура, но нет серьезной внутренней ИТ-экспертизы?
Клиенты такого рода не будут арендовать серверы, потому что у них есть свои. Они могут арендовать периметр или дата-центр, но это не факт, потому что внутренней экспертизы для работы с чистой инфраструктурой, которую предлагают провайдеры инфраструктуры, у них, скорее всего, недостаточно. И это принципиально отличает их от мегакорпораций, с которого мы начали рассказ.
Они добровольно не пойдут в наше облако, потому что не знают (и знать не хотят), как это будет работать с их уже существующей и как-то функционирующей инфраструктурой. В конце концов, классический принцип «работает — не трогай» никто не отменял. Им проще при необходимости докупить еще серверов и жить по-старому.
При этом владельцы этих бизнесов слышат истории про облака и хотели бы попробовать, но консерваторы-админы встают горой на защиту привычных, пусть и не самых эффективных, зато проверенных решений. Союзниками владельцев в этой ситуации становятся финансисты, которые искренне недоумевают, почему вместо одной согласованной лицензии на VMware компания за три года покупает две?
А получается так потому, что стоимость поддержки у данного вендора составляет примерно 30% от стоимости лицензии. И отказаться от поддержки, гарантирующей, в том числе, доступ к новым версиям и, например, исправление ошибок, связанных с безопасностью, нельзя. Ведь помимо исправлений ИТ-специалисты получают возможность делегировать существенную часть своей ответственности инженерам компании-поставщика. В итоге за три года компания оплачивает две стоимости лицензии.
Владелец или управляющий, ободренный финансистами, приходит к айтишникам и говорит человеческим голосом: «Ребята, а собственно говоря, когда же мы, наконец, пойдем в облака? Вы продолжаете покупать серверы пачками, покупать какие-то лицензии... И вообще, вы такие немодные. Не уволить ли вас к чертовой матери?» И оказываются эти «олдскульные» ребята между молотом — руководителем и наковальней — непонятной новой технологией. Такое положение вызывает сочувствие. А значит, именно тут есть возможность предлагать решения, которые удовлетворят амбициозное руководство, экономных финансистов и консервативных айтишников.
При формировании предложения мы снова упираемся в вопрос работы с данными. Предположим, мы приходим к потенциальному клиенту такого типа и говорим: «Давайте вы часть инфраструктуры перенесете в облако». Если клиент в принципе согласен, то первый вопрос, который он задаст, будет связан с синхронизацией данных. И если внятного ответа на этот вопрос нет, то, скорее всего, максимум на что можно рассчитывать, это перенос в облако каких-то не критически важных элементов инфраструктуры, например, тестовых системы собственных разработчиков. И то придется провести большую работу, поставить шлюз VPN, подключиться к сетям заказчика... То есть, с одной стороны — большая инфраструктурная работа, с другой — всего
Предложить прямо сейчас какой-то готовый механизм «размазывания» этих данных между арендованным дата-центром либо облаком и собственным дата-центром клиента мы не можем. Есть дорогие коммерческие системы хранения данных, которые обеспечивают такой режим работы, при котором данные дублируются и синхронизируются, и работать с ними можно из любого места. Такие системы стоят сотни тысяч долларов и едва ли окупятся тому типу клиентов, о которых мы сейчас говорим. Основную нагрузку нам будет тяжело забрать к себе из-за того, что она привязана к данным. Но есть еще разного рода вспомогательные ИТ-штучки. Тоже связанные с данными, но это уже не онлайн-доступ, т. е. не надо из двух мест эти данные обрабатывать, достаточно спокойно перенести ограниченный объем данных. Речь идет про резервное копирование, бэкап; следующим шагом может стать создание резервной площадки — Disaster Recovery. Эти две опции важны любому более-менее крупному ИТ-подразделению (20+ серверов). Рассмотрим каждую из них подробнее.
Резервное копирование (бэкап)
Вы когда-нибудь теряли мобильник со всеми данными и контактной базой? Тогда вы точно знаете, что время от времени телефон нужно синхронизировать с компьютером, а некоторые особенно важные данные, например, записную книжку, лучше хранить в облаке, чтобы можно было восстановить в любое время и в любом месте. С корпоративной ИТ-инфраструктурой дело обстоит примерно также. У вас есть данные, с которых периодически нужно делать «снимки», копии. Бэкап может включать в себя не только данные, но и информацию о конфигурации серверов. Так же как бэкап айфона может содержать последние настройки устройства. Резервная копия дает вам возможность «откатиться» к какой-то критически важной точке, восстановить данные и параметры объектов инфраструктуры, на которых эти данные хранились. Часто бывает, что кто-то из сотрудников компании написал скрипт, который не так отработал и стер какую-то табличку с важными данными. Например, с клиентской базой... Все ИТ вроде бы продолжают работать, а таблички с телефонами клиентов в базе не стало. И что делать? Откуда их взять? Если есть бэкап, то восстановить потерю нетрудно.
Однако небольшие компании нередко формально подходят к созданию бэкапов. Они не имеют возможности проверять целостность и функциональность резервных копий. И каталог, который позволил бы оперативно найти необходимый фрагмент данных, могут позволить себе не все. А значит, устранить случайно обнаруженную неисправность или восстановить данные, удаленные несколько месяцев назад, им довольно сложно. Полноценные бэкап-решения от ведущих производителей, таких как Symantec, HPЕ или IBM, стоят дорого. В итоге у ИТ-специалиста есть понимание необходимости резервного копирования, но нет бюджета на промышленное решение. Он пытается решить проблему сам, но, к сожалению, текущие задачи все время отвлекают его от этой работы. Так происходит до тех пор, пока однажды важные данные не оказываются утеряны.
Решением может стать «бэкап как сервис». То есть компания оформляет подписку, допустим, на терабайт данных. По мере использования выделенного объема хранения можно заказать еще. Преимущество такого решения в том, что клиент получает не только резервную копию своих данных, но еще и возможность относительно быстро развернуть ее в облаке. Предположим, у вас на подходе новая версия CRM-системы, ее надо протестировать, а у вас под это ресурсов нет. Вы арендуете на короткое время мощности в облаке хостинг-провайдера: это могут быть физические серверы или виртуальные машины, неважно. Прелесть в том, что в этом облаке уже есть копия ваших данных, вы ее разворачиваете (или заказываете у хостера услугу по развертыванию образа вашей инфраструктуры из бэкапа, имеющегося в облаке) и получаете работающую систему для тестирования.
Мы получаем потенциального клиента, который еще и арендует вычислительные мощности в нашем облаке под разного рода временные нагрузки. От такого клиента можно ожидать следующего шага — перехода к созданию резервной площадки.
Disaster Recovery
Теперь представим себе ситуацию, при которой пострадала критически важная инфраструктура компании. Резервная копия данных в этом случае не поможет, потому что негде ее разворачивать, а даже если есть, то на это нужно существенное время — десятки часов или даже несколько дней. Основное назначение резервной копии — давать возможность восстановления важных данных, утерянных в результате технического сбоя, системной ошибки или диверсии. Но она не поможет сократить время даунтайма в ситуации, когда объекты инфраструктуры выведены из строя.
На практике приходилось наблюдать проблемы компании, которая на месяц была лишена полноценной ИТ-инфраструктуры только из-за того, что одновременно вышли из строя (сгорели) два источника бесперебойного питания. Вендор признал, что оборудование не подлежит ремонту. А поскольку речь шла о больших, промышленных ИБП, то ждать новых устройств нужно было не меньше двух недель. Запускать ЦОД без источников бесперебойного питания никто не решился. Были и более драматичные ситуации: пожары, затопления, блэкауты... Другими словами, выход из строя физической инфраструктуры — история нередкая.
Так что, кроме бэкапа, в некоторых случаях (если вы банк, крупная торговая площадка, логистическая компания и т. п.) стоит озаботиться построением резервной площадки, ЦОДа, в который можно перевести нагрузку, если основная по тем или иным причинам перестала функционировать.
Возможны две реакции на такое предложение:
Вариант первый: «Ничего такого нам не надо, у нас основной дата-центр в том же здании, где сидит все наше начальство, в головном офисе. Если завтра туда попадет бомба, то нам свет не мил без нашего начальства, все равно в этом случае наша компания перестанет существовать». Специалисты просто отказываются рассматривать такой сценарий.
Вариант второй: «Да, мы понимаем, что это нужно, но знаем, что проект такого рода будет очень дорогим. Мы не можем себе это позволить». Представители таких компаний рассматривают угрозу физического повреждения критической ИТ-инфраструктуры как реальную. И с интересом рассмотрят любое оригинальное и бюджетное решение данной проблемы.
Итак, даже при наличии бэкапа при выходе физической инфраструктуры из строя нужно найти, где его (бэкап) развернуть. На это могут уйти дни, а то и недели. Резервный ЦОД решает эту проблему. Это фактически копия основного дата-центра, туда обеспечивается репликация данных с небольшой задержкой, практически — в режиме реального времени. Но строительство, оснащение и поддержка резервного ЦОДа — отнюдь не бюджетное решение: и стройка, и оборудование, и лицензии на ПО стоят дорого.
Решением может стать аренда оборудования (или облачных ресурсов) без дополнительных вложений в приобретение лицензии на платформу виртуализации для резервного дата-центра (чаще всего речь идет про VMware) и настройку синхронизации данных и возможности при необходимости переключаться с основного ЦОДа на резервный.
Решение задачи
Итак, вернемся к задаче, сформулированной в начале статьи: «что предложить корпоративному клиенту (условному „мясокомбинату“ или „кондитерской фабрике“) у которого уже есть действующая ИТ-инфраструктура, но нет серьезной внутренней ИТ-экспертизы?».
Дано. Компания с уже действующей коммерческой платформой виртуализации (Microsoft, VMware — не важно), понимающая необходимость, но ограниченная в средствах на постройку и обслуживание резервной площадки. Второй вариант — та же компания, но по той или иной причине не готовая приобрести резервную копию или не нуждающаяся в ней, но заинтересованная в миграции основной площадки в облако, то есть в отказе от собственной инфраструктуры.
Решение. Для компаний, которые нуждаются в резервной площадке, но по тем или иным соображениям не могут себе ее позволить, оптимальный вариант — резервная площадка как услуга (DRaaS, Disaster Recovery as a Service). В этом случае всю заботу, связанную с переносом данных в облако, развертыванию и обслуживанию инфраструктуры резервной площадки и т. д. берет на себя сервис-провайдер. При этом заказчик имеет прозрачный механизм ценообразования, который напрямую зависит от размера обслуживаемой инфраструктуры, например количества виртуальных машин или объема данных.
Для второго варианта можно предложить использовать ту же технологию, что используется в DRaaS, но только на короткий промежуток времени — для переноса данных в облако. После того как заказчик убедится в работоспособности ИТ-систем, перенесенных в облако провайдера, от основной площадки можно отказаться и передать ее инфраструктуру провайдеру для расширения ресурсов облака заказчика.
Оба варианта позволяют существенно сэкономить на стоимости владения (покупка, поддержка и обслуживание) — по нашей оценке, экономия только на стоимости лицензий VMware составит от 30 до 50% от совокупной стоимости владения в случае переноса резервной или основной площадки в облако сервис-провайдера.
Об авторах: Валерий Безруков — коммерческий директор ATLEX.Ru, Илья Стечкин — сотрудник TechComLab.
