Давайте будем честными, инфраструктура, как код (IAC), должна была облегчить все.
И какое -то время после того, как вы начнете его использовать, вот что происходит. В первый раз, когда вы поменяете ручное обеспечение на Terraform или Ansible, это похоже на магию. Больше не нужно щелкнуть по облачным мониторингам. Нет больше «Кто сделал это изменение?» Тайны. Все контролируется версией, повторяется и, теоретически, сотрудничает.
Но в какой -то момент медовый месяц заканчивается.
Ваша инфраструктура масштабирует, ваша команда растет, и внезапно, что аккуратно организованная репо МАК превращается в обширный взаимосвязанный беспорядок. Инженеры начинают наступать на пальцы друг друга. Одна опечатка в общем модуле может снять производство (не спрашивайте меня, откуда я знаю). Ваша команда DevOps становится узким местом, а не мощностью.
А вот и кикер: это не просто проблема вашей команды.
В недавнем опросе, проведенном SpaceLift, 45% организаций считают, что они имеют высокий уровень автоматизации инфраструктуры, но только 14% делают. Существует огромный разрыв между восприятием и реальностью. Компании думают, что они работают на зрелом уровне, но на практике они все еще сталкиваются с одинаковыми ловушками: несоответствием, борьбой с управлением и классическим компромиссом между скоростью и контролем.
Итак, как узнать, где вы стоите? И что еще более важно, как вы повышаетесь?
4 стадии зрелости МАК
автоматизация инфраструктуры не двоичная — это спектр. Некоторые команды только начинаются, в то время как другие создали надежные платформы самообслуживания с ограждениями и рабочими процессами автоматизации.
Чтобы сопоставить это, мы использовали результаты опроса для создания индекса лидерства по автоматизации инфраструктуры. Это разбивает зрелость на четыре этапа:
Большинство организаций падают где -то между усыновителем и оптимизатором. Они видели ценность IAC, но они изо всех сил пытаются масштабировать его.
И именно здесь вступает оркестровая IAC.
Когда имеет смысл оркестровки IAC?
Оркестровка МАК не для команд, которые просто экспериментируют с автоматизацией. Если вы все еще выясняете основы Terraform, вам еще не нужна оркестровка.
Но как только вы находитесь на территории усыновителя, вы начинаете видеть шаблоны: что -то хорошее — эй, мы можем раскрутить всю среду за считанные минуты! Некоторые не так хороши-почему у каждой команды есть немного другой способ обеспечения инфраструктуры?
На этом этапе команды часто неправильно применяют лучшие практики DevOps к IAC. Они обрабатывают инфраструктуру, например, код приложения, запуская ее через конвейеры CI/CD общего назначения. И для небольших развертываний это может сработать.
Но по мере роста сложности вы попадаете в стену.
IAC не похож на код приложения.
Развертывание приложений не состоит в том, что сегодняшняя сборка не заботится о прошлой неделе. Инфраструктура является государственной. Ваша конфигурация Terraform Today включает в себя базу данных, которую вы создали в прошлом году, записи DNS с прошлого месяца и балансировщик нагрузки с прошлой недели.
Вот почему лечение кода приложения IAC не удается. Вот почему инфраструктура требует выделенной оркестровки, так же, как базы данных имеют инструменты миграции схемы.
Поэтому, если вы усыновитель, пытающийся стать оптимизатором, оркестровая даст вам наиболее значительный импульс. И если вы стремитесь к статусу лидера, это необходимо.
Два больших заблуждения о оркестровке МАК
У меня было много разговоров с лидерами DevOps, которые колеблется на оркестровке. Обычно они поднимают одну из двух проблем:
1. «Разве мы не можем просто использовать наши существующие инструменты CI/CD?»
Я понимаю — зачем добавлять еще один инструмент, когда у вас уже есть Дженкинс, Действия GitHub или что -то, что предпочитает ваша команда?
Но вот в чем дело: трубопроводы CI/CD не были предназначены для инфраструктуры. Они оптимизированы для быстрого, без гражданства, не для управления зависимостями в тысячах переплетенных облачных ресурсов.
Команды пытаются перегрузить это, притягиваясь на пользовательских сценариях и обходных путях. Но в конечном итоге они сталкиваются с условиями гонки, дрейфом или — худшим случаем — случайно снимают живую производственную базу данных.
Реальность такова, что, как только вы достигнете определенного масштаба, вам нужен слой оркестровки, созданный для инфраструктуры, а не код приложения.
2. ‘Разве это не создаст блокировку?
Никто не хочет оказаться в ловушке в запатентованной экосистеме. Вот почему лучшие решения для оркестровки МАК используют открытые стандарты — внедряя штат терраформ, используя Docker для среды исполнения и используя открытый агент политики для управления.
Замок происходит, когда вы создаете хрупкое, собственное решение, которое понимает только ваша команда. Хорошая оркестровка уменьшает блокировку за счет стандартизации рабочих процессов, а не перекладывает вас в конкретного поставщика.
Избегание общих ловушек МАК
Даже с оркестровкой команды DevOps попадают в две общие ловушки.
1. Проблема «монолит IAC»
Некоторые команды объединяют всю свою инфраструктуру в один массовый проект. Это звучит эффективно, верно? Одно место для управления всем?
Неправильный.
Монолиты становятся невозможными в масштабе. Они требуют навсегда, чтобы синхронизироваться, дросселивать облачными API и в конечном итоге разбиться. Распространенным примером является монолит Terraform, также известный как Terralith: это звучит как хорошая идея с самого начала, но она становится сложной и неприятной по мере роста вашей инфраструктуры.
Но противоположная экстремальность — разбивая все на крошечные, фрагментированные проекты IAC — так же плохо. Это добавляет слишком много накладных расходов и делает управление зависимостью кошмаром.
Ключ — найти правильный уровень модуляризации для потребностей вашей команды.
2. Чрезвычайно предписывающий против дикого запада
Если вы разрабатываете инфраструктуру самообслуживания, вам нужны ограждения. Но слишком много ограничений разочаровывают разработчиков, заставляя их постоянно просить DevOps на особые исключения.
С другой стороны, слишком большая свобода ведет к хаосу. Команды развертывают инфраструктуру совершенно по -разному, ползутся уязвимости безопасности и затратывают спираль из -под контроля.
Сладкое место? Предоставьте открытые строительные блоки со встроенными политиками для безопасности и контроля затрат.
Как двигаться вверх по кривой зрелости IAC
Итак, куда вы идете отсюда? Рассмотрим эти шаги, чтобы добиться прогресса:
На этапе лидера автоматизация не только о скорости — это контроль, безопасность и способность разработчика. Вот где входит настоящая рентабельность инвестиций.
Последняя мысль: «Парадокс контроля скорости»
Одним из самых интересных результатов нашего опроса было то, что мы называем парадоксом контроля скорости.
Команды в начале своего путешествия в МАК сосредоточены на скорости — быстрее развертывание инфраструктуры. Но по мере того, как они созревают, они понимают, что реальная проблема — это контроль — управление, соблюдение и безопасность.
Лучшие команды — лидеры — уравновешивают оба. Они строят быстро, но с управлением, встроенным в каждый процесс. Они позволяют разработчикам, поддерживая безопасность и соблюдение нормативных требований.
И в конце дня это цель.
Trending Stories youtube.com/thenewstack Tech движется быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Марцин Вислински является соучредителем и главным офицером R & D в Spacelift; Он также является соучредителем проекта Opentofu. Он начал свою карьеру в качестве SRE для Google, а затем перешел на разработку программного обеспечения в Facebook. Предприниматель в глубине души, … Подробнее от Марцина Вислинского
