В начале 2025 года вышел отчет по состоянию внутренних платформ и порталов для разработчиков —
State of Internal Developer Portals 2025. Авторы отчета — компания Port.io, разрабатывает SaaS платформу для создания Internal Developer Portal (
IDP). В первом отчете в 2024 году авторы отметили, что отрасль находится на ранней стадии развития, в этом году сделан фокус на задачи, которые должен решать портал — с какими проблемами сталкиваются инженерные команды на всех уровнях, от разработчиков до CTO, от качества данных и ручной работы до количества инструментов и времени ожидания. Отчет подготовлен на базе опроса 300 респондентов, среди которых одна половина individual contributors, а вторая — руководители, из компаний в которых используется микросервисная архитектура (
microservice architecture) и cloud-native окружения (
cloud-native environments).
Ключевые выводы из отчета:
- 75% команд теряют от 6 до 15 часов в неделю из-за избыточного количества инструментов;
- 78% разработчиков ждут помощи от SRE и DevOps команд более одного дня;
- 50% разработчиков и инженеров не доверяют качеству метаданных;
- 94% разработчиков неудовлетворены внутренними платформами и порталами.
Подробные выводы из отчета:
- В начале отчета авторы отмечают, что принцип you build it, you run it привел к значительному росту сложности инженерных команд и способов их работы. От разработчиков теперь ожидается понимание и владение широким спектром навыков, выходящих за рамки их основных компетенций, включая управление инцидентами (incident management), облачными ресурсами (cloud resources), обеспечение качества (quality assurance), безопасности (security) и соответствия требованиям (compliance). В ответ на это крупные компании, такие как Spotify, Netflix и Lyft, начали создавать внутренние порталы разработчиков (IDP), чтобы снизить этот хаос, что стало катализатором развития платформенной инженерии (platform engineering). Создавая портал, который снижает когнитивную нагрузку (cognitive load) на разработчиков, представляющий собой единое консолидированное рабочее пространство для всего, что им необходимо, организации могут повысить продуктивность и вовлеченность разработчиков, а также улучшить качество своих приложений;
- Разработчики выполняют значительное количество эксплуатационных задач (operational tasks) в рамках своей повседневной работы, включая настройку новых окружений, создание новых сервисов и выполнение Day-2 задач (Day-2 operations). Лишь 11% разработчиков управляют этими задачами через внутренний портал разработчиков (IDP), что подчеркивает: подход к выполнению задач эксплуатации по-прежнему воспринимается как отдельный от других задач разработки. С этой точки зрения рынок IDP все еще находится на стадии формирования. Наиболее распространенные подходы: подготовить pull request с инфраструктурным кодом (IaC PR), выполнить задачу самостоятельно, использовать CI систему;
- Разработчики используют большое количество инструментов для выполнения повседневных эксплуатационных задач — для таких сценариев, как безопасность приложений (AppSec), управление инцидентами (incident management), качество кода (code quality) и других. В среднем команда использует 7,4 инструмента. В 43% случаев команды применяют более 8 инструментов. Это означает, что разработчикам необходимо уметь эффективно работать с большим количеством различных инструментов. Кроме того, они вынуждены регулярно переключаться между ними, что приводит к потере фокуса, увеличению времени выполнения задач и, как следствие, негативно влияет на продуктивность и опыт разработчиков (developer experience);
- 75% команд разработки теряют от 6 до 15 часов каждую неделю как прямой результат неэффективности, связанной с использованием множества инструментов для разных сценариев. Более высокая доля инженеров (81%) считает, что они теряют от 6 до 15 часов из-за избыточного количества инструментов и постоянного переключения контекста (context switching), по сравнению с инженерными руководителями (67%). Это объясняется тем, что инженеры напрямую сталкиваются с потерей времени в своей ежедневной работе, тогда как руководители часто находятся на некотором удалении от операционных деталей и хуже понимают масштаб проблемы;
- Большинство разработчиков способны выполнять действия в формате самообслуживания (self-service) в своей работе, несмотря на то что многие из них недовольны инструментами, которые используют для этого. Наиболее распространенные действия, которые разработчики могут выполнять самостоятельно: создание облачных ресурсов, определение того, соответствует ли сервис стандартам, шаблонизация нового сервиса. Лишь 25% инженеров имеют возможность самостоятельно выполнять Day-2 задачи (Day-2 operations), что подчеркивает потребность в инструментах, которые поддерживают более широкий спектр задач на протяжении всего жизненного цикла разработки сервисов (software development lifecycle, SDLC);
- Лишь 6% инженеров полностью удовлетворены платформами и инструментами в формате самообслуживания, тогда как 94% признают, что существует значительный потенциал для улучшений. Многие платформы и инструменты не достигают своих целей, поскольку по-прежнему требуют глубоких знаний базовой инфраструктуры. Большинство инструментов не предоставляют возможности опираться на стандарты и технические практики. Дополнительно такие инструменты часто страдают от некачественного UI, что снижает удобство использования;
- Одной из основных проблем взаимодействия для разработчиков является ожидание помощи со стороны команд DevOps или SRE. Более половины разработчиков (56%) ожидают помощи в среднем от одного до двух дней, тогда как более чем пятая часть (22%) ждет от трех дней до недели или дольше. На практике любое время ожидания снижает продуктивность разработчиков и негативно влияет на метрики, такие как среднее время восстановления (mean time to resolve, MTTR). Среди тех, кто использует внутренний портал разработчиков (IDP), доля респондентов со средним временем ожидания менее одного дня выше и составляет 30%;
- Наблюдается явный рост использования порталов для сбора метаданных: 23% респондентов используют внутренний портал разработчиков (IDP) для этого сценария, а 36% используют Backstage. Традиционные подходы, такие как Confluence, Jira, CMDB, а также электронные таблицы, часто подвержены ошибкам, статичны и в значительной степени зависят от ручного труда. Несмотря на эти ограничения, многие организации продолжают полагаться на такие инструменты — зачастую потому, что они инвестировали годы в их адаптацию под свои потребности, выстроили вокруг них процессы или просто сопротивляются изменениям, связанным с переходом на современные альтернативы. Такая зависимость может приводить к неэффективности, замедлению принятия решений и снижению масштабируемости, особенно по мере роста бизнеса и усложнения требований;
- Все опрошенные инженеры указали, что им необходимо вручную обновлять метаданные (software asset metadata), однако лишь 6% выполняют эту задачу ежедневно. В более чем половине организаций обновления выполняются только раз в неделю или даже реже. Это указывает не только на нехватку времени и ресурсов, но и на то, что данные, с которыми работают организации, не являются актуальными в реальном или почти реальном времени, что приводит к проблемам с точностью.
- Уровень доверия к качеству данных остается низким. Лишь 3% респондентов считают качество метаданных полностью надежным, а 50% сомневаются в их точности. Доверие к метаданным имеет критическое значение, поскольку без него разработчики с меньшей вероятностью будут опираться на эти данные и чаще будут обращаться к командам DevOps, SRE или другим коллегам за информацией. Идеальным состоянием является наличие единого источника истины (single source of truth) для этих метаданных. Разработчики, которые чаще сталкиваются с последствиями недостоверных данных, как правило, доверяют качеству данных меньше, чем руководители;
- Все опрошенные инженеры указали на наличие пробелов в соблюдении стандартов, что указывает на необходимость нового подхода к обеспечению соответствия стандартам (standards compliance). Без механизма гарантии, например, того, что сервисы находятся под мониторингом, 44% разработчиков могут не знать о проблемах с создаваемыми ими сервисами, что напрямую влияет на их удобство использования и надежность. Параллельно с этим ключевой проблемой остается владения сервисами (ownership). При отсутствии стандартов и инструментов возникает дефицит ответственности. Организационная структура часто не учитывается при анализе сервиса, из-за чего вопрос владения сервисами остается нерешенным. Совокупность этих двух проблем приводит к тому, что при возникновении инцидента разработчики не узнают о нем первыми, а команда, получившая оповещение, не понимает, с кем необходимо связаться;
- Хотя более половины респондентов (59%) согласны с утверждением, что сервисы соответствуют стандартам, 40% либо занимают нейтральную позицию, что указывает на неуверенность. Чтобы понять, насколько стандарты четко определены для разработчиков, авторы попросили респондентов оценить насколько разработчикам легко понимать стандарты, требуемые различными владельцами доменов (domain owners). Лишь 15% респондентов согласились с тем, что у них есть такая ясность, тогда как почти половина не согласились с этим утверждением. При отсутствии ясности инженеры не понимают, что именно от них ожидается, что приводит к несогласованности в разработке сервисов и повышенному риску того, что сервисы не будут соответствовать требованиям безопасности. В совокупности это негативно влияет на продуктивность, взаимодействие между командами и онбординг разработчиков.
Основные графики из отчета State of Internal Developer Portals 2025 приведены ниже: