Декларативность в будущем

В современном девопс подходе давно закрепились стандартные инструменты и подходы, Нам говорят серверы и виртуальные машины, мы думаем о terraform, про доставку кода мы говорим о gitops, K8S уже просто система оркестрации по умолчанию. Kubernetes, Terraform, GitOps — всё это принято называть декларативным подходом. Но если приглядеться внимательнее к манифестам, мы видим конструкции

replicas: 3
strategy:
  rollingUpdate:
    maxUnavailable: 1

Потом мы смотрим в .gitlab-ci.yml и видим там

image: docker:latest
services:
  - docker:dind

Практически везде, где мы работаем и что принимаем за отраслевой стандарт, можем найти в основе конструкции на вроде вышеуказанных, поэтому предлагаю обсудить вопрос:

AI-агенты — это первый шанс получить настоящую декларативность в инфраструктуре.

Да те конструкции, о которых говорились выше, не являются декларативными, а являются императивными. Мы не говорим запустить поы в достаточном количестве, а говорим запустить реплики в количестве 3. Строго, без вариантов. Кто-то скажет, а как же VPA и HPA, но это тоже императивные конструкции, мы говорим запустить реплики в количестве 3, а не запустить реплики в количестве 3 и при этом не убивать 10% реплик. Мы не можем говорить о настоящей декларации, пока у нас есть прослойка из императивных указаний для доставки кода.

Но в современном мире уже появились системы, которые могут привести нас к нужному состоянию декларативного описания доставки кода, с помощью AI-агентов многие уже пишут код, обмазываясь промптами, и заодно готовя пайплайн для гитлаба/гитхаба, даже не особо задумываясь о том, что конкретно будет происходить при доставке кода. Агенты генерирую код для пайплайна, но при этом они описывают состояние императивно, и тоже являются прослойками для императивного подхода.

Таким образом кажется, что система повторяет сама себя просто на очередном уровне абстракции, но это не декларативность.

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

На самом деле важно только одно: новый код должен быть доставлен в рабочее окружение с минимальными потерями для стабильности системы

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

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

Мы хотим, чтобы наш прод не падал как минимум какое-то решенное время, например 99.9% аптайма, именно это и будет наше декларачие и условием для соблюдения машина должна выполнить эту задачу или откатить версию создать отчет о том, что именно пошло не так, для модификации релизного кода. Кстати это перекликается к давно известным стандартам Blue/Green деплоя, канареечный деплой и прочие подобные вещи.

Мы можем указать нашему пайплайну следовать этому подходу в деплое, и тогда получается такая структура:

deploy:
  - name: deploy
    steps:
      - name: deploy
  - 99.99% SLA.
  - Выдерживать 10x нагрузку.
  - Без простоя.

Агент уже сам решает:

• StatefulSet или Deployment;
• HPA или KEDA;
• сколько реплик;
• какой StorageClass;
• topologySpread;
• PDB;
• canary или blue-green;
• ресурсы;
• даже выбор региона.