Инфраструктура как код: от императива до декларативного и обратного

Инфраструктура как код (IAC) прошла через увлекательные сдвиги за эти годы. Эволюция управления инфраструктурой была историей постоянной итерации, сформированной потребностями систем масштабирования, показателей скорости и безопасности, а также требований производительности разработчика.

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

В 2025 году мы видим тонкое, но значимое возвращение к императивным методам — ​​хотя и с поворотом. Давайте рассмотрим, как отрасль переключилась между императивными и декларативными подходами, сходящиеся к современным гибридным моделям.

Первые дни: императивное управление конфигурацией

В начале 2000 -х годов такие инструменты, как шеф -повар и марионетка, выставленная на конфигурацию инфраструктуры. Пол Хаммонд и Джон Алллоспс выступили с влиятельными развертываниями 10+ в день: сотрудничество Dev и Ops в Flickr на конференции O’Reilly’s Velocity, демонстрируя, как современные инструменты могут трансформировать инженерные практики. В то время достижение 10+ развертываний в день казалось научной фантастикой.

Шеф -повар и марионетка, самые популярные платформы раннего управления конфигурацией, стали основой этого сдвига, внедряя новый подход к настройке систем. Тем не менее, они работали в рамках императивной парадигмы, где пользователи явно обрисовали шаги для достижения желаемой конфигурации.

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

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

Это привело к нескольким ограничениям:

Увеличенная сложность: Сценарии стали громоздкими, когда инфраструктура масштабировалась.
Подвержен ошибкам: Незначительные ошибки часто вызывают несоответствия, особенно в окружающей среде.
Повторяющаяся логика (без сухой — не повторяйся): Дублированный код в сценариях создал значительное бремя обслуживания. Сдвиг в сторону гибридной декларативной конфигурации

Поскольку отрасль признала недостатки чистого императивных подходов, такие инструменты, как Ansible, стали переходным решением, смешивая императивные и декларативные парадигмы. Неудивительно, что Red Hat быстро приобрела Ansible, поскольку она набрала импульс. Благодаря своим игрокам на базе YAML Ansible позволила пользователям определять свою инфраструктуру без указания точных шагов для ее достижения. В то время как все еще выполняя задачи последовательно под капотом, Ansible принял декларативную философию описания результатов по процедурам.

Успех Ansible продемонстрировал аппетит к большей абстракции в управлении инфраструктурой, проложив путь к полностью декларативным инструментам.

Декларативная революция и прорыв МАК

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

Эти инструменты примирили это состояние реальностью, автоматизируя действия, необходимые для достижения результата. Terraform ввел файлы состояния для отслеживания ресурсов, обеспечивая инкрементные обновления и масштабируемость, в то время как CloudFormation использовала шаблоны JSON или YAML для декларативного управления ресурсами AWS. Оба предложили четкие решения проблем, связанных с императивными моделями.

Этот сдвиг парадигмы решил многие проблемы, присущие императивным подходам:

Масштабируемость: Декларативный МАК легко масштабировался по окружающей среде.
Последовательность: Государственное отслеживание обеспечило однородность в развертываниях.
Эффективность: Команды могли управлять инфраструктурой без повторяющейся процедурной логики. Императивный ренессанс (своего рода)

Сегодня такие инструменты, как Terraform CDK (TFCDK) и Pulumi, стали популярным выбором среди инженеров. Эти инструменты позволяют разработчикам писать IAC, используя знакомые языки программирования, такие как Python, TypeScript или GO. На первый взгляд, это возвращение к императивному МАК. Однако под капотом они по -прежнему генерируют декларативные конфигурации, такие как терраформные планы или шаблоны облачной информации, которые определяют желаемое состояние инфраструктуры.

Почему возрождение интерфейсов в императивном стиле?

Ответ заключается в более широкой тенденции к улучшению опыта разработчиков (DX), обеспечения самообслуживания и повышения доступности. Подобно сдвигам, которые мы наблюдаем в таких областях, как платформ, эти инструменты предназначены для оптимизации рабочих процессов и расширения возможностей разработчиков более эффективно.

Почему сейчас?

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

Движение к интерфейсам в императивном стиле не является шагом назад. Вместо этого он подчеркивает более широкое движение, чтобы расставить приоритеты в доступности и производительности разработчика, согласуясь с акцентом на оптимизированные рабочие процессы и возможности самообслуживания.

Знакомство разработчика: Многие разработчики более удобны для языков программирования общего назначения, чем языки конфигурации YAML или домена. Использование знакомого кода устраняет крутой кривую обучения.
Повторное использование кода: Разработчики могут включить существующую логику приложения в свои конфигурации IAC. Например, код, описывающий поведение прикладных агентов, может быть использован повторно для определения настройки инфраструктуры.
Повышение производительности: Такие инструменты, как TFCDK и Pulumi, делают IAC более доступным, демократизирующим управлением инфраструктурой. Разработчики могут определять инфраструктуру без переключения контекстов или обучения совершенно новым языкам.
Закулисная декларативная сила: В то время как разработчики пишут конфигурации, основные операции остаются декларативными. Это обеспечивает сохранение пособий по масштабируемости, последовательности и управлению государством.

Даже в смежных доменах, таких как CI/CD, мы видим это смешивание. Такие инструменты, как Dagger и Buildkite, позволяют разработчикам использовать знакомые языки программирования для определения рабочих процессов, создавая более доступный опыт при сохранении декларативных результатов под капотом.

Полный круг в 2024/5

Мы во многих отношениях прошли полный круг — но с современным взглядом на знакомые концепции. Направление для более удобных для разработчиков интерфейсов не в том, чтобы переосмыслить IAC, но улучшить его доступность и удобство использования. Даже после приобретения красной шляпы (и, соответственно, Ansible), IBM теперь собирается приобрести Hashicorp, подчеркивая, насколько развился ландшафт IAC.

Декларативный IAC остается центральным, но новые инструменты предлагают императивные интерфейсы, которые лучше соответствуют рабочим процессам разработчиков и подчеркивают гибкость, производительность и сотрудничество. Эти инновации снижают сложность, поддерживают масштабируемость сотрудничества и улучшают управление инфраструктурой. Они отражают тенденции в DevOps и облачном нативном развитии.

Что дальше и будущее IAC

Поскольку линии между императивом и декларативным размытым МАК появляются, появляются гибридные инструменты, чтобы объединить лучшие из обоих миров. Улучшение управления состоянием, более жесткая интеграция с логикой приложений и улучшенная поддержка с несколькими изделиями способствует будущему IAC к простоте и производительности. Различные платформы DevOps (например, Env0) помогают командам принять эти гибридные подходы, чтобы достичь большего с меньшим количеством.

Эти модели обеспечивают гибкость кодирования в императивном стиле при сохранении масштабируемости и согласованности декларативного МАК. Цель не в том, чтобы выбрать одну парадигму над другой, а использовать свои сильные стороны, чтобы удовлетворить развивающиеся потребности. Балансирование старых и новых подходов останется центральным в инновациях в IAC по мере развития инструментов.

Trending Stories youtube.com/thenewstack Tech движется быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Арел является главным инженером в команде ENV0 RND и является частью основной команды -основателя для проекта OpenTofu. Он принял участие в предоставлении проекта Opentofu в готовый к производству штата, и был одним из ответственных за людей … Подробнее от Arel Rabinowitz

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *