Kubernetes, Terraform, GitOps, CI/CD, Backstage — классический стек Platform Engineering уже хорошо знаком.
Но что происходит с этой моделью, когда появляются AI-нагрузки и новые способы взаимодействия с инфраструктурой?
В материале CNCF автор предлагает рассматривать это как следующий этап — Platform Engineering 2.0.
При этом фундамент не меняется: Platform as a Product, удобство для разработчиков, готовые пути, самообслуживание и безопасность на ранних этапах остаются актуальными. Меняется масштаб задач платформы и круг её пользователей.
Что добавляется:
⏺AI становится ещё одним типом нагрузки
Платформе теперь приходится учитывать GPU/TPU, запуск и обслуживание моделей, обработку запросов, жизненный цикл моделей, MCP-шлюзы и специальные механизмы защиты.
То есть AI — это не отдельный слой где-то рядом с платформой. Для platform team это ещё один класс нагрузки со своими требованиями к ресурсам, безопасности и управлению.
⏺Пользователей становится больше
Помимо разработчиков и platform engineers, с платформой работают ML-инженеры, специалисты по данным, команды безопасности и соответствия требованиям, FinOps — и постепенно AI-агенты.
Отсюда практический вопрос: можно ли пользоваться платформой программно?
Интерфейс и Backstage отлично подходят человеку. Но автоматизации и агентам нужны интерфейсы через API: ресурсы, действия, права доступа и ограничения.
⏺FinOps перемещается ближе к созданию ресурсов
Стоимость становится частью решения ещё до развёртывания.
Например: сколько будет стоить новая нагрузка, какой ресурс выбрать и можно ли вообще её создавать с учётом текущего бюджета и правил.
⏺Безопасность уходит глубже в платформу
Меньше ручных проверок после развёртывания — больше политик и контроля непосредственно на уровне платформы и среды выполнения.
Для AI добавляются свои риски: неконтролируемое использование AI, prompt injection, отравление моделей, утечки данных при обработке запросов.
⏺Платформа становится модульной
Отдельные возможности должны быть доступны через API и собираться в разные сценарии: интерфейс, CLI, CI/CD, автоматизация или агент.
По сути, архитектура начинает выглядеть так:
Developer / ML Engineer / Agent↓Platform APIs↓Identity / Policy / Cost↓Kubernetes / Cloud / GPU / AIИ здесь важно: Kubernetes, Terraform, GitOps, Backstage никуда не исчезают. Меняется слой над ними — платформа начинает решать задачи, которые раньше находились за пределами классического самообслуживания разработчиков.
В итоге из концепции Platform Engineering 2.0 можно сделать вполне практичную вещь — ревизию собственной платформы.
Спросить себя:
→ Можем ли мы быстро выдать специализированный ресурс?
→ Можем ли мы сделать это через API?
→ Знаем ли стоимость до развёртывания?
→ Можем ли мы применять политики на уровне платформы?
→ Может ли автоматизация или агент работать с платформой без человека?
Если где-то ответ «нет» — вот там и находится следующая задача для platform team⌨️
#DevOps #Platformengineering