Недавно компания Sonatype рассказала о том, какие ограничения ввела на использование бесплатной версии своего менеджера репозиториев. Это может существенно повлиять на малые и крупные организации, особенно в условиях санкционного давления на российский ИТ‑рынок. Рассказываем подробности.

Ключевые изменения в OSS-версии

Согласно новым правилам, развёртывания Sonatype Nexus Repository Community Edition теперь ограничены: 100 000 компонентов и 200 000 запросов в день. Если лимиты превышены, пользователи не смогут добавлять новые компоненты до тех пор, пока оба показателя не будут снижены. То есть блокировка активируется даже при превышении только одного из порогов (например, количества запросов) и требуется одновременное соблюдение обоих условий для восстановления функциональности.

Для кого это критично?

В малых компаниях (до 100–200 сотрудников) 200 000 ежедневных запросов — приемлемый объем для небольших команд. Однако даже они могут столкнуться с ограничениями. Крупные компании с миллионами запросов в сутки точно окажутся в сложной ситуации. В OSS‑версии и до этого были ограничения, затрудняющие интеграцию в масштабные инфраструктуры, а новые лимиты делают её практически непригодной для таких сценариев.

Новые правила касаются только последних версий Sonatype Nexus. Старые развертывания продолжат работу, но без доступа к обновлениям и исправлениям.

Ситуация на рынке с 2022 года

До 2022 года основными игроками в этой сфере были Nexus и Artifactory, которые занимают большую часть мирового рынка: Artifactory контролирует около 60%, а Nexus — порядка 35%. Однако после их ухода с российского рынка компании столкнулись с необходимостью поиска альтернативных решений. К 2025 году уже появились отечественные аналоги, способные частично или полностью заменить функциональность ушедших продуктов.

Проблемы существующих open-source решений

Ключевым open‑source решением, на котором начали работать многие компании, стал Nexus OSS. Он подходит небольшим компаниям, но у него есть ключевые проблемы:

• Ограниченная масштабируемость из‑за монолитной архитектуры.

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

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

• Использование встроенного в монолит поиска, который не может быть вынесен в отдельный сервис и файловой базы данных OrientDB, что увеличивает нагрузку на систему.

• Даже open‑source лицензия кому‑то принадлежит и может стать недоступной для использования в РФ.

• Кроме того, OSS‑версия Nexus не предполагает наличия исходников от всех модулей. Часть модулей OSS‑версии реализованных Sonatype не имеет открытых исходников и исправлять проблемы в таких модулях очень затруднительно.

• Одно из самых главных замечаний к OSS версии Nexus — это наличие гигантского количества уязвимостей.

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

Также после последнего обновления OSS‑версии компания Sonatype объявила о новых ограничениях, о которых я писал выше, что ставит корпоративный сегмент в ещё более сложную ситуацию.

Разработка собственного решения

Проведя много исследований, мы, команда платформы «Сфера», ещё в 2022 году увидели новый открытый рынок хранилищ артефактов. В России он создавался заново, и многие отечественные разработчики, сделав те же выводы, пошли по простому пути внедрения Nexus OSS в ядро своих продуктов. Мы, однако, уже тогда понимали, что полноценно использовать OSS‑версию Nexus в корпоративной среде не получится, поскольку нагрузка на инфраструктуру в крупном сегменте бизнеса растет слишком быстро.

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

Что нам нужно было от продукта:

• Поддержка архитектуры, которая будет соответствовать современным стандартам и лучшим практикам.

• Сервисы без устаревших и уязвимых библиотек. Такие сложные функции как полнотекстовый поиск должны поставляться в виде отдельных сервисов для удобства масштабирования и уменьшения рисков отказа основного функционала.

• Гибкое масштабирование хранилища артефактов.

• Работе в кластере.

• Безопасность хранения артефактов.

• Работа с ключевыми форматами репозиториев, такими как Maven, Docker, Helm, Yum, Apt и Raw.

• Безопасное подключение внутренних и внешних репозиториев.

• Поддержка новых версий Java.

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

Дистрибутивы и лицензии 2.0

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

При этом для решения конкретных задач в продукте мы использовали open-source решения, а не брали готовый OSS‑продукт и дорабатывали его. Этот подход позволяет нам заменять разнообразные части продукта в случае возникновения проблем с ним.

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