Что такое Internal Developer Platform
IDP как продукт для разработчиков: self-service, golden paths, абстракции над инфраструктурой
Проблема, которую решает IDP
Представьте типичный день бэкенд-разработчика в компании с 50 микросервисами. Вам нужно поднять новый сервис. Вы идёте в Confluence, находите (если повезёт) полугодичной давности инструкцию, которая ссылается на Terraform-модули, которые кто-то переписал в прошлом квартале. Потом вы пишете в Slack девопсу с просьбой создать namespace в Kubernetes и настроить секреты. Девопс отвечает через четыре часа, потому что у него ещё десять таких запросов. Потом вы обнаруживаете, что CI-пайплайн из шаблона не работает с новой версией Node, и снова пишете в Slack. К концу дня у вас нет работающего сервиса, но есть устойчивое ощущение, что вы потратили рабочий день на борьбу с инфраструктурой.
Internal Developer Platform (IDP) существует для того, чтобы этой ситуации не возникало. Разработчик открывает портал, выбирает шаблон «новый Node.js-сервис», заполняет пять полей (название, команда, окружение, подключения к базам), нажимает кнопку — и через пять минут получает готовый репозиторий с CI/CD-пайплайном, namespace в Kubernetes, настроенным мониторингом и записью в каталоге сервисов. Без тикетов, без ожидания, без археологических раскопок в Confluence.
Определения: платформа vs портал
В индустрии термин IDP используют для двух разных вещей, и это создаёт путаницу. CNCF Platforms White Paper разделяет их так: Internal Developer Platform — это вся совокупность инструментов, API, автоматизации и процессов, которые платформенная команда предоставляет разработчикам. Internal Developer Portal — это UI-интерфейс, через который разработчики взаимодействуют с платформой. Портал — часть платформы, её фасад, но не вся платформа.
Эван Ботчер в статье на MartinFowler.com дал определение, которое стало каноническим: «Цифровая платформа — это основа из self-service API, инструментов, сервисов, знаний и поддержки, организованная как привлекательный внутренний продукт. Автономные delivery-команды используют платформу, чтобы доставлять фичи быстрее и с меньшей координацией». Ключевые слова здесь — «self-service» и «привлекательный продукт». Платформа, которую разработчики обходят стороной, — это не платформа, а пустая трата бюджета.
Что входит в хорошую IDP
У каждой компании платформа выглядит по-своему, но набор базовых возможностей повторяется.
Каталог сервисов. Единый реестр всех сервисов, библиотек, API, инфраструктурных ресурсов и их владельцев. Когда вам нужно узнать, кто отвечает за payments-service, какие у него зависимости и где его документация, вы заходите в каталог, а не пишете в общий чат «народ, кто знает…».
Self-service provisioning. Разработчики создают инфраструктуру сами, без тикетов в ops-команду. Новая база данных, Redis-кластер, S3-бакет — всё доступно через портал или CLI с предустановленными конфигурациями, которые соответствуют стандартам безопасности компании.
Golden paths и шаблоны. Предготовленные пути для типовых задач: создание нового сервиса, добавление нового API-эндпоинта, настройка мониторинга. Подробнее о них — в отдельной главе.
Документация. Техническая документация, которая живёт рядом с кодом и обновляется автоматически — API-спецификации, runbook-и, архитектурные решения (ADR).
Наблюдаемость. Единое место, где видно здоровье сервиса: метрики, логи, трейсы, алерты, SLO. Разработчик смотрит на свой сервис в портале и видит всю картину.
Спектр платформ: от wiki до оркестратора
Gartner прогнозирует, что к 2026 году 80% крупных софтверных организаций создадут платформенные команды — в 2022-м таких было 45%. Но это не значит, что все они построят одинаковые платформы. IDP — это спектр, и ваше место на нём зависит от размера организации, зрелости инфраструктуры и количества команд.
На одном конце спектра — wiki-страница с описанием стандартов и ссылками на инструменты. Скелтон и Пейс в Team Topologies называют это Thinnest Viable Platform — минимальная платформа, которая всё ещё приносит пользу. Для команды из 10 человек с тремя сервисами этого хватит.
Дальше идут скрипты и шаблоны: Cookiecutter-шаблоны для новых сервисов, Terraform-модули для инфраструктуры, Makefile с типовыми командами. Вы автоматизировали повторяющиеся задачи, но у вас нет единого интерфейса.
Следующий шаг — developer portal: Backstage, Port или аналог, который собирает каталог сервисов, шаблоны и документацию под одним UI. Разработчики получают единую точку входа.
На другом конце спектра — полноценный Platform Orchestrator вроде Humanitec, который управляет всем жизненным циклом приложения: от описания рабочей нагрузки через Score-файл до провижининга инфраструктуры и деплоя во все окружения.
Когда строить платформу
Самая частая ошибка — строить IDP слишком рано. Если у вас два сервиса и одна команда, вам не нужен Backstage. Вам нужен хороший README и Terraform-модуль. Платформа начинает окупаться, когда когнитивная нагрузка от инфраструктуры мешает разработчикам писать код — и обычно это происходит, когда в компании появляется пятая-шестая команда, которая тратит по два дня на создание нового сервиса вместо двух часов.
Хорошая стартовая точка: посчитайте, сколько времени ваши разработчики тратят на инфраструктурные задачи в неделю. Если эта цифра больше 20% рабочего времени и растёт с каждым новым сервисом, пора думать о платформе. Если 55% крупных организаций уже внедрили platform engineering (по данным опроса Gartner), это не потому что модно — это потому что без платформы они теряют инженерные часы на координацию и ожидание.