Возможность потреблять ресурсы внешнего облака напрямую зависит от состояния внутренней инфраструктуры. С внешним «облаком» интегрировать унаследованную инфраструктуру очень сложно – собрать в один пул внутренние и внешние ресурсы можно лишь в том случае, если у них одна и та же технологическая база. «Островковая» архитектура 1990-х годов, построенная по принципу «каждому приложению – по серверу», с коллективным облаком не совместима технологически. Поэтому если организация рассматривает возможность потребления внешних ресурсов, она должна четко осознавать, что, пока внутри она не построит приватное облако, путь к потреблению ресурсов облака публичного ей фактически закрыт.

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

Дорожная карта

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

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

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

О самостоятельной трансформации

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

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

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

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

Транспортная среда для облачных вычислений

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

«Облако» по стандарту

На данный момент полной прозрачности между «облаками», которые построили разные вендоры (каждый по своей технологии), нет. Нельзя сказать, что на этом пути стоят непреодолимые барьеры, но и для достижения полной прозрачности еще потребуется немного времени. Скорее всего, года через два-три появятся универсальные форматы, модели организации вычислений, которые позволят прозрачно перемещать ИТ-сервисы из одного «облака» в другое, вне зависимости от того, какие вендорные технологии используются. Это будет примерно как серверы на базе процессора архитектуры х86 – сейчас это промышленный стандарт. Кто бы такой сервер ни произвел: IBM, HP, Dell – на нем всегда сможет работать Windows, Linux или другая операционная система. А наличие стандарта позволит абстрагироваться от производителя оборудования. В области средств виртуализации, которые и являются основной облака, движение к индустриальным стандартам уже явно выражено, и к ним мы придем в ближайшие годы. 

Хотя само облако можно использовать согласно самым разным моделям. Их выбор напрямую связан от того, на кого ориентированы услуги конкретного провайдера: на частных лиц, на малый или корпоративный бизнес. Корпоративные провайдеры, я думаю, смогут либо выбрать одну из вендорных технологий (их же немного на самом деле – можно пересчитать по пальцам одной руки), либо поддерживать несколько сегментов на разных технологиях, чтобы удовлетворить потребности максимального количества корпоративных клиентов. Ведь работа с корпоративным клиентом – всегда штучная, и требования к удовлетворению его конкретных потребностей на порядок выше, чем при работе с массовым рынком. На массовый рынок вы выводите продукт: нравится – хорошо, не нравится – готовите следующий. С корпоративным заказчиком работа ведется по-другому, поэтому даже публичное облако в некотором смысле подтачивается под его задачи, под его модель использования. Поэтому я думаю, что могут быть гибридные варианты.