Отчет Port «2024 State of Internal Developer Portal» показывает, что инженеры все активнее используют внутренние порталы для разработчиков (internal developer portals, IDP) в рамках подхода платформенного инжиниринга (platform engineering), пишет на портале The New Stack Сурадж Шах, директор по контент-маркетингу компании Port.

Мы знаем, что платформенный инжиниринг, имеющий большой потенциал для разрушения внутриорганизационной разрозненности, набрал ход в уходящем году. Его ключевой движущей силой являются IDP, которые получили широкое распространение в 2023 г., поскольку инженерные руководители стремились снизить когнитивную нагрузку на разработчиков, повысить их производительность и улучшить инженерные стандарты.

Но вместо того чтобы предполагать, насколько сильна эта тенденция, мы решили узнать у инженерных руководителей, как на самом деле обстоят дела в их компаниях с развивающейся дисциплиной платформенного инжиниринга и основным инструментом для ее развития. Поэтому мы опросили 100 таких руководителей из компаний, использующих микросервисную архитектуру в производстве, и расспросили их о текущих развертываниях, а также об их мыслях и мотивах, побуждающих к применению платформенного инжиниринга и IDP.

Платформенный инжиниринг и IDP идут рука об руку

Мы обнаружили, что практически все (99%) опрошенные нами руководители инженерных подразделений уже используют платформенный инжиниринг в своих организациях, причем 53% сообщили, что начали это делать в течение последнего года. При этом подавляющее большинство респондентов (85%) заявили, что либо уже начали внедрять IDP, либо планируют сделать это в ближайший год.

Очевидно, что компании стремятся внедрять порталы в качестве основной составляющей платформенного инжиниринга; эти два элемента идут рука об руку, и инженеры признают, что IDP служит для разработчика интерфейсом к платформе. Почти все хотят иметь внутреннюю платформу для разработчиков, и порталы — это способ достижения этой цели.

Однако существуют различия, связанные с размерами компаний. В небольших компаниях, где работает менее 300 разработчиков, порталы используются реже (43%), чем в крупных компаниях (57%). Это вполне логично, учитывая, что платформенный инжиниринг и IDP опираются на более крупные инженерные команды, где обычно выше сложность микросервисной архитектуры, потребность в адаптации разработчиков и разрозненность DevOps-разработчиков. Однако небольшие компании не стоят на месте: 45% планируют добавить портал в течение следующих 12 месяцев, по сравнению с 26% в крупных организациях. Таким образом, независимо от размера компании в ближайшие 12 месяцев внедрение платформенного инжиниринга и IDP будет расти.

Что такое внутренний портал для разработчиков?

В наших результатах не было ничего удивительного, пока мы не спросили респондентов, которые используют или планируют использовать портал, о его типе. В то время как более половины (53%) используют то, что обычно определяется как IDP, будь то Backstage, портал на основе коммерческого продукта или самописный портал, 35% респондентов назвали своим «порталом» электронные таблицы с данными микросервисов. И это несмотря на то, что такой подход — в высшей степени ручной и без возможностей самообслуживания — является именно тем, от чего IDP призваны избавить организации. Еще 12% заявили, что используют в качестве портала интерфейс самообслуживания на базе CI.

Возможно, рынок ошибочно полагает, что возможности каталога ПО в электронной таблице или CI-самообслуживания реализуют внутренний портал для разработчика. Поскольку это все еще развивающееся пространство, со временем инженеры будут лучше понимать суть и преимущества настоящего портала.

Четыре ключевых столпа, на которые следует обратить внимание руководителям инженерных служб, следующие:

  • Каталог ПО. Существуют различные типы каталогов ПО, на которые может опираться портал, но на самом деле акцент должен быть сделан на том, чтобы организация могла выбрать свой собственный каталог, будь то каталог CI/CD или каталог, основанный на данных облачных ресурсов или GitOps. Он должен выступать в качестве центрального хранилища метаданных о ПО, средах, ресурсах, конвейерах, CI/CD, облачных ресурсах — по сути, обо всем, что нужно разработчику. И он должен показывать разработчикам абстракции данных, помогая облегчить когнитивную нагрузку за счет редактирования и белых списков.
  • Самообслуживание разработчиков. Одним из основных преимуществ платформенного инжиниринга является повышение качества работы разработчиков, и самообслуживание на портале является ключевым фактором, позволяющим разработчикам свободно переключаться (при наличии соответствующих ограждений и мер контроля). Идея состоит в том, чтобы создать самообслуживание по требованию поверх любой автоматизации, созданной командами платформы или DevOps. В идеале интерфейс портала должен работать в один клик, быть последовательным и отделенным от инфраструктуры. Портал должен отражать потребляемые ресурсы в каталоге ПО и их коррелированное состояние в режиме реального времени, а также быть оснащен средствами контроля доступа на основе ролей и журналом аудита.
  • Автоматизация. Облегчение жизни разработчиков должно включать автоматизацию. Это означает, что она может программно запускать оповещения или рабочие процессы DevOps; завершать работу среды или отправлять оповещения при ухудшении показателей служб; запускать рабочие процессы, связанные с управлением ресурсами, исправлением ситуации, выделением ресурсов, эскалацией инцидентов, исправлением ситуации с безопасностью, мониторингом сервисов, обновлением каталогов и т. д.
  • Оценочные карты и инициативы. Обеспечьте качество и стандарты для инженерной организации, используя оценочные карты (scorecards), чтобы определить метрики качества, готовности к производству и производительности разработчиков/DevOps. Убедитесь, что показатели могут быть контекстуализированы для конкретных подразделений, поскольку это поможет донести стандарты и обеспечить видимость в организации. В то же время, вместо того чтобы рассылать повторяющиеся сообщения с просьбой обновить графики или версии, можно собрать все в одном месте на портале, чтобы организации могли сообщать об инициативах и легко отслеживать их по разработчикам, командам и службам.

Готовый портал для разработчиков также должен быть оснащен инструментальными панелями и визуализациями.

Хотя из нашего исследования видно, что организации все чаще используют IDP в качестве части своего подхода платформенного инжиниринга, также очевидно, что руководители все еще пытаются разобраться в различных составляющих и понять, как различные элементы взаимодействуют между собой, чтобы обеспечить применимость и надежность. Поскольку эта сфера еще очень нова, некоторые в отрасли до сих пор подходят к платформенному инжинирингу с использованием ручных методов, а не внутреннего портала для разработчиков, и надеются, что им удастся получить те же преимущества. Со временем станет очевидно, что таким образом они с этой задачей не справятся.