Короткое вступление

Довольно давно занимаюсь вопросами связанными с инфраструктурой и построением платформ для разработчиков.
Не один раз слышал от коллег и читал про такое понятие как Infrastructure as Data(IaD). Но я не смог найти внятного и короткого объяснения, что же это такое и чем полезно, потому решил попробовать рассказать свою версию.

Что такое Infrastructure as Data

Infrastructure as Data (IaD) — это (как можно догадаться из названия) развитие идеи Infrastructure as Code. Суть подхода в том, чтобы описывать инфраструктуру с помощью данных — YAML, JSON, переменных — а не менять код конфигурации вручную при малейшем изменении. Вы просто меняете параметр(переменную), а все необходимые действия выполняет заранее написанный код или сервис. Это упрощает управление и снижает количество изменений в логике.

В отличие от Infrastructure as Code (IaC), где изменения чаще всего касаются самого кода (например, Terraform-модулей), IaD предлагает отделить данные от логики. Код остаётся стабильным и универсальным, а различия между окружениями, настройками и ресурсами описываются только в конфигурационных файлах. Подход в програмировании не такой уж и новый, на самом деле разделение логики и данных очень много где встречаеться. Нам он может помочь заменить или расширить функционал модулей, заменить сторонние утилиты.

Стоит отметить, что IaD — это не догма, а скорее идеал, к которому стоит стремиться. Чтобы он действительно работал, важен и правильно написанный код и дисциплинированная команда, готовая следовать этому подходу.

Как пример такого подхода можно вспомнить Crossplane, но не пугайтесь. Даже обычный Terraform можно использовать следуя IaD. Более того я уверен что многие и так используют этот подход, потому что это логичный путь улучшения нашего кода.

Причина(зачем)

Давайте отвлечемся на то, чтобы понять, а зачем нам вообще что-то менять?

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

Если не нравиться слово конфликт, можно его мысленно заменить словосочетанием "запрос на изменение".

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

(Как)

Давайте попробуем понять какие есть способы решать конфликты, для примера, в Терраформе.

Когда нельзя просто добавить еще один блок с новым ресурсом, нам приходиться идти на всякие хитрости- использовать условные выражение(иногда довольно сложные), или разносить конфигурацию по разным стейтам.

Также можно использовать модули: например взять готовые(неважно свои или чужие) или написать новый модуль - такой подход я условно назову "сдвиг вправо" - потому что мы берем и переносим сложность из терраформ конфигурации в модуль.

Или можно сложность перенести из кода в данные(например в виде списка строк в переменной). Этот метод я условно называю «сдвиг влево» и мне кажется ключевым подходом IaD.

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

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

Диаграмма отражает разницу схематично, а вот как будет примерно выглядеть код для наших бакетов/корзинок:

# eu-west-1-dev.tfvars

s3_buckets = {
  "one-bucket" = {
    "name" = "one-bucket"
    "encryption" = true
    "versioning" = false
    }
  "two-bucket" = {
    "name" = "two-bucket"
    "encryption" = true
    "versioning" = true
    }
  "not-bucket" = {
    "name" = "not-bucket"
    "encryption" = false
    "versioning" = false
    }
  }

Согласитесь такой конфиг человеку гораздо проще редактировать, чем код Терраформа, и несложно заполучить такие файлики для каждого энвайромента и применять примерно вот так:

module "s3" {
  for_each = var.s3_buckets

  source = "../modules/s3" 

  ...

}

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

Собственно перенос конфигурации ресурсов в tfvars/locals и есть "сдвиг влево". Причем он может как совмещаться со "сдвигом вправо"(Терраформ модулем) так и вполне обходиться без него, все зависит от конкретной ситуации. Самое важное что мы получаем больше свободы действий и меньше изменений в коде.

Плюсы подхода

• Читаемая конфигурация инфраструктуры - вы всегда можете сказать что и где у вас созданно просто посмотрев в понятную человеку структуру, а не в запутанный код огромного модуля.

• Вместо сложных дата структур, можно использовать и простые(флаги-переключатели)

• Это сильно снижает необходимость в посторонних инструментах вроде Terragrant.

• При правильной настройке Infrastructure as Data позволяет реализовать полноценный GitOps-подход к управлению инфраструктурой: убирая конфликт, делегировав управление командам-потребителям. С кодом так сделать сложнее.

• Такой подход проще автоматизировать(присылать ченжи в виде tfvars файлов гораздо проще, чем в виде diff кода терраформа)

• Сильно снижаеться время добавление ресурсов для "еще одного нового сервиса" или "еще одного энвайромента"- вы добавляете не код, а описываете параметры в tfvars.

Минусы подхода

Повышаеться порог входа:

• Требуется опытная и дисциплинированная команда, ибо требования к коду повышаются - а такая команда стоит дорого.

• Либо нужен готовый сервис который будет нивелировать неопытность команды и все делать сам- а такой сервис стоит дорого.

В любом случае, инфраструктура — это постоянная работа с изменениями. И у нас есть два пути: либо менять код, либо менять данные. Подход IaD видиться более устойчивым и масштабируемым.