Как построить частное облако

Виктория родилась в Литве, где в 1988 году стала чемпионом по шахматам среди женщин, училась в Харьковском университете по специальности прикладная математика, а затем переехала в США, где получила степень бакалавра Computer Science в Case Western Reserve University. После четырх лет работы в Ford Motor в 1997 году перешла в Sun Microsystems, где в течение 10 лет занимала должность старшего архитектора продукта Sun Grid. Виктория – предприниматель, специалист в области распределенных вычислений и программирования на языке Java, Java-евангелист. Одной из первых применила язык Java в проектах CADCAM, создала систему обнаружения мошенничества, работающую в режиме реального времени, а также первое приложение для программистов на базе идеологии Utility computing.

При основании в 2006 году собственной компании Grid Dynamics Лившиц пошла не по обычному для стартапов продуктовому пути, а отдала предпочтение сервису. Grid Dynamics оказывает услуги консалтинга крупным организациям, помогая им преодолевать проблемы, связанные со структурой вычислительных ресурсов, рассматривая облака как средство доступа к практически неограниченному их пулу. Другая часть бизнеса компании заключается в построении облаков.

Какие корпоративные приложения следует переводить в облака? Что может стать стимулом к этому переходу?

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

• компании, которые уже инвестировали значительные средства в построение и обслуживание собственных ЦОД, для них частное облако – это следующий шаг эволюции ЦОД после виртуализации и консолидации серверов. В качестве примеров таких компаний можно привести eBay и Salesforce.com, mail.ru и Яндекс. Как правило, деятельность таких компаний невозможна без поддержки ИТ, которые и являются значительной статьей расходов. В то же время они не могут позволить передать этот критический компонент своего бизнеса сторонним поставщикам;
• компании, которым жизненно необходима гибкость облака, но из-за повышенных требований к безопасности – обычно регламентируемых государственными организациями – они не могут использовать внешние облака. Например, нормативные акты в таких индустриях могут требовать, чтобы данные о заказчиках содержались в пределах одной серверной стойки, что в условиях внешнего облака выполнить весьма сложно. С ограничениями такого рода сталкиваются, как правило, высокотехнологичные компании, работающие в полупроводниковой или медико-биологической (life sciences) индустрии.

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

Как начинаются «облачные инициативы» в организации, которые затем приводят к развертыванию облака?

Один из наших клиентов – крупнейшая торговая сеть в мире, которая сейчас находится на пути к завоеванию лидирующих позиций в электронной коммерции. Ее движение к облакам началось, казалось бы, в неожиданном месте – в отделе контроля качества программных продуктов QA (Quality Assurance). Разработчики и специалисты по QA столкнулись с известной проблемой – им не хватало ИТ-оборудования. У этих пользователей было три простых желания. Во-первых, иметь возможность оперативно – в считанные дни или часы – разворачивать новые версии среды разработки или тестирования для удовлетворения нужд разных команд. Во-вторых, не иметь заранее заданных ограничений на число экземпляров такой среды. И в-третьих, не обременяя себя чрезмерной административной нагрузкой, получать информацию о потреблении и стоимости используемых ресурсов. Облака оказались наиболее подходящим решением.

Почему в данной ситуации решением стало именно внешнее облако, а не обращение в ИТ-подразделение с просьбой добавить ресурсов?

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

В свое время такая ситуация вызвала появление мини-ЭВМ как альтернативы мэйнфреймам...

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

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

В какой момент ИТ-подразделения должны начать инвестировать в частное облако?

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

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

Как и какое внешнее облако выбрать?

Этот вопрос часто задают наши клиенты, и ответ, как это ни банально, начинается с фразы «все зависит от того, что вам нужно».

Начнем с количества сервисов, предоставляемых облаком. Многие облачные услуги оптимизированы под определенные типы приложений. Никто, наверное, не удивится, что Microsoft создала Azure для обслуживания приложений, написанных на .net, и для .net-разработчиков. Конечно, поддержку Windows обеспечивают и многие другие облачные провайдеры, но Azure построена специально для .net и предоставляет для своих разработчиков множество высокоуровневых служб и дополнительных удобств. Для масштабируемых приложений на Java или Python столь же привлекательным выбором является платформа Google AppEngine. И Azure и AppEngine – примеры решений класса Platform as a Service, накладывающих серьезные ограничения на архитектуру приложений, но максимально оптимизирующих процессы их развертывания, администрирования и масштабирования.

Другой класс облаков – IaaS (Infrastructure as a Service) и их службы уже более общего назначения, но при этом они предоставляют потребителям и разработчикам приложений гораздо больше свободы. Наиболее зрелым и функциональным IaaS-предложением является Amazon AWS (Amazon EC2 и Amazon EBS): четыре года в эксплуатации, сотни тысяч приложений, миллионы пользователей. У Amazon имеются серьезные конкуренты, среди которых можно назвать Rackspace и Terremark. Оба вышли из традиционного хостинг-бизнеса и ориентируются на корпоративных клиентов. Их цены более демократичны, а сервисы позволяют создавать и условно-частные облака, в том числе внешнее облако, к которому гарантированно имеет доступ только ваша организация. Кроме того, Terremark предоставляет своим клиентам возможность лицензировать их технологию для построения собственного частного облака. Путь внедрения облаков, который они предлагают, очень удобен и интересен, несмотря на возможные ограничения. Как пользователь, я могу сначала попробовать публичное облако. Если мне этого недостаточно, я могу получить выделенное условно-частное облако для монопольного владения. А потом уже можно строить собственное частное облако – использовать ресурсы собственного ЦОД для разворачивания облачной инфраструктуры со знакомым интерфейсом.

Что можно сказать про экосистему технологий для облаков?

Думаю, можно даже говорить не об экосистеме, а об экосистемах. Так, существует ряд решений с открытым исходным кодом, находящихся на разной стадии готовности к коммерческому применению. Особняком стоят два продукта: OpenNebula и Eucalyptus, которые позволяют разворачивать инфраструктуры среднего размера (до 500 серверов), поддерживая базовую функциональность IaaS, подобную Amazon EC2. Есть и другие достаточно интересные решения (Nimbus, Redhat Ovirt, Cloud.com), которые предоставляют отдельные компоненты для создания частных облаков.

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

Решения уровня предприятия представлены продуктами традиционных игроков на рынке ЦОД: VMware, BMC, CA, EMC, HP и прочими. Так, компании OpSource и Terremark строят свои внешние облака, опираясь на vSphere, предоставляя своим потребителям возможность использовать все возможности платформы, лежащей в их основании. Среди независимых игроков можно отметить компанию Appistry.

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

Как построить приложение, независимое от типа внешнего облака?

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

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

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

Как по шагам описать стратегию развертывания частного облака компании?

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

1. Дайте пользователям возможность поработать с публичными облаками для решения подобных задач. Есть определенная вероятность, что в вашей организации какие-то конечные пользователи уже сейчас используют внешние облака. Я считаю, что не стоит пытаться прерывать подобную практику, наоборот – ее стоит поощрять, но при этом контролировать. ИТ-подразделения должны четко понимать, кто, зачем и как в организации использует внешние облака. Если в вашей организации не используют внешние облака вообще, то вначале потребуется разработать некий набор политик, позволяющих конечным пользователям начать работать с внешними облаками для решения определенного набора проблем при посильной поддержке ИТ-подразделения.
2. После того как в вашей организации начнет зарождаться облачная культура, попытайтесь агрегировать требования и сценарии использования облаков. На этой базе можно создать некое описание архитектуры и требований к облакам в вашей организации. В этом описании может быть отражено следующее: какие базовые операционные системы нужно поддерживать; сколько и какого рода облачных систем хранения данных необходимо; какие нужны высокоуровневые сервисы; какие метрики оценки уровня обслуживания наиболее важны и т.д. Определитесь с поставщиками, наиболее соответствующими вашим требованиям, и продолжайте работать с внешними облаками, постепенно консолидируя и стандартизируя используемые сервисы. Если вы создаете собственный инструментарий, задействуйте библиотеки-брокеры, чтобы смягчить зависимость от одного поставщика.
3. В момент, когда в вашей организации появляется весомое количество пользователей, работающих с облаками, плюс есть набор причин (экономических или политических), по которым далее масштабировать облачную культуру имеет смысл лишь в рамках частного облака, реплицируйте платформу и функции внешнего облака на внутреннем ЦОД. Если вы создаете собственный инструментарий и последовали нашему совету из предыдущего пункта, добавьте поддержку вашего частного облака в библиотеку-брокер. В зависимости от специфики приложений, это может облегчить работу в «гибридном» режиме, когда для ваших приложений используется как частное, так и публичные облака.