Что такое Internal Developer Platform

Проблема, которую решает IDP

Типичный день бэкенд-разработчика в компании с 50 микросервисами. Нужно поднять новый сервис. Сначала — Confluence, поиск инструкции полугодичной давности, которая ссылается на Terraform-модули, переписанные в прошлом квартале. Потом сообщение в корпоративный чат девопсу с просьбой создать namespace в Kubernetes и настроить секреты. Девопс отвечает через четыре часа, потому что у него ещё десять таких запросов. Дальше выясняется, что CI-пайплайн из шаблона не работает с новой версией Node, — снова сообщение в чат. К концу дня работающего сервиса нет, зато есть устойчивое ощущение, что рабочий день потрачен на борьбу с инфраструктурой.

Internal Developer Platform (IDP) существует, чтобы этой ситуации не возникало. Разработчик открывает портал, выбирает шаблон «новый Node.js-сервис», заполняет пять полей (название, команда, окружение, подключения к базам), нажимает кнопку — и через пять минут получает готовый репозиторий с CI/CD-пайплайном, namespace в Kubernetes, настроенным мониторингом и записью в каталоге сервисов. Без тикетов, без ожидания, без археологических раскопок в вики.

Определения: платформа 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. Разработчик открывает страницу сервиса в портале и видит всю картину.

Спектр платформ: от вики до оркестратора

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) — не из моды, а потому что без платформы они теряют инженерные часы на координацию и ожидание.