Подобно русской матрешке, IDP (internal developer platform, внутренняя платформа для разработчиков) — это слой поверх SSP (self-service portal, портал самообслуживания разработчиков), который предлагает инструменты для оптимизации всего жизненного цикла разработки ПО. А SSP — это про функциональность и автоматизацию для всех участников процесса, пишет на портале The New Stack Бенджамин Бриал, основатель компании Cycloid, занимающейся платформенным инжинирингом.
В 2007 г. мир познакомился с DevOps. Этот подход предполагает объединение команд разработчиков и операторов для ускорения развертывания и повышения эффективности и усиления взаимодействия в жизненном цикле разработки ПО. Считается, что он в два раза быстрее традиционного подхода.
Тем не менее, согласно отчету Synopsys «State of DevSecOps 2023», только 9% компаний используют исключительно DevOps, и только 20% — более чем в половине разработок. Почему же при столь очевидных преимуществах этот подход так мало распространен? В отчете также говорится о том, что 80% организаций испытывали трудности с внедрением DevOps в течение последних пяти лет.
Улучшение опыта разработчиков (DevX) было названо ключевым фактором, способствующим росту числа пользователей DevOps. Положительный опыт разработчиков повышает производительность. DevX влияет на то, насколько эффективно разработчики пишут, тестируют и развертывают код. Разработчики охотнее принимают и поддерживают инструменты и технологии, которые обеспечивают бесперебойную и интуитивно понятную работу.
Однако акцент сместился с создания лучших условий для разработчиков на то, чтобы сделать процессы более интуитивно понятными и привлекательными. Этой цели служат зарождение платформенного инжиниринга и создание IDP, которые предлагают курируемые инструменты и сервисы — конвейеры CI/CD, контейнеризацию, инструменты мониторинга и т. д. — для обеспечения самообслуживания разработчиков.
До сих пор это было полезно только для разработчиков. Но как насчет других, менее технических, заинтересованных сторон в организации, которые также вовлечены в потребление ИТ-инфраструктуры? Архитекторы решений, ITOps, DevOps, FinOps, команды безопасности и сетевые команды — все они вносят свой вклад в бизнес, но не являются профильными разработчиками.
Хотя в определении Gartner платформенный инжиниринг в значительной степени сфокусирован на DevX, это лишь одна часть головоломки. По-настоящему эффективная платформа должна быть предназначена не только для разработчиков, но и для гораздо более широкого круга команд.
Порталы самообслуживания
Даже в лучшие времена легко потеряться в море ИТ-аббревиатур, и это касается и экосистема платформенного инжиниринга — особенно если учесть, что IDP и SSP, казалось бы, обещают похожие вещи, а на деле, как оказывается, — совершенно разные. Для многих организаций выбор или создание IDP может быть тем, что, по их мнению, требуется для того, чтобы избавить своих разработчиков от повторяющейся работы, тогда как SSP нужен для оптимизации автоматизации.
При правильном использовании SSP может стать мотором процесса цифровой трансформации организации. Он предоставляет возможности управления для определения ролей, каталог услуг для повышения эффективности и автоматизацию, которая решает ручные задачи и сокращает количество человеческих ошибок для всех команд в организации, которые потребляют ИТ-инфраструктуру, но, что очень важно, не являются профильными разработчиками.
Выступая в роли связующего звена между командами, такие пользователи, как руководители проектов, QA-тестировщики и даже заинтересованные стороны из бизнеса, могут с помощью SSP получить доступ к полезным инструментам управления и автоматизации. Эти инструменты позволяют «не-разработчикам» следить за проектами, выявлять узкие места и получать инсайты о процессе разработки без необходимости иметь глубокие технические знания.
SSP также поощряют сотрудничество, которое должно быть заложено в каждом уголке портала. Общие репозитории позволяют пользователям, которые обычно зависят от технических навыков выделенного разработчика, хранить код с автоматизированным контролем версий, чтобы все работало гладко, а также проводить обзоры кода, чтобы убедиться, что все находятся на одной волне.
Такая бесперебойная работа на разных платформах очень выгодна для гораздо более широкого круга пользователей, так в чем же проблема?
Эффект матрешки
Во-первых, нужно определить потребности. Для многих организаций приобретение или создание IDP, которая устранит операционные издержки и обеспечит самообслуживание разработчиков, звучит как простое решение, но существует некоторая путаница в определении того, что такое IDP на самом деле и как ее получить.
Backstage, платформа Spotify с открытым исходным кодом, наделала много шума в области платформенного инжиниринга, предложив систему плагинов, которая делает IDP чрезвычайно настраиваемой и удобной для совместной работы. Однако в реальности все обстоит несколько иначе, и такой подход «сделай сам» может сделать весь процесс еще более запутанным.
Именно здесь целостный подход полезен для обеспечения контроля за разработкой. Он даст возможность всем пользователям — менеджерам, финансовым директорам и даже специалистам по устойчивому развитию — отвлечься от повседневных задач по разработке ПО и взглянуть на картину в целом.
Предоставляя удобный интерфейс для определения и развертывания облачных ресурсов, SSP освобождает от необходимости тратить время и силы на создание сложных конфигураций инфраструктуры. Централизация ресурсов обеспечивает надзор, а также позволяет установить ограждения для защиты от развертывания теневых ИТ. Это помогает не только выявить неиспользуемые ресурсы, что позволяет сэкономить деньги, но и сделать облачные технологии более экологичными за счет удаления ненужных ресурсов.
В этом заключается основное различие между SSP и IDP, и понимание того, какие возможности необходимы организации, имеет решающее значение для обеспечения беспроблемного внедрения платформенного инжиниринга. Подобно русской матрешке, IDP — это слой поверх SSP, который предлагает инструменты для оптимизации всего жизненного цикла разработки ПО. А SSP — это про функциональность и автоматизацию для всех участников процесса.
Большая матрешка — это инженерная платформа, та самая сложная часть, которая объясняет, почему путь к платформенному инжинирингу занимает примерно три года. Это комплексное решение выходит за рамки SSP и IDP. Инженерная платформа — это всеобъемлющая концепция, которая охватывает множество функций, включая управление ресурсами, взаимодействие с экосистемой и интеграцию плагинов. Разработанная для людей с любым уровнем подготовки, она предлагает удобный интерфейс и настраиваемые функции для удовлетворения различных потребностей и рабочих процессов.
Взаимосвязь между всеми тремя слоями напоминает головоломку, в которой важна каждая мелкая деталь, даже если на первый взгляд она кажется незначительной. Как уже говорилось, DevOps прошел долгий путь с
