AI становится ещё одним типом нагрузки

Стек

Откликнуться

Загрузите резюме — мы свяжем вас с работодателем напрямую через нашу базу.

Описание

Platform Engineering 2.0: как меняется роль внутренней платформы 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

Контакты работодателя (email/phone/telegram) скрыты из публичного превью — отправьте резюме, чтобы мы связали вас напрямую.