Иногда возникают ситуации, когда наши программы пытаются установиться из старых источников или делают это «бесконечно» долго, больше, чем разработчики хотят ждать.
Для решения этой проблемы и других был придуман подход Immutable infrastructure, о котором мы и поговорим на двухдневном онлайн-интенсиве. Обсудив проблему и подход, на демо мы соберем с помощью Packer образ для нашего облака и запустим наше приложение.
Перевод материала подготовлен в рамках курса «DevOps практики и инструменты».
Еще совсем недавно все хвалили облачную инфраструктуру за ее простоту. Для организаций со сложной локальной инфраструктурой облака предоставили интуитивно понятную, масштабируемую и экономически эффективную альтернативу, которая обещала в целом изменить подход к ИТ-инфраструктуре.
Но по мере усложнения облачных решений эта простота отошла на второй план. Сегодня портфель услуг облачной инфраструктуры невероятно велик, постоянно усложняется и за этим всем все сложнее угнаться.
Только Amazon Web Services предлагает 175 различных инфраструктурных сервисов. Уже нет небольшого списка с набором простых, интуитивно понятных сервисов, которые можно быстро развернуть с помощью пару кликов мышки.
Вместо упрощения подходов к инфраструктуре облака движутся в противоположном направлении — создают новые проблемы управления, требуя дополнительных навыков по работе с виртуальными датацентрами и увеличивая среднее время выхода на рынок.
Почему растущая сложность облака — это проблема бизнеса
Когда облачная инфраструктура только появилась, ее начали использовать ради гибкости, масштабируемости и простоты управления, которые она предлагала.
Облака позволили разработчикам и инфраструктурным командам разворачивать новые сервисы в считаные минуты, что значительно сокращало время выхода на рынок и позволяло организациям получать важнейшее конкурентное преимущество на переполненных рынках.
Но по мере усложнения облаков эти преимущества для многих организаций стали не так важны. Для инфраструктурных команд усложнение сервисов влекло за собой овладение дополнительными навыками, а для разработчиков необходимость в более глубокой экспертизе при самостоятельном развертывании сервисов.
Проще говоря, усложнение облаков вернуло множество организаций в состояние, в котором они были 15 лет назад.
Решение — рассматривайте инфраструктуру как внутренний продукт
Крупные облачные провайдеры, возможно, перестали предоставлять простые, интуитивно понятные инфраструктурные решения, которые любой может развернуть самостоятельно. Но это не значит, что вы не можете создать свои внутренние платформы и процессы.
В этом суть подхода Platform Engineering (платформенная инженерия). Вместо того чтобы инфраструктурная команда тратила все свое время на настройку и развертывание новых экземпляров, сред и сервисов для разработчиков, она создает платформу, предлагающую самообслуживание, когда разработчики могут легко выбрать необходимые компоненты и развернуть их самостоятельно.
Такой подход начал широко применяться в 2020 году, о чем свидетельствует отчет State of DevOps от Puppet. Согласно отчету, 63% организаций имеют как минимум одну внутреннюю платформу самообслуживания.
Благодаря повторно используемым компонентам и самообслуживанию, инфраструктурные команды могут тратить меньше времени на настройку отдельных решений и предоставить бизнесу быстрый вывод на рынок новых цифровых сервисов.
На диаграмме выше показано, как при таком подходе экспоненциально возрастает скорость получения прибыли (speed to value) и скорость выхода на рынок по мере развития платформы и создания переиспользуемых компонент, которые легко можно комбинировать для создания нового продукта и расширения бизнеса.
По мере создания переиспользуемого продукта или компонента цикл Build-Measure-Learn (Сборка-Измерение-Обучение) становится все меньше и быстрее, ускоряя получение ценности. Тем не менее по мере развития требуется тщательное управление платформой, чтобы она оставалась компонентноориентированной и целостной.
Почему такой подход работает
Такой платформенный подход работает, потому что он учитывает потребности каждого и дает всем командам время и возможности, необходимые для того, чтобы сконцентрироваться на задачах, которые они делают лучше всего:
Командам разработчиков и другим внутренним клиентам для получения необходимых сервисов не нужно изучать новые языки или развивать навыки управления облачной инфраструктурой.
Команда инфраструктурной платформы видит все запросы, связанные с облачной инфраструктурой, и может расширять свою экспертизу по мере развития облачных решений и ландшафта инфраструктуры, гарантируя актуальность и ценность продуктов для организации в целом.
Однако важно отметить, что достичь этих результатов можно только при правильном планировании, внедрении и управлении.
Что может пойти не так?
Недавно ThoughtWorks работала с финтех-предприятием, которое попыталось внедрить платформенный подход и столкнулось с многочисленными проблемами, ограничивающими его эффективность.
Была создана команда, в которую вошли несколько новых облачных инженеров и несколько инженеров из текущей команды датацентра, у которых были способности к программированию.
Над созданием платформы команда работала 18 месяцев. Платформа должна была предоставлять разработчикам собственные облачные компоненты, используя подход infrastructure-as-code, через отправку Pull Request команде разработчиков платформы, которая координировала и разворачивала приложения на виртуальных машинах с балансировкой нагрузки через пайплайн непрерывной поставки (CD, continuous delivery).
Но после полутора лет разработки через новую платформу проходило только 2% продуктивных задач. Почему?
На приведенной выше диаграмме показаны зависимости задач в бэклоге, порожденные таким подходом. Это было ненастоящее самообслуживание, потому что часто какие-то другие команды или отдельные сотрудники должны были внести свой вклад и подправить запрос, прежде чем он мог быть принят. Таким образом, владелец конечного продукта оставался неясным.
По мере того как новые команды разработчиков отправляли все больше кода, эта неэффективность только увеличивалась (показано в нижней половине диаграммы). Запросов на ревью становилось больше, но их по прежнему рассматривала только одна команда разработчиков платформы, что создавало серьезное узкое место, которое только еще больше замедляло процесс развертывания.
В итоге была разработана платформа, которая с трудом справлялась с задачей обеспечения изначально обещанной ценности для бизнеса. Задержки и узкие места замедляли время выхода на рынок, новые языки и процессы затрудняли взаимодействие с внутренней платформой, и в конечном счете не отвечали потребностям разработчиков.
Залог успеха
Для обеспечения успеха такого подхода необходимо учитывать три ключевых фактора при создании и реализации стратегии платформы облачной инфраструктуры:
Учитывайте потребности и ожидания ваших клиентов
Назначьте владельца продукта
Пересмотрите показатели эффективности инфраструктуры
1) Учитывайте потребности и ожидания ваших клиентов
При таком подходе инфраструктура рассматривается как набор внутренних продуктов, а разработчики как клиенты. Как и в случае с любым другим продуктом, один из важнейших ключей к успеху — правильное понимание потребностей клиентов и реагирование на них.
Подобно тому как продуктовые команды и маркетинг сосредоточены на предоставлении качественного и интуитивно понятного клиентского опыта, команды облачной инфраструктуры должны сделать то же самое для внутренних клиентов. Для обеспечения высокого качества и долгосрочного успеха разработчики должны быть в центре каждого решения.
Например, если взаимодействие с платформой требует от разработчиков изучения нового языка только для того, чтобы продолжать выполнять ту же работу, которую они делали и раньше, то это не будет хорошим опытом для разработчиков. Как клиент, которому нужно преодолеть слишком много препятствий для покупки товара в интернет-магазине, он просто уйдет и вернется к тому, как он делал свою работу раньше.
2) Назначьте владельца продукта
Одна из самых больших проблем с истинным самообслуживанием в облачной инфраструктуре заключается в том, что ни одна команда или руководитель заказчика не заинтересованы в решениях, которые можно повторно использовать во всей организации. Каждая команда просто создает то, что нужно ей в данный момент. Для конкретной команды это нормально, но приводит к дублированию работ по всей организации.
Назначив владельца продукта, вы можете преодолеть эту проблему и спроектировать продукты облачной инфраструктуры с учетом потребностей всей организации. Такой независимый от команды лидер будет обеспечивать, максимальную пользу каждого решения.
Здесь достаточно работы на полный рабочий день, поэтому не поддавайтесь соблазну разделить обязанности в команде. Выделение отдельного сотрудника на эту роль повысит ответственность, чем просто поручение дополнительных задач текущим членам команды.
Это поможет привлечь внимание и показать намерение об изменении, о стремлении к улучшению и в конечном счете о вашем решении начать рассматривать инфраструктуру как продукт.
3) Пересмотрите показатели эффективности инфраструктуры
Одно из самых серьезных препятствий на пути к такому подходу к инфраструктуре, основанному на продуктах, является устаревшее представление о том, как выглядит успешная инфраструктурная команда. В прошлом было стремление снизить затраты и сохранить системы как можно более стабильными без внесения в них изменений и дополнительных возможностей.
С другой стороны, подход к проектированию платформ направлен на предоставление разработчикам возможности быстрого и легкого превращения своих приложений в готовые для рынка и бизнеса сервисы.
Вы не увидите краткосрочного снижения затрат. Будут долгосрочные улучшения в таких показателях, как время выхода на рынок, производительность разработчиков и согласованность в предоставлении и развертывании, что приведет к сокращению среднего времени восстановления (MTTR, Mean Time to Restore). Это критерии, с помощью которых вам нужно будет оценивать успех, и очень важно, чтобы это понимали все заинтересованные стороны и руководители всех уровней.
Итог
Управление облачной инфраструктурой стало чрезвычайно сложной задачей. Если вы хотите и дальше предоставлять разработчикам и ИТ-командам быстрый доступ к инфраструктурным сервисам с самообслуживанием, который раньше предоставляло облако, то вам придется взять дело в свои руки.
Приняв подход к проектированию платформ и создав инфраструктурные "продукты", вы сможете возродить простоту первых предложений infrastructure-as-a-service (IaaS), при этом максимально использовав современные возможности и технологии.
Такой подход требует особой ответственности. Он требует глубокого понимания внутренних клиентов, которым эти продукты будут служить. И он должен основываться на новых показателях эффективности датацентров, которые больше соответствуют ценности, которую может принести современный инфраструктурный подход.
Если вы сможете справиться со всем этим, то вас ждет более быстрый, бережливый и последовательный подход к управлению инфраструктурой. Подход, который расширяет возможности всех участников процесса поставки программного обеспечения, и помогает разработчикам быстрее запускать новые сервисы, а также может значительно сократить как время выхода на рынок, так и время окупаемости.
В заключение, важно понимать, что облачная инфраструктура обеспечивает основу для всего вашего бизнеса. Идя по пути наименьшего сопротивления, принимая хрупкость и не уделяя этому процессу достаточного стратегического внимания, вы повышаете риски и увеличиваете расходы в будущем.
Участвовать в двухдневном онлайн-интенсиве «Делаем immutable infrastructure с помощью Packer и Terraform»
Узнать подробнее о курсе «DevOps практики и инструменты»
