Не секрет, что сегодня большинство ИТ-организаций планируют инфраструктурную стратегию с учетом особенностей облачных технологий, и внутреннее, или частное, облако становится фундаментальной частью этой стратегии.
Чтобы не погрязнуть в спорах об определениях, достаточно сказать, что облачная среда позволяет потребителям ИТ-ресурсов направлять запросы на предоставление ресурсов в режиме самообслуживания, а поставщики могут настраивать порядок автоматического выделения вычислительных ресурсов: виртуальных серверов, сетевых каналов и средств хранения. Обычное развертывание механизмов виртуализации с поддержкой множества виртуальных серверов на одном физическом, хотя и полезно само по себе, но к вычислениям в облаке непосредственного отношения не имеет.
Из бесед с информированными людьми стало понятно, что развертывание частных облаков планируется во многих организациях. Поставщикам направляются запросы на получение коммерческих предложений. Компании намерены заключить договор с поставщиком в 2011 году и завершить внедрение в 2012-м.
Вопросы заключаются в том, как это частное облако будет использоваться и каковы его недостатки. Рассмотрим несколько сценариев. Некоторые из них представляются разумными, другие не имеют особого смысла, а третьи выглядят малопонятными. Тем не менее все же полезно будет поделиться увиденным и выразить свой взгляд на использование облаков организациями.
. Объясняется это следующим:
1. Ключевой принцип деятельности ИТ-директора заключается в том, чтобы не вмешиваться в работу нормально функционирующих систем. Любое изменение может привести к ошибкам и сбоям. Зачем же заниматься развертыванием новой инфраструктуры и пытаться интегрировать в нее приложения, которые и так работают? Впрочем, это не означает, что в существующей среде не будет никакой виртуализации. Одно из главных достоинств виртуализации в том, что эта технология приносит ощутимую выгоду, позволяя сокращать затраты за счет консолидации серверов без внесения каких-то серьезных изменений на уровне приложений.
2. Большинству существующих приложений размещение в облачной среде не сулит никакого выигрыша. Как правило, они имеют статическую топологию и администрируются вручную. Самообслуживание и автоматизированная эластичность не дают здесь никаких преимуществ. Поэтому интеграция облачной инфраструктуры в производственную среду вряд ли улучшит ситуацию. В любом случае вялотекущее внедрение в производственную среду виртуализации вызывает сомнения в том, что ИТ-службам за одну ночь удастся перенести в облако всю свою производственную инфраструктуру.
3. Вычисления в облаке — дорогостоящая и разрушительная инициатива. Мы видим, что организации недооценивают последствия перемен, которые влечет за собой переход в облачную среду, и стоимость этого процесса. Достаточно вспомнить, что для описания функционирования ИТ в облачной среде был даже придуман специальный термин devop, отражающий связь между процессами разработки и обслуживания текущих операций.
Итак, подведем итог: интеграция облачных технологий в существующую производственную среду — дорогостоящая инициатива, подрывающая сложившиеся устои и не сулящая особых преимуществ. Исходя из этого, мы полагаем, что большинство ИТ-служб не станет внедрять облачные технологии в производственную вычислительную среду.
Многие организации ориентируют первые проекты внедрения частных облаков на обслуживание разработчиков, и это разумно. В действующих процедурах обслуживание разработчиков зачастую оставляет желать лучшего, а появившаяся возможность самообслуживания способствует повышению производительности их труда. Кроме того, при таком варианте удается избежать многих вопросов, характерных для производственных частных облаков, — например, как интегрировать существующие сложные процессы, скажем ITIL, с гибким выделением ресурсов на основе самообслуживания? Нужно помнить также, что разработчики относятся к категории высокооплачиваемых сотрудников, и своевременное предоставление им необходимых ресурсов позволяет уменьшить общие затраты.
Но если организация внедряет у себя частное облако, ориентированное на разработчиков, каковы сценарии его применения? Другими словами, что произойдет, если разработчики начнут использовать частное облако для проектирования (и, конечно, тестирования)? Перечислим общие сценарии такого использования и их вероятные последствия.
Сценарий первый. Гибкая разработка, статические операции
При данном сценарии инженеры, занимающиеся разработкой и обеспечением качества, получают в свое распоряжение частное облако для решения задач проектирования. Но когда приходит время развертывать приложение в производственной среде, все операции выполняются в соответствии с существующими процессами (которые создавались для статической топологии, неэластичных приложений и сред со сложными процессами типа ITIL).
Мы полагаем, что степень удовлетворенности такой стратегией будет зависеть от доли новых разработанных приложений и использования эластичной автоматизации в облачной среде. Будет ли выбран такой подход, зависит от планируемых в организации требований к эластичности будущих приложений. Если наличие приложений, предъявляющих высокие требования к эластичности, невелико, такой сценарий вполне приемлем. Большинство приложений устраивает техника статических операций. Тем немногим приложениям, которым нужна эластичность, в качестве исключения предоставляется среда, позволяющая осуществлять более гибкие операции и проводить более релевантные оценки.
Этот сценарий вступает в конфликт с тем, что мы все чаще привыкли видеть в приложениях будущего. Меняется природа приложений, растут колебания рабочей нагрузки, усложняются топологии развертывания, все труднее становится управлять ими вручную. Сильнее проявляется несоответствие между перспективами приложений и операционными допущениями сценария.
Сценарий второй. Гибкое развертывание, полугибкие операции
При таком сценарии новые приложения помещаются в операционную инфраструктуру, поддерживающую эластичность, сложные топологии и автоматизированное администрирование, а существующие программы продолжают выполняться в старой, статической, операционной среде. Это можно представить как расширение среды существующего ЦОД, работающее по новым правилам.
В какой-то степени такой сценарий напоминает историю развития компьютерной отрасли. Новые компьютерные платформы не вытесняют существующие — они дополняют собой то, что уже имеется. Как правило, большинство новых приложений развертываются на новой платформе, вмешательство же в существующие платформы ограничивается минимальными обновлениями существующих приложений. Со временем подавляющее большинство приложений переносится на новую платформу.
Этот сценарий весьма привлекателен тем, что уменьшается общая дезинтеграция и создаются хорошие условия для разработки и внедрения приложений в облаке. Кроме того, устраняются препятствия, описанные в предыдущем сценарии.
При использовании подобного сценария нужно помнить о двух вещах.
Во-первых, о тех ситуациях, когда приложения от стадии разработки переходят на производственную стадию без получения официального разрешения. ИТ-служба может оказаться ответственной за приложения, которые каким-то непонятным образом попали в производственную сферу и теперь требуют гибкой и эластичной инфраструктуры. Другими словами, ИТ-служба рискует внезапно столкнуться с необходимостью незапланированного развертывания производственной облачной среды. Эта «преждевременная» передача неизбежно порождает дополнительные трудности и вызывает лишние вопросы.
Во-вторых, легко недооценить те изменения, которые потребуется внести для работы с гибкой инфраструктурой. Сквозная автоматизация выходит далеко за рамки установки стека облачного программного обеспечения и декларации «открытости для облачного бизнеса». Все уже привыкли к традиционному наращиванию старых платформ новыми. Столь же традиционно ИТ-службы переоценивают роль технологии и недооценивают влияние людей и процессов. В результате с приложениями в облаке будет возникать масса проблем при их внедрении в производство. Операционной группе придется на ходу учиться управлять автоматизированными, эластичными приложениями.
Сценарий третий. Гибкая разработка, обход операций
Этот сценарий ставит непростые задачи перед группой управления основной инфраструктурой и создает косвенную угрозу финансовой устойчивости всей ИТ-службы. В ходе этого сценария разработчики предпринимают попытки использовать частное облако, но по разным причинам находят отдельные элементы среды неудовлетворительными и отдают предпочтение разработке или развертыванию приложений в общедоступном облаке.
Причины можно проиллюстрировать на примере, который мы уже приводили ранее. При обсуждении вычислений в облаке с менеджером, отвечающим за инфраструктуру, обычно говрится о необходимости организовать самообслуживание при возникновении потребностей в ресурсах. Менеджер со своей стороны стремится к максимальной гибкости, но запрос на предоставление ресурсов должен быть переадресован операционному администратору. Администратор оценивает его суть, и, если несоответствий не выявлено, выделяет необходимые ресурсы и информирует разработчика о том, что можно приступать к их использованию. Администратор не видит разницы между настоящим самообслуживанием и отправкой по электронной почте запросов на выделение ресурсов. И меня вряд ли удовлетворит его реакция на необходимость прямого выделения ресурсов эластичным приложениям в зависимости от загрузки системы.
Такая ситуация типична для организаций, занимающихся инновационными разработками (ранее я уже подчеркивал разницу между поддерживающими и разрушающими инновациями и отмечал, что вычисления в облаке относятся к разрушающим инновациям). Сталкиваясь с разрушающими инновациями, организации обычно пытаются втиснуть их в рамки существующих процессов и допущений. Как правило, успеха это не приносит.
В данном сценарии разработчики с радостью начинают использовать частное облако, но, столкнувшись с нежеланием операционного персонала поддерживать самообслуживание, эластичность приложений и т. д., быстро разочаровываются и выбирают один из двух вариантов:
1) развертывание приложений за пределами внутреннего ЦОД;
2) отказ от частного облака в пользу разработки и развертывания приложений в общедоступной облачной среде.
Независимо от остроты ситуации разработчик в конечном итоге получает не то, что хочет. Работа в облаке позволяет уменьшить трения в ходе получения и использования вычислительных ресурсов путем отказа от бесконечных запросов, совещаний, телефонных звонков, электронных писем, не говоря уже о жестком нормировании ресурсов и требованиях к разработчикам обосновать свои запросы на выделение серверных ресурсов, ресурсов хранения или чего-либо еще.
Для формирования среды гибкой разработки на основе невосприимчивой производственной инфраструктуры могут потребоваться инвестиции в облако, которое так и останется незадействованным. При таком сценарии возникает опасность неэффективных капиталовложений: дорогостоящая производственная среда будет простаивать, а разработчики, идя по пути наименьшего сопротивления, начнут развертывать приложения в общедоступных облаках.
Облако для разработки — вполне разумный вариант для успешного старта, но его недостаточно при составлении долгосрочных планов. Облако разработки становится лишь первым шагом на пути к внедрению крупной производственной среды, поддерживающей самообслуживание, эластичное снабжение и гибкие операции, полностью соответствующие облачным характеристикам. Все, что не дотягивает до этого уровня, в конечном итоге обречено.
- Bernard Golden. Cloud CIO: 3 Private Cloud Use Case Scenarios. CIO Magazine. March 23, 2011