Обзор готовых решений для построения портала IDP и когда они не подходят: анализ на примере кейса компании Evrone

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

Меня зовут Александр Кириллов. Я СТО в компании Evrone. В этой статье я расскажу о наших предпосылках внедрения IDP, поиске вариантов реализации и объясню, почему иногда готовые решения не подходят.

Материал подготовлен по мотивам моего доклада на VK Kubernetes Conf. Вы можете посмотреть его запись здесь.

Об Evrone

Evrone создает сложные высоконагруженные проекты. Наша команда специализируется на продуктовой разработке, дизайне и техническом консалтинге. Мы разрабатываем ПО на заказ и делимся экспертизой с клиентами, которые хотят интегрировать в свои проекты новые технологии и подходы, в том числе DevOps.

В работе с DevOps мы придерживаемся следующих принципов: 

1. Выстраиваем одинаковые dev/stage-окружения, чтобы от проекта к проекту не строить новые «велосипеды», разбираться с которыми будет сложно и долго.

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

3. Обеспечиваем отчуждаемость инфраструктуры, чтобы безболезненно отдавать заказчику его проект.

Путь унификации

Одно из главных условий работы в нашей сфере — максимальная унификация подходов, инструментов и практик. Мы следуем этой парадигме. 

Унифицированные инструменты

Мы унифицировали базовый стек инструментов. В него вошли:

• Terraform,

• Kubernetes (kustomize, helm),

• CI (GitHub, GitLab),

• CD (GitOps) (FluxCD/ArgoCD).

С этими инструментами мы работаем в подавляющем большинстве проектов.

Единые шаблоны Terraform

Также мы унифицировали модули, с которыми работаем. Среди них:

• модули для управления облачными ресурсами (Managed K8s, Managed Postgres, Managed <svc-name>);

• модули для Bare-metal.

Это позволяет нам разворачивать типовую инфраструктуру в облаках (и не только) без необходимости постоянного изучения особенностей каждой отдельной платформы.

Единые шаблоны GitOps

Мы используем GitOps, чтобы автоматизировать доставку сервисов внутри окружения и приложений в эти окружения. Для однокластерных проектов с одним продуктом внутри это Single Tenant Cluster GitOps, для мультикластерных — часто multi-tenant-архитектура. 

При этом мы создали шаблоны структур GitOps-репозиториев под single-tenant и multi-tenant, поэтому при развертывании репозитория специалисту достаточно заимствовать готовое решение и лишь немного доработать его под проект. Это сокращает время разработки и обеспечивает унификацию.

«Слепые зоны» в observability

Вместе с тем даже выстроенной стандартизации в нашем случае было недостаточно. Нам не хватало observability, то есть прозрачности всех выполняемых процессов, что в условиях работы над проектами сторонних клиентов и даже в сторонних командах просто необходимо. В итоге в какой-то момент мы столкнулись с некоторыми ограничениями.

• Метрики по проектам были доступны только клиентам. Безусловно, в каждом окружении мы ставим Prometheus, Grafana, Loki и другие решения. Но, чтобы собирать и анализировать данные с них, надо отсматривать каждый проект отдельно. Единого UI с метриками по всем проектам не было и не хватало.

• Статус проектов можно было отслеживать только по тикетам. То есть узнать, что именно уже сделали специалисты, сколько потратили времени и что им еще предстоит сделать, можно, но только методом перебора каждого тикета в ручном режиме. В случае с аутстаф-проектами информация о статусах проектов часто оставалась «размытой».

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

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

Архитектура Internal Developer Platform

Internal Development Platform — внутренняя платформа разработки, которая является одним из вариантов реализации платформенного подхода. 

Фактически IDP представляет собой «коробку», в которой разработчикам доступны все преднастроенные инструменты, шаблоны, реализации, конфигурации, типовые конвейеры сборки, «разложенные» по соответствующим слоям.

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

• инфраструктурой,

• окружениями,

• приложениями,

• развертываниями,

• правами доступа.

Но надо понимать, что стандарта «наполнения» IDP нет и быть не может: каждая компания интегрирует в платформу те компоненты, с которыми работает. То есть «содержимое» IDP от компании к компании может кардинально различаться. 

Вместе с тем неизменным элементом IDP всегда является портал, который выполняет задачи единого окна для предоставления доступа ко всем компонентам, размещенным под капотом IDP.

Фактически портал — это UI, к которому интегрируются все компоненты и через который выстраивается вся работа команды разработки. Таким образом, одной из ключевых задач при построении IDP является выбор реализации самого портала.

Поиск решения

Наиболее распространенный путь компаний — поиск инструмента для портала среди доступных SaaS или Open-source-решений. В нашем случае вариант с SaaS однозначно не подходил: мы разрабатываем продукты для внешних клиентов и не можем навязывать им работу с платным решением. Соответственно, мы выбирали в основном среди Open-source, хотя поглядывали и на SaaS-решения. Рассматривали четыре варианта:

• Backstage,

• Port,

• DevTron,

• Seal (Walrus).

Backstage

Backstage — платформа с открытым исходным кодом, разработанная компанией Spotify и переданная Cloud Native Computing Foundation (CNCF) в 2020 году.

Инструмент служит внутренним порталом для разработчиков и упрощает процесс разработки, предоставляя единую и централизованную платформу для управления всеми аспектами жизненного цикла создания программного обеспечения.

Backstage — одно из самых популярных, но самых сложных решений. 

Инструмент способен решать широкий спектр задач. Среди них:

• ускорение адаптации специалистов (например, инженеров эксплуатации) при работе с продуктами;

• унификация экспертизы (DevEx) за счет изоляции всех инвариантов инструментов для гибкого перехода от одного проекта к другому и шаринга знаний внутри команды;

• Inner-sourcing, то есть предоставление информации о наборах сервисов, их работе, возможностях расширения инфраструктуры и других аспектах. Это полноценный Software Catalog;

• предоставление шаблонов для сервисов и компонентов, необходимых для сокращения времени подготовки продуктов, уменьшения дублей и минимизации ошибок, связанных с человеческим фактором;

• работа с метриками и визуализация данных от компонентов платформы.

Более того, решение поддерживает расширение функционала за счет добавления нужных сервисов.

То есть Backstage имеет несколько значимых особенностей:

• является полноценным фреймворком для IDP;

• позволяет использовать систему расширения в виде плагинов для создания интеграций с любыми внутренними и внешними сервисами;

• дает возможность гибко кастомизировать UI под задачи и особенности конкретного проекта.

Вместе с тем, как и упоминалось ранее, Backstage — довольно сложное решение. Причем сложностей немало:

• продукт вырос из Spotify и наследует ее специфические особенности инженерной культуры;

• инструмент надо глубоко адаптировать под процессы компании;

• на полную настройку инструмента требуется очень много времени, в отдельных случаях — до года;.

• для поддержки и разработки с помощью Backstage нужна специфическая экспертиза; 

• многие модули для Backstage пишутся на TypeScript, а DevOps не хотят работать с TypeScript.

В результате решение хорошее, но нам оно не подошло из-за причин, описанных выше, а также специфики нашей работы с клиентами: нет отчуждаемости инфраструктуры от IDP с сохранением функциональности.

Port

Port — решение для построения IDP на основе SaaS, которое имеет удобный интерфейс и низкий порог входа в работу. Инструмент предлагает набор готовых функций и интеграций, которые можно использовать для быстрого создания эффективного и удобного портала IDP. 

Одно из ключевых достоинств Port — большой набор компонентов, который позволяет закрыть потребности не только разработчиков, но и других специалистов команды. К таким компонентам можно отнести:

• Каталог сервисов и сущностей.

  

• Дашборды по рантайму и сервисам. Причем можно использовать не только базовые системы метрик, но и интегрировать готовые графики, например из Grafana.

  

• Инструменты для управления рантаймом и окружениями.

Помимо этого, Port дает возможность интегрироваться с внешними сервисами — работать с ними напрямую через API и получать от них данные напрямую в IDP. Более того, данные, поступающие в Port, могут быть как внешними интеграциями, так и экспортироваться из уже готовых систем (например, если есть готовый кластер в другом регионе).

Для тех, кому и этого мало, у Port есть проект Ocean. Это набор библиотек, с помощью которых пользователи могут расширить функционал инструмента под свои потребности.

Таким образом, Port:

• является полноценной инфраструктурной платформой;

• позволяет работать с любыми компонентами и источниками данных;

• обеспечивает высокий уровень observability;

• дает возможность настраивать свои процессы.

Вместе с тем нам Port не подошел. Причины две:

1. Нет отчуждаемости — Port полностью замыкает на себе. То есть мы не сможем полностью передавать проекты клиентам.

2. Работать с Port слишком сложно и избыточно для наших задач. 

Исходя из этого, от Port мы тоже отказались.

DevTron

Devtron — встроенная в Kubernetes платформа управления жизненным циклом приложений, которая глубоко интегрируется с продуктами, обеспечивая безопасность, отладку и наблюдаемость через интуитивно понятный UI. Платформа построена на базе Argo, Clair, Helm, Prometheus, Grafana и других.

К основным возможностям DevTron относят:

• возможность развертывания контейнеризированных приложений и сервисов любой сложности (даже простых лендингов);

• возможность работы с Helm-чартами через ArgoCD для деплоя более сложных инфраструктур с применением готовых компонентов;

• следование Application-centric-подходу (AppsOps), при котором ключевое значение имеют задеплоенные сервисы, которые можно фильтровать по проектам, окружениям, доступности и другим критериям;

• предоставление контроля над компонентами внутри платформы разработки, сущностями внутри приложений и их метриками — то есть полный доступ к ресурсам и логам;

• контроль над процессами сборки/релиза и возможность быстрой настройки пайплайнов развертывания из одной среды в другую.

То есть DevTron — вполне функциональный инструмент, который подходит под большинство кейсов:

• управление окружением основано на подходах AgroCD;

• он имеет простой в настройке и поддержке Flow деплоя;

• работа с окружениями/проектами выстроена в режиме единого окна;

• есть возможность контроля доступа и изоляции проектов.

Но даже при этом нам данное решение не подошло. Причина оказалась типичной: в DevTron «урезанный» GitOps, то есть все сущности, которые создаются для ArgoCD, создаются в рантайме внутри кластера Kubernetes, поэтому нет отчуждаемости. Для нас это критично.

Walrus

Walrus — компонент продукта SEAL, который представляет собой удобный и интуитивно понятный портал. 

У Walrus есть несколько поддерживаемых сущностей.

1. Коннекторы (connectors). Сущность, которая обеспечивает соединение с Kubernetes-кластером через kubectl и kubeconfig.

2. Проекты (Projects). Верхнеуровневая сущность, которая изолирует окружения, находящиеся внутри нее.

3. Окружения (Environments). Изолированная среда с развернутыми нагрузками и ресурсами. Окружения, как и проекты, можно гибко настраивать под конкретные кейсы.

4. Ресурсы (Resources). К ресурсам относят всевозможные сущности — от простейших подов до сложных продуктовых решений на базе шаблонов.

5. Шаблоны, то есть компоненты software-каталога на базе модулей Terraform. Это классические Terraform-модули, у которых есть inputs, набор ресурсов и outputs.

Среди «плюшек» у Walrus также есть поддержка Dependency Graph, который наглядно и максимально детализировано отображает все «слои» развернутых сущностей, а также связи и зависимости между отдельными модулями внутри этой сущности.

Также в Walrus есть workflow, который можно настроить, чтобы кастомизировать доставку сервисов или компонентов из одной среды в другую — пайплайн может быть любой сложности.

К сожалению, поддержка и разработка Walrus прекратилась 16 сентября 2024 года. Проект до сих пор OpenSource, но репозиторий находится в состоянии публичного архива.

Первые результаты поиска и промежуточные выводы

Фактически мы рассмотрели и изучили особенности множества популярных решений для развертывания портала IDP, но для Evrone с нашими «отягчающими» особенностями они просто не подошли. Причем в большинстве случаев барьеры типовые:

• нет изоляции по проектам/клиентам;

• нет отчуждаемости.

Для нас это критично: мы должны иметь возможность контролировать все проекты из одного окна и без проблем отдавать их клиентам. 

Надо понимать, что рассмотренные инструменты не плохие или недостаточно функциональные — просто они «не для нас». То есть вы вполне можете эффективно использовать одно из упомянутых решений, если:

• у вас нет сложных специфичных процессов, не укладывающихся в концепции приведенных выше решений;

• вы не мегакорпорация;

• вы можете использовать SaaS;

• вы более или менее статичны — вам не надо менять стек каждый месяц;

• инфраструктура и разрабатываемые продукты принадлежат вам.

Продолжение поисков

Первичный анализ рынка и доступных вариантов закончился для нас безуспешно. Но мы не стали на этом останавливаться.

Так, в процессе изучения первых четырех «кандидатур» нам на глаза попался один довольно интересный продукт — Gimlet. Изначально он не входил в фокус наших интересов, но после осознания «несоответствия» рассмотренных инструментов мы решили вернуться к нему и подробнее изучить решение.

Gimlet — это набор инструментов и модулей для построения платформы для работы с приложениями поверх Kubernetes. Решение построено на Helm и FluxCD, предоставляет набор практик и интеграций для повышения удобства разработки и консолидации всех компонентов IDP.

Нас заинтересовало то, что у Gimlet довольно любопытный набор особенностей. Так, инструмент:

• основан на «чистом» GitOps; 

• базируется на FluxCD, заимствует соответствующие процессы и технологии для построения конфигураций;

• имеет компонентную модель, которая дает возможность гибкого расширения решения нужными инструментами и сервисами (зачастую их достаточно включить и настроить);

• имеет компонентную модель изменений — это тот же GitOps.

В целом решение более чем интересное и даже частично соответствует нашим запросам:

• основан на «чистом» GitOps;

• позволяет использовать инструменты, с которыми мы уже работаем;

• обеспечивает отчуждаемость.

Но даже при этом в Gimlet конкретно на данный момент мы увидели для себя весомые недостатки:

• решение только начинает развиваться и для компании нашего масштаба с текущим набором требований еще сырое;

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

В результате и от этого варианта нам пришлось отказаться, но мы внимательно наблюдаем за его развитием.

Что в итоге

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

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