• Новости
• Блоги
• Аналитика
• Новости компаний
• В СНГ и в мире
• Анонсы

Частное облако: где маркетинг, где реальность?

Частное облако – не продукт, а концепция организации взаимодействия пользователей и ИТ. Результат ее внедрения зависит от стратегической цели проекта.

Больше чем технологии

Казалось бы, еще совсем недавно вопросы создания частного облака в России мало кого беспокоили. ИТ-специалисты крупнейших российских компаний не видели особой разницы между облаком и обычной серверной виртуализацией. Сегодня ситуация стремительно меняется. Во-первых, изменилось отношение бизнеса к ИТ в целом. Надежность и производительность информационных систем стали одними из главных конкурентных преимуществ на рынке. Особенно это актуально для компаний финансового сектора и тех, кто использует ИТ как инструмент продаж своих товаров и услуг конечному потребителю.

Второй немаловажный момент: современный бизнес стал концентрировать свое внимание на целесообразности внедрения тех или иных технологий. Например, если речь идет о создании частного облака, потенциального заказчика привлекает прежде всего легко прогнозируемая (на первый взгляд) выгода от внедрения: экономия на обслуживании инфраструктуры, повышение эффективности использования ИТ и оптимизация управления ими.

По крайней мере это обещают маркетологи. К сожалению, слишком часто маркетинг расходится с действительностью. Как правило, это выясняется на этапе технического задания, когда заказчик в качестве своих целей и пожеланий озвучивает тезисы из маркетинговых буклетов. Здесь он натыкается на непонимание со стороны интегратора, для которого частное облако – нечто большее, чем технологии. Это целая концепция организации рабочих процессов взаимодействия пользователей и ИТ.

Как это происходит в реальности? Менеджер по продажам общается с потенциальным заказчиком, после чего идет ко мне как к руководителю отдела виртуализации с просьбой подсчитать примерную стоимость проекта создания частного облака. Он свою задачу выполнил: рассказал контрагенту о преимуществах решения, вызвал его заинтересованность. А я, не видя клиента и ничего не зная о его потребностях и возможностях, должен оценить бюджет.

Менеджер не понимает, почему я не могу этого сделать. Он рассматривает частное облако именно как технологию – как некий продукт, у которого по логике должна быть конечная цена. Я же рассматриваю облако как концепцию, которая индивидуальна для каждого проекта. И поэтому не могу рассчитать бюджет ни за день, ни даже за неделю. Таким образом, проект умирает, не родившись.

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

На разных языках

Для начала вспомним, когда появился термин «частное облако». Лично я впервые узнал о нем в 2011 г., когда мне в руки попал рекламный проспект по VMware Cloud Director. Или даже раньше, слушая рассказ представителя компании HP об их инновационном продукте HP Matrix. Кто был первым – не важно. Важно, о чем говорили вендоры, предлагая услуги создания Private Cloud. По их словам, частные облака повышают доступность ИТ-систем, снижают затраты на администрирование ИТ-инфраструктуры и электроэнергию. Они также обеспечивают моментальное реагирование на требования бизнеса, масштабирование и самообслуживание по требованию.

Помнится, когда я впервые знакомился с этими тезисами, постоянно ловил себя на мысли, что все это уже есть. Большинство перечисленных преимуществ – это возможности, которые предоставляет использование серверной виртуализации. Тогда зачем нужна новая консоль? За что в реальности платит деньги заказчик?

Ответа на эти вопросы вендор не дает, предоставляя нам полную свободу действий в общении с потенциальным заказчиком. А маркетологи продолжают рассказывать клиентам, что предлагаемые программные продукты помогут выйти на новый уровень ИТ. Для сравнения: представьте, что у вас есть «Жигули». Вам говорят: купите Ferrari – это позволит выйти на новый уровень вождения. И вот вы сидите за рулем спортивного автомобиля за космические деньги и пытаетесь понять – повысился ваш водительский уровень или нет. Думаю, ответ очевиден. Рекламщиков это мало беспокоит, они преследуют свои цели под девизом «Спорткар в каждый дом!», разумно умолчав, что управлять подобным авто могут далеко не все желающие.

Примерно такая же ситуация наблюдается сейчас на рынке Private Cloud. Вендоры предлагают хорошие программные продукты, безусловно, обладающие полезным функционалом. Но ошибкой было бы считать, что один только факт их использования повысит качественный уровень ИТ. Участники рынка имеют разные (зачастую расплывчатые) представления о частном облаке, о его предназначении и возможностях. И каждый продвигает свою точку зрения.

Единственное, с чем согласны все, – что частное облако является отличной платформой для построения среды для разработки и тестирования. Там и масштабирование на месте, и с услугами все ясно (IaaS), понятно, кто является потребителем и поставщиком услуг, и ясно, зачем нужно самообслуживание. Но возникает вопрос: и это все? Ведь нам интересно увидеть в облачных технологиях не только платформу для тестирования, но и реальную основу для качественного развития ИТ. Для этого попробуем сравнить разные взгляды на частное облако: технический, аналитический и научный.

Три парадигмы

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

При этом облако обладает такими свойствами, как самообслуживание, сетевой доступ, объединение ресурсов в пулы, эластичность и измеряемость. На первый взгляд, все разложено по полкам.

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

Пулы необходимы для отделения пользователей, арендаторов друг от друга. Предоставление пулов по требованию обеспечивает гибкое разделение ресурсов между потребителями. Эластичность – это возможность быстрого предоставления требуемых ресурсов и их высвобождения. Измеряемость подразумевает, что вы можете посчитать, какое бизнес-подразделение сколько ресурсов потребляет, перевести объем затраченных ресурсов в деньги и получить объективное представление о том, сколько и за что мы платим.

Вот здесь и начинается путаница. Продолжим аналогию с автомобилями: NIST сваливает в одну кучу качественные характеристики автомобиля и водителя. И дает им единое определение. Например, «гармоничное вождение».

Производители ПО рассматривают облако с иной точки зрения. Для них существует такое понятие, как «зрелость облака». По их мнению, облако появляется на этапе применения серверной виртуализации и далее качественно эволюционирует посредством объединения ресурсов в пулы, стандартизации оборудования, автоматизации процессов развертывания и т.д.

Если принять такую парадигму, то частное облако появляется в организации вместе с серверной виртуализацией. Вендор предполагает, что в идеальном облачном ЦОДе виртуализовано все – от серверов до сети. А само понятие услуги хоть и присутствует, но зачастую ограничивается IaaS. С технической точки зрения облако – это программно определяемый ЦОД (Software Defined Data Center, SDDC). Таков подход большинства вендоров, предлагающих рынку продукты для построения частного облака. Для них понятия облака и программно определяемого ЦОДа тождественны. Другими словами, производитель рассказывает о том, как построить гоночный автомобиль, но ни слова не говорит о том, как выиграть гонку.

Что думают об облаке аналитики? Они оперируют другими терминами – так называемыми моделями зрелости ИТ-процессов. Им в первую очередь интересно, как развиваются технологии в плане пользы для бизнеса. Под бизнесом в данном случае подразумевается не только генерация прибыли, но и любая деятельность.

Существует множество моделей зрелости: от Microsoft, от IBM, от Gartner. Все они похожи друг на друга и все включают в себя несколько уровней развития ИТ в части взаимодействия с бизнесом. Наиболее удобной для примера является модель Gartner. У нее пять уровней. Первый уровень – хаотичный, «Дикий Запад». Характеризуется практически полным отсутствием службы эксплуатации и множественными службами поддержки. В современных условиях этот уровень практически не встречается.

Второй уровень – реактивный, на нем наводится определенный порядок в части поддержки существующей ИT-инфраструктуры путем отслеживания событий, создания единой службы поддержки, управления топологией сети и ИT-активами. Возникает необходимость в резервном копировании.

Третий уровень – проактивный, для него характерно управление производительностью, изменениями, проблемами, конфигурациями, доступностью. На этом уровне мы не просто устраняем возникшие проблемы, а предупреждаем их возникновение. Именно на этом уровне появляются различные дорогостоящие инструменты проактивного мониторинга и автоматизации процессов управления ИT.

Четвертый уровень модели Gartner – сервисный, когда ИТ рассматриваются как сервис-провайдер. Этот подход обеспечивает планирование нагрузок и емкостей, управление уровнями обслуживания. Управление ресурсами осуществляется на основе требований к сервисам и ориентируется прежде всего на потребности пользователей. На этом уровне формируется сквозная и связанная отчетность, дается обоснование затратам и планам развития ИТ. Именно на этом уровне появляются понятия услуги, потребителей и поставщиков ИТ, качества оказания услуги – все то, о чем говорил NIST в своем определении облака.

Еще есть пятый, «утопический» уровень. Назовем его «ценность для бизнеса». Он определяет ИТ как стратегического партнера, совместно с которым реализуются все ключевые бизнес-процессы. Качество предоставления сервисов обеспечивается за счет использования бизнес-метрик. Он встречается крайне редко и характерен для провайдеров публичных облаков, где нет проблем с определением роли ИТ в бизнесе – для них ИТ и есть бизнес.

Пристальный взгляд на ИТ

Итак, мы выяснили, что, говоря о частном облаке, вендор ориентирован на то, как построить ЦОД таким образом, чтобы использовать его максимально эффективно; аналитик думает о рациональном использовании ИТ-ресурсов; ученый рассматривает задачу в целом. Я считаю, что взгляд аналитика ближе всех к истине. Провожу уже знакомую аналогию с автомобилями: у хорошего водителя на несовершенной машине шансов на победу в гонке гораздо больше, нежели у незрелого новичка на суперсовременном болиде.

Дело в том, что с точки зрения бизнеса построение SDDC и совершенствование ИТ-процессов – задачи независимые, имеющие абсолютно разный характер и разные временные рамки. Первая задача – чисто тактическая, вторая имеет стратегический характер. Первую при должных финансовых вливаниях можно решить за год, решение же второй может занять и десять. Решать их можно независимо друг от друга. Программно определяемый ЦОД не является необходимым условием для построения частного облака. Достаточным – да, но не необходимым. Переход к сервисной модели ИT можно и даже нужно начинать без средств автоматизации, а SDDC должен стать осознанной необходимостью, а не самоцелью.

В любом случае задача создания частного облака, которая ставится перед интегратором, не должна быть абстрактной. Интегратор должен четко понимать, какова стратегическая цель проекта. Желаете ли вы снизить затраты на закупку нового оборудования? Консолидировать серверы? Повысить отказоустойчивость своих сервисов? Оптимизировать процессы управления ИТ? В зависимости от задачи и нужно будет продумывать пути решения и подбирать для проекта соответствующую команду специалистов.

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

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