Задача управления в гибридной облачной среде требует учитывать различные факторы при выборе подходящего инструмента. На что надо обращать внимание, чтобы добиться оптимального результата?
Рынок корпоративных систем управления для гибридных облачных сред (Hybrid Cloud Management, HCM) долгое время оставался в тени. Требования заказчиков не распространялись за границы традиционного выбора между публичным и частным облаком, гибридные решения казались им сложными в управлении и обслуживании, непредсказуемыми с точки зрения безопасности и слишком «экспериментальными», рассчитанными в первую очередь на исследователей, чем на корпоративное применение.
Но в последнее время в этой нише появились признаки заметного движения. Сегодня корпоративные заказчики смотрят на строительство облачного окружения совершенно иначе. В первую очередь они рассматривают возможность применения гибридной облачной модели, а окончательный выбор именно этой конфигурации делают уже не менее половины участников рынка.
Впрочем, выбор нужной облачной конфигурации — это только начало. Следом возникает вопрос выбора наиболее подходящего инструмента, который обеспечит эффективное управление. Заказчиков интересует активный мониторинг ресурсов по заранее отобранным параметрам, подбор индивидуальной схемы при формировании набора применяемых политик, обеспечение эффективного управления клиентской базой и многие другие вопросы.
В своих регулярных отчетах «The Forrester Wave: Hybrid Cloud Management» аналитики Forrester оценивают состояние рынка систем управления гибридными облачными средами. Далее мы будем опираться на результаты этих исследований.
Этапы облачного роста
Развитие корпоративных облачных систем принято делить на три основных этапа. Первый
Во время второго этапа
Нынешний третий этап (2017 г. — н.в.) связывают с началом активного перехода компаний на использование модели гибридных облаков. Причины смещения их интересов — в возникшей у компаний потребности подключения разнородного набора из внешних и частных облачных решений, соответствующих продуктов, инструментов и технологий с целью обновления собственной ИТ-инфраструктуры.
Изменения произошли в первую очередь благодаря тому, что многие глобальные поставщики облачных решений, например, Google или Alibaba, стали активно предлагать корпоративным клиентам свои сервисы в упакованном, облачном виде. Теперь они размещали их на собственных облачных площадках, таких как Google Cloud или AliCloud. Применение таких облачных услуг заставляло компании искать пути для выстраивания новой ИТ-инфраструктуры, вело к строительству гибридных облачных сред.
Правила выбора HCM-продукта
На первых порах развития наибольшую популярность, по оценкам Forrester, получили следующие HCM-системы, которые часто относят к первому поколению (Generation 1) продуктов этого типа: BMC Cloud Lifecycle Management, IBM Cloud Orchestrator и Micro Focus Cloud System Automation (CSA). Их главной отличительной особенностью была универсальность. Гибридная облачная среда рассматривалась для них как один из возможных вариантов применения. Пользователям предоставлялся очень широкий набор разнообразных инструментов, позволявших проводить тонкую настройку в любых конфигурациях.
Универсальность хороша сама по себе, но на ее освоение требуется много времени, а для эффективного применения необходимы прочные знания и опыт. Поэтому концепция универсальности достаточно быстро обросла разнообразными отклонениями. Новые HCM-продукты были ориентированы в первую очередь на запросы заказчиков, у которых к этому моменту уже сформировалось понимание условий работы и собственных потребностей в формировании гибридной среды.
Выбор HCM-продукта сегодня напоминает скорей поиск подходящего варианта с учетом рассмотрения его положения по трем различным «шкалам». Первая «шкала» — поиск продукта, где на одном краю предложен широкий набор функций для работы со сложными облачными конфигурациями, на другом расположены самые простые по функциональному наполнению продукты, главная ценность который — удобство применения. Вторая «шкала» — это поиск между «навороченными» системами с полным набором функций и агрегаторами, позволяющими подключить внешние, «лучшие в своем классе» инструменты. Третья «шкала» — выбор с учетом предоставленного механизма подключения внешних модулей — от API до модульного встраивания.
HCM-продукты поколения Gen1 востребованы сегодня только среди крупных компаний и сервис-провайдеров, которым необходимо работать со сложными или разнообразными облачными конфигурациями. Они ценят возможность гранулированного управления по выбранным параметрам и глубину интеграции с собственными платформами. Остальных заказчиков больше привлекает удобный интерфейс и скорость внедрения, в том числе, с учетом необходимой донастройки.
Компоновка HCM-продуктов
Интерес заказчиков иметь под рукой сразу все необходимые инструменты управления подталкивает разработчиков к созданию продуктов типа «все включено». Их проще интегрировать в корпоративной среде, можно применять для решения различных прикладных задач. Но этот выбор порождает зависимость от определенного вендора и выбранного им подхода. В результате применять инструменты других вендоров часто становится затруднительно, даже когда применение альтернативного продукта более предпочтительно.
Заказчики также стараются избегать зависимости от определенного вендора, предпочитая выбирать HCM-продукт, выстроенной по модульной схеме. Это сохраняет многофункциональность, но зато обеспечивает независимость в выборе подходящего решения. Главное, на что обращают заказчики в этом случае — поддержка стандартизации и возможность замены части функциональных решений на другие.
Модульный подход нашел понимание и среди разработчиков. Если в их продукте еще нет поддержки для определенной части функций, то они легко допускают его комбинацию с другими сторонними инструментами, не занимаясь «изобретением велосипеда».
Нередко также применяется опция «выбор пользователя» («user’s choice»). Она позволяет отключить встроенный инструмент и воспользоваться альтернативным. В результате для нынешних HCM-продуктов уже стало привычным использовать сторонние продукты для выполнения определенных прикладных задач, например, для управления конфигурациями или приложениями, автоматизации развертывания контейнеризированных приложений, проведения анализа машинно-генерируемых логов. Для этих целей часто используют продукты Ansible, Chef, Helm, Kubernetes, Puppet, Splunk и Terraform.
Наращивание функциональной начинки
Среди разработчиков также популярны решения, позволяющие добавлять к исходному набору новые инструменты, когда обнаруживается, что их недостает. Они могут добавляться в базовый пакет двумя способами: по требованию и по мере необходимости. Технически в продукте имеется механизм для автоматического встраивания новой функции.
Благодаря этому механизму, можно также осуществлять наращивание за счет добавления новых функций по запросу. Если готового модуля еще нет, то к его разработке может подключаться разработчик. Если же уже есть инструмент, созданный сторонним разработчиком или партнером, то подключение выполняется как внешнего модуля (плагина).
Учитывая, что рынок облачных услуг продолжает стремительно расширяться, разработчики большинства HCM-систем также предоставляют полный внутренний API своих продуктов. Имея в распоряжении такую информацию, корпоративные разработчики и системные администраторы могут добавлять собственные инструменты самостоятельно, формируя индивидуальный функциональный пакет.
Создание инструментов собственными силами, конечно, требует от заказчиков серьезных усилий, особенно при отсутствии техподдержки со стороны вендора, но зато необходимый функционал можно получить быстрей, не дожидаясь выхода обновлений.
Варианты управления в гибридных облачных средах
Практическое применение HCM-систем осуществляется по двум основным сценариям.
В первом речь идет о создании прозрачной для остальных программных ресурсов среды, в которой скрыты все особенности применяемой облачной конфигурации. Этот сценарий получил название «невидимого облака» («invisible clouds»).
Второй сценарий подразумевает создание такой среды, где прозрачными для пользователей остаются только производимые над облачными ресурсами операции. Такой сценарий получил название «невидимого управления» («invisible management»).
Разработчики некоторых HCM-систем ограничивают заказчиков только первым сценария применения. Они позиционируют свою платформу как единую точку входа для контроля за изменениями в облачной конфигурации, позиционируя ее в равной степени и для пользователей, и для разработчиков. Благодаря неизбежной в этом случае унификации, весь арсенал функций управления, связанный с поддержкой команд настройки облачной конфигурации, выносится за периметр, доступный прикладным задачам. В итоге появляется возможность применять единый набор команд и формировать единый набор правил для работы с любыми облачными платформами.
Однако такая унификация неудобна заказчикам, которые хотят проводить еще и исследовательские работы с облачными ресурсами. При унификации разработчик «навязывает» им свой подход к управлению, тогда как заказчику могут требоваться в работе свой набор инструментов и правил. Поэтому им важно иметь также возможность получения другого варианта настройки системы управления — «невидимое управление» облачной средой. В этом случае можно экспериментировать, чтобы добиваться необходимой настройки или оптимизации.
Применение сценария «невидимое облако» на практике подразумевает создание абстрактного слоя, представленного набором доступных API-интерфейсов. Потребуется также создать дополнительный интерфейсный слой (API), который будет транслировать через себя данные, полученные с различных источников через собственные API и в собственных форматах.
В некоторых HCM-продуктах этот же интерфейсный слой используется также для трансляции запросов к индивидуальным API. В результате появляется т. н. Shim-слой — промежуточный прокси-уровень, позволяющий решать любые проблемы, возникающие с обеспечением совместимости. Нестыковки могут возникать из-за специфических правил и требований, которые предъявляют конкретные облачные провайдеры.
Стандартизированные ресурсы
Несмотря на активное применение в последнее время прокси-уровня, все используемые ресурсы должны подлежать стандартизации под API облачной платформы. Хотя при подключении HCM-системы требует только произвести настройку политик на прокси-уровне, все же приходится также провести шаблонное преобразование вовлекаемых ресурсов для гарантии их работоспособности под действием команд, поступающих со стороны HCM-продукта.
Получается, что выстроить прозрачное облачное управление сегодня достаточно просто, однако добиться полного доступа к ресурсам с другой облачной платформы оказывается гораздо сложней. В такой ситуации многие заказчики предпочитают иметь управляющие панели двух типов — эксплуатационную и экспериментальную. Используя экспериментальную панель, они сначала отрабатывают новую конфигурацию, а только потом пускают ее в «тираж», используя эксплуатационную панель.
Чтобы подключить новые ресурсы, доступны несколько способов. Можно 1) экспортировать имеющиеся шаблоны на новые платформы; 2) переделать предложенный разработчиком платформы шаблон к нужному виду; 3) начать пользоваться предоставленным шаблоном, внося необходимые изменения по мере выявления фактов нарушения политик. Последний вариант — самый щадящий, но он же и наименее привлекателен для пользователей: некоторое время в их работе будут возникать нестыковки, а исправления придется вносить вручную.
Настоящее и будущее рынка HCM
Время «облачных романтиков» прошло, сейчас наступило время прагматиков, считают в Forrester. Сегодня уже не имеет принципиального значения, какой продукт является лучшим на рынке, или какой вендор вырвался впереди других в своих достижениях. Сегодня главное — чтобы выбранный продукт делал все необходимое, что требуется заказчику.
