Компания Bluebricks спонсировала этот пост.
Со времени GitHub Universe и анонса GitHub Spec Kit разработка на основе спецификаций (SDD) взяла штурмом мир разработчиков. Идея убедительна: дайте агентам ИИ структурированный контекст с помощью спецификаций уценки, прежде чем они напишут код, и вы получите все это. Конец галлюцинациям по поводу API, поспешного кодирования и некачественных результатов.
Благодаря SDD агенты ИИ будут работать больше как разработчики-люди, которые получают документы с требованиями к продукту (PRD), разбивают задачи и выполняют их систематически.
Эта концепция формализует то, что команды разработчиков делали годами. Менеджер продукта пишет требования. Разработчики переваривают PRD или спецификации, разбивают работу на задачи и начинают писать код. SDD просто структурирует этот рабочий процесс для эпохи искусственного интеллекта, превращая спецификации естественного языка в контекст больших языковых моделей (LLM), необходимый для генерации осмысленного кода.
Как человек, который живет и дышит DevOps и разработкой платформ, я задал очевидный вопрос: что это значит для работы инфраструктуры? Стоит ли нам спешить с внедрением SDD для наших модулей Terraform и конфигураций Kubernetes?
Код инфраструктуры — это не код приложения
Код инфраструктуры выглядит как код, но ведет себя совсем не так, как код приложения.
Посмотрите любой файл Terraform, диаграмму Helm или шаблон CloudFormation. Что ты видишь? Технические характеристики. Инфраструктура как код (IAC) уже заложена в соответствии со спецификациями. Это декларативно. Описываем желаемое состояние. Мы говорим: «Мне нужна база данных с этими свойствами», а не «Выполните эти команды, чтобы создать базу данных».
Но здесь все становится интереснее.
- Код приложения способствует творчеству. Дайте 10 разработчикам один и тот же запрос на функцию, и вы получите 10 разных реализаций. Каждый из них может быть по-своему обоснованным и элегантным. Цель состоит в том, чтобы решать бизнес-проблемы с помощью новых подходов, оптимизировать взаимодействие с пользователем или находить разумные улучшения производительности. В таком разнообразии решений есть ценность.
- Код инфраструктуры способствует воспроизводимости. Когда я развертываю инфраструктуру в us-east-1, eu-west-1 и ap-southeast-1, мне нужны идентичные конфигурации. Те же настройки сети, те же группы безопасности, те же конфигурации базы данных. Стандартизация означает предсказуемые затраты, взаимозаменяемые детали и надежное аварийное восстановление.
Это различие важно для SDD, поскольку агенты ИИ преуспевают в творческом решении проблем, но испытывают трудности со строгой воспроизводимостью. Мы не хотим, чтобы агент ИИ проявлял творческий подход к конфигурации нашего виртуального частного облака (VPC). Мы хотим, чтобы каждый раз идеально применялся один и тот же проект.
Что еще более важно, код инфраструктуры редко переходит от спецификации к реализации. Рассмотрим, как на самом деле развивается инфраструктура. FinOps корректирует типы экземпляров для оптимизации затрат. Безопасность устраняет уязвимости непосредственно в рабочей среде. Кто-то масштабирует базу данных через консоль во время инцидента. Ваш Терраформ по-прежнему описывает исходное состояние, но реальность изменилась. Это дрейф: когда ваши фактические облачные ресурсы больше не соответствуют вашему IaC. Команды, занимающиеся инфраструктурой, работают в обратном направлении, постоянно обновляя спецификации в соответствии с реальностью.
SDD предполагает прямой поток от требований к коду. Но команды платформы работают не так. Нам не нужен ИИ, чтобы написать больше Terraform на основе спецификаций; нам нужно совсем другое.
Настоящий пробел в автоматизации — это оркестровка развертывания
SDD повлияет на работу инфраструктуры, но не всегда так, как это будут праздновать команды платформы.
Сегодня разработчики уже в 10 раз более продуктивны с помощью ИИ-пилотов, чем всего несколько лет назад. SDD обещает пойти еще дальше: полные модули создаются на основе спецификаций, целые функции материализуются на основе планов уценки. Объем кода приложения резко возрастет.
Весь этот код нужно где-то запускать. Каждая функция нуждается в инфраструктуре. Каждому микросервису нужна своя база данных, очередь сообщений и сеть. Ускорение создания кода создает беспрецедентное давление на скорость развертывания.
Тем не менее, развертывание по-прежнему остается ручным. В то время как разработчики получают помощников искусственного интеллекта, которые превращают спецификации в код, инженеры платформ по-прежнему координируют сложные развертывания вручную. Мы можем создать полноценный микросервис за несколько часов, но потратим дни на то, чтобы выяснить, как безопасно настроить и развернуть его инфраструктуру.
Почему агенты ИИ не могут организовать развертывание инфраструктуры
Препятствием для развертывания на основе ИИ являются структурные проблемы в организации кода инфраструктуры сегодня.
- Терралиты: Монолитные кошмары. Мы создали огромные файлы Terraform, в которых спецификации, значения и логика переплетены воедино. Один файл может перепутать настройки сети, баз данных и приложений. Небольшие изменения происходят непредсказуемо. Невозможно понять радиус взрыва, когда все соприкасается со всем остальным.
- Гетерогенный инструмент. В одной среде используется Terraform для инфраструктуры, Helm для Kubernetes, а также скрипты Python. Каждый из них имеет разные входы, выходы и управление состоянием. Их оркестровка требует понимания скрытых зависимостей, которые нигде не документированы.
- Работа назад от заноса. Команды, занимающиеся инфраструктурой, постоянно корректируют отклонения, обновляя код в соответствии с реальностью. Агентам ИИ сначала нужно будет сопоставить то, что на самом деле существует во всех облаках, регионах и учетных записях, прежде чем даже пытаться что-либо обновить.
Что нам действительно нужно, так это реструктурировать инфраструктуру, чтобы она была готова к использованию ИИ.
Развертывание на основе чертежей: инфраструктура для эпохи искусственного интеллекта
Путь вперед ясен. Нам необходимо изменить способы упаковки, развертывания и управления инфраструктурой. Вот как подготовить инфраструктуру к использованию ИИ:
- Преобразуйте каждую часть инфраструктуры. Превратите каждый модуль Terraform, диаграмму Helm и скрипт Python в артефакты с нормализованными входными и выходными данными. Эти артефакты становятся многоразовыми строительными блоками, которые собираются в чертежи.
- Соберите артефакты в четкие версионные чертежи. с четко определенными границами. Схема базы данных создает базы данных. Схема сети обрабатывает VPC и подсети. Никакого смешения, никакой путаницы.
- Опубликуйте их в каталоге. Решите, какие из них передать агентам ИИ, чтобы они знали, что безопасно и разрешено к развертыванию.
Этот подход решает структурные проблемы, о которых мы упоминали ранее:
- Терралиты разлагаются на артефакты и чертежи. Этот монолит из 10 000 строк становится набором специализированных компонентов, каждый из которых имеет свой жизненный цикл и понятные интерфейсы. Изменения ограничены. Радиус взрыва ограничен. ИИ работает с чертежами, а не с запутанным кодом.
- Разнородная оснастка становится унифицированной. Terraform, Helm, Python и т. д. — все они становятся артефактами со стандартными вводами и выводами посредством нормализации. Уровень оркестрации не заботится о том, что создало артефакт.
Благодаря этому вы можете решить проблему сноса:
Цикл становится устойчивым: реальность формирует чертежи, чертежи направляют развертывание, а развертывание отслеживается на графике.
Теперь ИИ-агент действительно может работать:
Запрос: «Нам необходимо расширить свое присутствие в Азиатско-Тихоокеанском регионе, чтобы снизить задержку».
Агент запрашивает каталог схем и облачный график и находит стандартную схему региональной инфраструктуры, уже работающую в сша и Европе. Он понимает зависимости от графа, сетевых баз данных перед приложениями.
«Я разверну региональную инфраструктуру v2.3 на ap-southeast-1. Судя по графику зависимостей, это займет 12 минут. Никакие существующие ресурсы не будут затронуты».
Одно одобрение. Все остальное делает оркестратор.
Инфраструктура отличается от кода приложения
Разработка на основе спецификаций имеет смысл при создании функций. Это не так, когда вы создаете платформу, на которой работают эти функции.
Потребности в инфраструктуре:
- Чертежи, а не спецификации: Многоразовые шаблоны с поддержкой версий, которые можно развертывать в разных регионах и средах.
- Оркестрация, а не просто генерация кода: Скоординированные многоэтапные рабочие процессы в инфраструктуре, конфигурации и приложениях.
- Четкие границы, не запутанные модули: Четко определенные области действия для каждого проекта и артефакта позволяют сдерживать изменения.
- Облачные графики, а не дампы кода: Живой просмотр того, что на самом деле работает в каждой учетной записи, регионе и облаке.
Будущее не за агентами ИИ, создающими Terraform. Это агенты искусственного интеллекта, которые безопасно выполняют развертывание, используя предварительно проверенные схемы.
Вот так ИИ наконец вступает в игру по развертыванию.
Bluebricks — это оркестратор среды, который преобразует IaC, инструменты настройки и сценарии в многоразовые, версионные схемы, готовые для агентов ИИ. Это позволяет командам создавать сложные готовые к работе среды одним щелчком мыши, независимо от базовой конфигурации, IaC и облака. Узнайте больше Последние новости от Bluebricks ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Идан Ялович — соучредитель и генеральный директор Bluebricks, платформы оркестрации среды, которая преобразует инфраструктуру как код, инструменты конфигурации и сценарии в многоразовые, версионные схемы среды, готовые к доставке агентами. Подробнее от Идана Яловича
