Обзор Developer-Led Landscape

В сентябре 2021 года эксперт Tyler Jewell опубликовал аналитический обзор Developer-Led Landscape и открытую базу компаний в репозитории на GitHub. Developer-Led Landscape представляет собой список компаний, чьи продукты продаются разработчикам, приобретаются под их влиянием или используются ими. Издание 2021 года включает 1004 компании и 1263 продукта. Первое издание вышло в августе 2020 года и включало 800 компаний и 1000 продуктов в 22 сегментах.

Ландшафт во многом пересекается с DevOps, при этом DevOps обычно исключает инструменты разработчика (например, IDE) и включает инструменты эксплуатации, которые не входят в рабочий процесс разработчика (например, мониторинг).

Определения и критерии Developer-Led Landscape
Ландшафт включает только продукты, которые приносят (или планируют приносить) выручку. Компании, создающие эти продукты, могут привлекать (или не привлекать) венчурный капитал. Ландшафт не включает Open Source проекты, поэтому совокупная активность в сегментах шире, чем показывает ландшафт. Продукты в списке могут распространяться для загрузки, предоставляться по модели SaaS (Software as a Service) или в виде управляемого сервиса (Managed service).

Определения категорий, сегментов и специализаций Developer-Led Landscape
Крупные группы в Developer-Led Landscape называются категориями:
  • жизненный цикл поставки ПО (Software Delivery Lifecycle, SDLC);
  • инструменты разработчика (Developer Tools, DT);
  • инфраструктура разработки (Developer Infrastructure, DI);
  • платформы для разработчиков (Developer Platforms, DP).

Продукты со схожими возможностями объединены в специализации. В зависимости от характера специализации автор иногда применяет вертикализацию (как в случае API как продукта, API as a Product) или горизонтальное деление (как в случае серверов приложений, App Servers). Некоторые специализации настолько детальны, что продукты могут относиться к нескольким специализациям и категориям. Если продукт логически подходит для нескольких мест, автор указывает его в одном месте, которое ближе всего к ценностному предложению продукта.

Сегменты представляют собой группы продуктов из разных специализаций, используемые для агрегированной отчетности. Тесно связанные специализации объединяются в сегмент.

Автор дает определения категорий, сегментов и специализаций в тех случаях, когда общепринятых определений нет или его определение отличается от общепринятого.

Категории Developer-Led Landscape:
  • Жизненный цикл поставки ПО (Software Delivery Lifecycle, SDLC). Процессные решения, которые координируют то, как команды проектируют, разрабатывают и тестируют программное обеспечение. SDLC включает сегменты, в которых создаются продукты, а во многих случаях и услуги и решения, влияющие на разработчиков на всем жизненном цикле разработки. Концептуально решения SDLC применяются во всех категориях: инструменты разработчика, инфраструктура разработки и платформы для разработчиков. Поставщики SDLC монетизируются за счет продажи корпоративных и индивидуальных SaaS подписок, лицензий и подписок на ПО для локальной установки (On-premises), маркетинга влияния (Influence marketing), например рекрутинга и показа рекламы, а также проектных и регулярных профессиональных услуг;
  • Инструменты разработчика (Developer Tools, DT). Индивидуальные инструменты (которые использует один инженер), облегчающие создание программного обеспечения. Поставщики DT монетизируются за счет продажи вендорских и индивидуальных SaaS подписок, лицензий и подписок на ПО для локальной установки, различных Open Source стратегий, включая Open Core и расширенную поддержку, а также Freemium моделей с оплатой за расширенные версии (или во многих случаях за покупку других продуктов, часто из категорий DI и DP);
  • Инфраструктура разработки (Developer Infrastructure, DI). Аппаратное и программное обеспечение, которое поддерживает распределенное и воспроизводимое создание программного обеспечения. Некоторые аналитики называют это цепочкой поставки программного обеспечения (Software Delivery Supply Chain). Если DT включает продукты для отдельного разработчика, то DI включает решения, от которых зависит команда инженеров. Поставщики DI монетизируются за счет продажи SaaS подписок, тарифицируемых по разным критериям (места, серверы, сокеты, контейнеры, проекты, репозитории исходного кода, пайплайны, потребление вычислительных ресурсов, потребление хранилища и т.д.), лицензий и подписок на ПО для локальной установки, различных Open Source стратегий, включая Open core и расширенную поддержку, а также Freemium моделей с оплатой за расширенные версии. Отдельно стоит отметить оценки, согласно которым затраты на эксплуатацию инфраструктурного стека, на котором работают продукты DI, составляют до 15% мирового потребления вычислительных ресурсов и хранилища. Компании, которые продают продукты DI и уже имеют прибыльное предложение по вычислениям и хранению, могут предлагать (в основном) бесплатные продукты DI в качестве убыточных лидеров, компенсируемых ростом потребления вычислительных ресурсов;
  • Платформы для разработчиков (Developer Platforms, DP). Среды выполнения, ориентированные на разработчиков, построенные по принципу Code-first и доступные только через API. Это продукты среды выполнения (Runtime), интерфейс которых требует участия инженера разработки или активы (Assets) для развертывания в которых должен создать разработчик. Поставщики DP монетизируются за счет оплаты по факту использования (Pay-as-you-go), тарифицируемой по разным критериям (за запрос, по потреблению вычислительных ресурсов и т.д.), SaaS подписок, тарифицируемых по разным критериям (места, серверы, сокеты, контейнеры, проекты, потребление вычислительных ресурсов, потребление хранилища и т.д.), лицензий и подписок на ПО для локальной установки, различных Open Source стратегий, включая open core и расширенную поддержку, а также Freemium моделей с оплатой за расширенные версии.

Сегменты Developer-Led Landscape:
  • RPA для DevOps (RPA for DevOps). Решения, которые автоматизируют развертывание и эксплуатацию инструментов разработки, чтобы ускорить путь от кода до релиза и снизить накладные расходы на сопровождение все более сложной инфраструктуры разработки;
  • Безопасность кода и приложений (Code + Application Security). Сочетание статического тестирования безопасности приложений (Static Application Security Testing, SAST), динамического тестирования безопасности приложений (Dynamic Application Security Testing, DAST), фаззинга (fuzzing), анализа состава программного обеспечения (Software Composition Analysis, SCA) и интерактивного тестирования безопасности приложений (Interactive Application Security Testing, IAST). Эти инструменты используют и инженеры по безопасности, при этом зачастую они ориентированы в первую очередь на разработчиков (Developer-first);
  • Инженерная эффективность (Engineering Efficiency). Решения, которые предоставляют инженерную аналитику (Engineering Intelligence) для прозрачности и рекомендаций по улучшению поставки программного обеспечения. Эти решения дают инсайты, которые используют все заинтересованные стороны: инженеры, продакт-менеджеры, представители бизнеса и руководители;
  • Управление потоком создания ценности (Value Stream Management). Поток создания ценности (Value Stream) это термин из Lean Movement, описывающий поток материалов и информации для создания ценности. Это последовательность действий, которые организация выполняет для удовлетворения потребности клиента. Поставщики решений для управления потоком создания ценности предлагают решения, которые повышают скорость движения элементов через поток создания ценности, как правило за счет связывания и интеграции множества нижележащих решений для разработки и эксплуатации.

Пересечения сегментов в Developer-Led Landscape:
  • SDK + серверы приложений (SDKs + Application Servers). Автор включил SDK в этот сегмент, поскольку это широкий термин, охватывающий множество библиотек и фреймворков, которые разработчики включают в создаваемое программное обеспечение. Многие поставщики SDK монетизируются в продакшене, и хотя между SDK и серверами приложений нет дублирующихся поставщиков, отнесение продукта к той или иной категории определяется субъективно;
  • CI + CD + автоматизация сборки (CI + CD + Build Automation). Автор отслеживает эти три сегмента отдельно. При этом функциональность этих продуктов все больше пересекается, и различия между ними становится все сложнее выделить, хотя они существуют;
  • CI + CD + GitOps. Поставщики CI/CD все чаще добавляют в свои предложения элементы GitOps. Многие поставщики GitOps описывают свои решения как разновидность CD. Наблюдается конвергенция управления конфигурациями и платформ CI/CD. Пока автор сохраняет эти категории раздельными;
  • Безопасность кода и приложений + конфигурация + GitOps + CI + CD (Code and Application Security + Config + GitOps + CI + CD). Безопасность кода и приложений включает множество подсегментов, связанных с проверкой и тестированием кода и систем. Рынок рассматривает статическое тестирование безопасности приложений (SAST), динамическое тестирование безопасности приложений (DAST), фаззинг, анализ состава программного обеспечения (SCA) и интерактивное тестирование безопасности приложений (IAST). Автор не включает в категории ландшафта защиту приложений во время выполнения (Runtime Application Self-Protection, RASP). Эти практики часто в упрощенном виде присутствуют в продуктах, которые также предлагают управление конфигурациями, GitOps, CI или CD. Компании, которые в основном предоставляют решения для безопасности кода и приложений, относятся к этой категории. Компании, для которых такие решения являются дополнительными, указаны в других категориях;
  • Серверы приложений + PaaS (Application Servers + PaaS). Границы между хостинговыми предложениями и загружаемым ПО размылись. Серверы приложений представляют собой платформы, на которых разработчики создают и запускают свои приложения в любой среде. Продукты Platform as a Service (PaaS) представляют собой хостинговые платформы для создания и запуска тех же приложений. Многие поставщики все чаще предлагают оба варианта: загружаемый сервер приложений, который также доступен как PaaS. Многие компании можно обоснованно отнести к любому из сегментов. Компания попадает в тот сегмент, где, по мнению автора, она получает большую часть выручки;
  • API как продукт + PaaS (API as a Product + PaaS). Ряд поставщиков, предлагающих API как продукт, также являются PaaS, особенно в областях интеграционных PaaS (iPaaS) и коммуникационных PaaS (cPaaS). Большинство поставщиков iPaaS включены в сегмент PaaS, поскольку от клиентов требуется создавать программные системы, которые развертываются и размещаются в облаке поставщика. Большинство поставщиков cPaaS включены в сегмент API как продукт, поскольку большая часть ПО использует вызываемые API. Такая же ситуация часто встречается у поставщиков headless CMS, которые предоставляют API для управления контентом и PaaS для размещения контента;
  • Low Code + PaaS. Несколько поставщиков предлагают Low Code решения для рабочих процессов, оптимизированные для интеграции. Это очень похоже на iPaaS. Некоторые поставщики iPaaS все чаще позиционируют свои продукты как Low Code или No Code. Отнесение продукта к сегменту Low Code или PaaS может быть субъективным;
  • API специализации (API Specializations). Автор отмечает, что многие поставщики предлагают функциональные продукты, специализирующиеся исключительно на API. Это касается IDE, автоматизации тестирования, безопасности и шлюзов. Для поставщиков, которые предлагают варианты продуктов только для API, автор выделяет специализации в этих сегментах.

Что не включено в Developer-Led Landscape:
  • Системные интеграторы и консультанты (System Integrators, SIs, and Consultants). Это большой и сложный рынок. Его измерение было бы идеальным, поскольку дало бы различные индикаторы того, какие технологии и продукты набирают или теряют влияние;
  • Данные и базы данных (Data and Databases). Многие продукты для работы с данными выбирают инженеры и архитекторы при проектировании приложений, поэтому их следовало бы включить в такое исследование. При этом этот сегмент активно освещают многие инвесторы и аналитики, и автор отразил бы его хуже. Кроме того, было бы сложно провести тонкую границу между продуктами для данных, которые выбирают разработчики, например MySQL, часто в процессе создания продукта, и продуктами, выбор которых не определяется разработчиками, например Snowflake в роли корпоративного облачного хранилища данных;
  • Поставщики управляемых сервисов (Managed Service Providers). Поставщики, которые размещают продукты других поставщиков в виде управляемого сервиса, не включены. Многие SaaS предложения включены (и используют технологии других поставщиков): такие поставщики включены, если, по мнению автора, для предоставления сервиса была создана значимая интеллектуальная собственность;
  • Open Source проекты и фонды (Open Source Projects & Foundations). В любом отдельном сегменте могут существовать сотни дополнительных Open Source проектов, которые влияют на его развитие. Отслеживать эти проекты было бы сложно из-за высокой скорости изменений. Эта работа помогает принимать более взвешенные корпоративные решения в отношении разработчиков и инвестиций. Отслеживание коммерческих компаний отражает готовность брать на себя обязательства и риски, что, в свою очередь, отражает общее влияние подобных технологий на индустрию;
  • Учебные организации (Training Outfits). Организации, специализирующиеся на обучении, будь то очное обучение с инструктором, веб-обучение или другие форматы, не включены в Developer Enablement. Developer Enablement относится к нетрадиционным формам взаимодействия с разработчиками, обычно связанным с построением сообщества, как Stack Overflow или Product Hunt;
  • No Code предложения (No Code Offerings). Некоторые аналитики относят к Low Code или No Code продукты с расширенными возможностями конфигурации, скриптинга или макросов. Например, SaaS приложение, которое автоматически генерирует маркетинговые лендинги без написания кода. Это отличное предложение, и многим компаниям стоит его купить, при этом такой продукт не является Low Code системой для создания приложений или других бизнес-систем;
  • Data Science. Большинство ноутбуков для Data Science требуют программирования моделей. Специалисты по данным наращивают собственные значительные технологические и программистские компетенции и для упрощения не включены в ландшафт. Ряд стартапов работает над тем, чтобы упростить специалистам по Data Science поставку возможностей машинного обучения в составе программного проекта. Возможно, в будущем стоит включить компании, которые объединяют практики программной инженерии с рабочими процессами Data Science;
  • MLOps. По аналогии с Data Science, MLOps представляет собой новый сегмент поставщиков, которые автоматизируют создание, развертывание, мониторинг и управление ML моделями. Архитектура и рабочие процессы решений MLOps похожи на технологии в сегментах инфраструктуры разработки и DevOps и ориентированы на рабочие процессы команд Data Science, создание и сопровождение моделей машинного обучения. Эти предложения часто пересекаются с рабочими процессами и инструментами разработчиков, при этом в организации их выбор не определяется разработчиками. В организациях появляются специалисты по эксплуатации ML, которые специализируются в этой области. Интересные взгляды на ландшафт MLOps представлены у LF AI Foundation, в блоге Fiddler, в блоге Google, у Blumberg Capital, Toward Data Science и TopBots;
  • Блокчейн (Blockchain). По тем же причинам, по которым исключены Data Science и MLOps;
  • Продукты отдельных поставщиков (Some Vendor Products). Некоторые компании выпускают несколько продуктов, которые выполняют схожие, но различающиеся функции в одном сегменте. В некоторых случаях пересечения настолько значительны, что автор считает их одним поставщиком и одним продуктом. В других случаях продукты достаточно различаются, и поставщик появляется в одной категории несколько раз;
  • События M&A (M&A Events). Когда Developer-led компании объединяются с другими компаниями (или прекращают деятельность), это событие изменения индустрии. Количество поставщиков в категории может сократиться, распределение выручки может измениться и т.д. Автор обновляет базу данных с учетом новой реальности, при этом не ведет журнал каждого события с датой и конкретными последствиями.
Если вам интересно развитие инструментов для разработчиков в вашей компании, обращайтесь к нам за помощью. Мы помогаем CTO, платформенным и продуктовым командам выявлять пробелы и дублирование инструментов и оценивать их влияние на продуктивность и Developer Experience.

Вступайте в сообщество Enabling Community и подписывайтесь на наш канал Enabling.team Insights, чтобы оставаться в курсе технологических трендов.