Внутренние платформы для разработчиков: почему это вопрос для руководителя
Что такое internal developer platform, почему этот подход набирает силу и при чём тут скорость и операционный контроль.
Несколько лет назад разговор о DevOps был разговором о культуре и инструментах. Компании внедряли CI/CD, учились деплоить быстро, налаживали мониторинг. Этот процесс в большинстве технологически активных компаний так или иначе прошёл. Следующий уровень - platform engineering - теперь входит в обиход, и мне кажется важным объяснить, почему это не очередная мода, а логичный следующий шаг.
Из чего вырастает идея платформы
Когда в компании несколько команд разработки, каждая из них рано или поздно начинает строить одно и то же. Своя схема CI/CD, свой способ настраивать окружение, свои подходы к логированию и мониторингу, свой набор скриптов для деплоя. Это работает, пока команд мало. Потом начинаются проблемы.
Новый разработчик выходит на работу и тратит неделю, чтобы разобраться, как вообще устроено окружение. Один сервис падает, и оказывается, что у него другая система логирования, чем у остальных - инцидент расследуется дольше. Появляется задача настроить аутентификацию в новом сервисе - и каждая команда делает это по-своему.
Internal developer platform (IDP) - это попытка вынести общую инфраструктуру в отдельный продукт, которым пользуются все команды. Не набор регламентов, а работающий инструмент: создал новый сервис - получил сразу CI/CD, логирование, мониторинг, схему деплоя - по стандарту, без ручной настройки.
Почему это управленческий вопрос
Ускорение разработки - очевидный аргумент, но не главный для руководителя. Важнее другое.
Операционная прозрачность. Когда все сервисы устроены одинаково - инциденты расследуются быстрее, онбординг новых людей дешевле, аудиты проще. Хаос в инфраструктуре - это скрытые операционные издержки, которые плохо видны в бюджете, но хорошо ощущаются при кризисе.
Соответствие требованиям. Если компания работает в регулируемых отраслях - финансы, медицина, государственный сектор - то встроенные в платформу механизмы аудита, шифрования и контроля доступа решают половину вопросов на уровне инфраструктуры, а не на уровне отдельных сервисов.
Масштабирование без потери контроля. Рост числа сервисов без платформы - это экспоненциальный рост сложности. С платформой сложность управляется лучше.
Что это не значит
Платформа - это не серебряная пуля. Построить IDP - это само по себе продуктовый проект, требующий инвестиций и команды. Если компания небольшая и у неё 2-3 сервиса - это перебор. Разговор имеет смысл, когда команд несколько и боль от дублирования уже ощутима.
Кроме того, платформа, которую разработчики не используют - это потраченные деньги. Хороший IDP строится с учётом удобства тех, кто будет им пользоваться, а не только с учётом требований безопасности и операционного контроля.
Вопросы для оценки
- Сколько команд разработки в компании и насколько различаются их инфраструктурные практики?
- Сколько времени занимает онбординг нового разработчика до первого деплоя?
- Как устроено расследование инцидентов - есть ли стандартный набор инструментов у всех?
- Если завтра нужно добавить новый сервис - сколько раз придётся "изобретать велосипед"?
- Есть ли у компании команда, которая готова взять на себя платформу как продукт?
Если первые четыре вопроса вызывают лёгкую боль - разговор о платформе актуален. Пятый вопрос определяет, реально ли это делать сейчас.