Spring Framework и Spring Boot десятилетиями оставались ключевой основой для корпоративной Java-разработки. Но в августе 2024 года Broadcom сократил срок открытой поддержки этих продуктов до одного года и перевел долгосрочное сопровождение на коммерческую модель. К 2026 году даже платная поддержка версий Spring 6.x, на которых работает более половины российских разработчиков, будет прекращена.
Это событие стало тревожным сигналом для российского ИТ-сектора. Что оно означает для компаний, их архитектуры, безопасности и стратегических решений — разберем в статье.
Сокращение поддержки и зависимость от Spring
По данным международного исследования Snyk, около 60 % разработчиков по всему миру используют Spring Framework для своих основных приложений. Это делает его одним из самых распространенных инструментов в Java-экосистеме и фактически стандартом де-факто для корпоративной разработки.
Spring Framework — популярный фреймворк для разработки на Java, который упрощает работу с базами данных, интеграцию с сервисами и управление бизнес-логикой.
Сокращение поддержки Spring в России — не просто изменение графика релизов.
«Сегодня на Spring Boot работает значительная часть, даже вероятно, что более половины внутренних и клиентских Java-систем, особенно в банках, телекоме и в госсекторе».
Алексей Постригайло, старший партнер ИТ-интегратора «Энсайн»
По данным исследования TechRadar Java 2025, проведенного JUG Ru Group, почти 90% корпоративных разработчиков в России используют Spring для создания веб-приложений, а треть — до сих пор работают на версиях Spring Boot 2.x.
Spring Boot — это надстройка над Spring, которая позволяет запускать готовые к работе приложения буквально «из коробки». Он автоматизирует настройку, избавляет от сложных конфигураций и стал стандартом для создания микросервисов и корпоративных платформ.
Фреймворк достаточно глубоко укоренился в корпоративной разработке: любое изменение политики его поддержки отразится на тысячах проектов и командах по всей стране.
Компании, построившие свою инфраструктуру вокруг Spring, теперь сталкиваются с неопределенностью. Broadcom фактически повторяет стратегию Oracle с Java: продукт, изначально открытый и бесплатный, становится коммерческим. Для крупных компаний это давление на бюджеты и сроки — им приходится либо быстро искать альтернативные решения, либо оплачивать платную поддержку. А малый и средний бизнес рискует столкнуться с замедлением развития систем и увеличением рисков безопасности.
На практике влияние этих изменений зависит от зрелости конкретных проектов. Николай Голубев, архитектор-разработчик и техлид в ИТ-компании HFLabs, отмечает: «Проекты, в которых библиотеки обновляются регулярно (не реже чем раз в год), не почувствуют особых изменений. Проблемы могут возникнуть у legacy-проектов, которые уже активно не развиваются и находятся на поддержке, если в старых версиях Spring будут находить критические уязвимости».
Эксперт уверен, что сложившаяся ситуация открывает возможности и для отечественных разработчиков: они могут заняться обратным портированием исправлений и предлагать коммерческую поддержку на базе открытой лицензии Apache 2.0.
Сравнение лицензий привели к таблице ниже:
|
Параметр |
Раньше | Теперь |
|
Лицензия |
Apache License 2.0, без ограничений | Формально осталась Apache License 2.0, но без долгосрочной поддержки |
|
Обновления безопасности |
Бесплатно и регулярно в рамках open source | Только по платной подписке Spring Enterprise Subscription |
|
Исправления ошибок (багфиксы) |
Выпускались сообществом в открытом доступе | Доступны лишь в коммерческой версии |
| Срок поддержки OSS-версий | 3–5 лет, включая LTS-релизы |
Всего 6–12 месяцев, далее требуется миграция |
| LTS-версии | Бесплатно доступны всем пользователям |
Только для клиентов с Enterprise-подпиской |
| Миграция между версиями | Проводилась по необходимости, в удобное время |
Фактически обязательна каждые полгода для сохранения актуальности |
| Доступ из России | Полный доступ к репозиториям, обновлениям и артефактам Maven Central |
Доступ ограничен: санкционные риски, невозможность приобрести подписку, возможные блокировки репозиториев |
Зависимость от Spring вполне объяснима. По мнению Владимира Фризена, технического директора Smartech, «Spring «взял на себя» многие рутинные вещи, о которых разработчику приходилось заботиться самому, реализовывать вручную. Этим и объясняется его популярность».
«Сложно оценить затраты, вызванные прекращением поддержки этого фреймворка. Так как с его помощью уже разработано много продуктов, они точно будут немаленькими. И, что хуже, непродуктивными — не несущими каких-то положительных эффектов. Связано это с тем, что ничего нового это событие не дает, и кто будет платить за его последствия, непонятно. Еще один вопрос — будут ли приложения при отказе от данного фреймворка также эффективны».
Кирилл Семион, генеральный директор АНО «Национальный центр компетенций по информационным системам управления холдингом» (НЦК ИСУ)
«Боюсь, что для заказчиков это выльется в повышение стоимости сопровождения и развития существующих эксплуатируемых конечных продуктов из-за роста расходов у разработчиков», — сообщает эксперт.
Влияние на архитектуру и микросервисные системы
Изменение релизного цикла Spring напрямую отражается и на архитектуре. Для многих крупных организаций, где инфраструктура построена на десятках и сотнях микросервисов, любой сдвиг сроков или изменение модели поддержки становится чувствительным фактором. Например, Spring Boot остается основой большей части таких решений, поэтому даже незначительные изменения в релизной политике могут повлечь каскадные последствия — от задержек с обновлениями до нарушений совместимости сервисов.
По мнению экспертов, компании вряд ли станут резко перестраивать релизные процессы — большинство предпочитает действовать по принципу «не трогай, если работает». В результате все больше организаций выберет тактику «заморозки» стабильных версий: они продолжат использовать проверенные релизы, откладывая обновления до последнего.
«Возможны несколько сценариев. Первый сценарий — ничего не изменится и Legacy в больших компаниях продолжить жить, как и раньше. Второй сценарий — в ряде компаний появится или возобновится аргументация об обновлении версии фреймворка или миграции с него на другие. Но год жизни пока не выглядит страшным. Намного хуже, если пострадает качество самой экосистемы Spring и ее стабильность из-за смены владельца. В этом случае вопрос миграции встанет острее».
Константин Беседин, директор по разработке «НЕКСТБИ»
Однако подобный подход лишь временно снижает риски: отказ от обновлений ведет к накоплению технологического долга, усложняет интеграцию новых компонентов и повышает вероятность уязвимостей.
В больших системах с десятками микросервисов на Spring Boot может возникнуть новая сложность: версии фреймворка будут обновляться неравномерно, что приведет к проблемам совместимости.
Если релизы Spring станут ежегодными без поддержки LTS, часть сервисов будет оставаться на проверенных версиях ради стабильности, тогда как другие обновятся для исправления уязвимостей и новых функций, но перестанут полностью взаимодействовать с остальными. В результате CI/CD-процессы могут давать сбои из-за несовпадения зависимостей, включая Spring Cloud, Security, Data, Kafka, OpenFeign и другие.
«Это приведет к фрагментации ландшафта и росту технического долга — аналогично тому, как сейчас компании страдают от десятков версий Java или Python. В результате — возврат к идее платформенных слоев, где Spring заменяют на внутренние SDK или “core-модули”, контролирующие зависимости».
Максим Киреев, руководитель отдела разработки Angara Security
В итоге крупные организации рискуют столкнуться с парадоксом: стремление к стабильности приведет к заморозке версий, а попытки быстро закрывать уязвимости — к несовместимости и сбоям в CI/CD.
Пока компании ищут баланс между безопасностью, совместимостью и техническим долгом, на горизонте формируется новая задача — выстраивание внутренних платформенных слоев, способных взять под контроль разрозненные версии и зависимости.
Риски для безопасности и формального соответствия
Главная угроза после сокращения поддержки Spring — падение уровня безопасности.
«Spring — это веб-контроллеры, безопасность, сериализация запросов, авторизация. Исторически уязвимости в этих слоях быстро идут в эксплуатацию. После окончания открытой поддержки вы не получаете больше официальных CVE-фиксов и живете на заведомо уязвимой базе».
Дмитрий Свалов, технический директор компании BSS
Без регулярных обновлений старые версии фреймворка быстро становятся слабым местом корпоративной инфраструктуры. Уязвимости, обнаруженные в коммерческих ветках Spring, могут не доходить до публичных релизов, и бизнесу придется самостоятельно отслеживать исправления и интегрировать их вручную. Это повышает риск ошибок и требует дополнительных ресурсов.
Заметным последствием становится и регуляторный фактор. В отраслях с повышенными требованиями к ИБ — банковской, телекоммуникационной, госсекторе — использование устаревших версий фреймворков может обернуться не столько техническими, сколько юридическими проблемами. Даже при полной стабильности работы системы формальное отсутствие актуальных обновлений уже само по себе может быть расценено как нарушение стандартов безопасности.
Компании оказываются в непростой ситуации: игнорировать обновления, значит, рисковать безопасностью, а оставаться в рамках требований зачастую требует существенных затрат и ручной поддержки.
Наиболее устойчивый путь — создать внутренний контур контроля, от регулярного анализа уязвимостей и самостоятельного внедрения необходимых исправлений до постепенной миграции на поддерживаемые или отечественные аналоги. Такой процесс требует времени, но именно он позволяет сохранить контроль над безопасностью без зависимости от решений одного вендора.
Что предпринять сейчас
В условиях неопределенности полагаться на одного поставщика опасно — важно выстраивать долгосрочную устойчивость и самостоятельность инфраструктуры. А также:
Укрепить внутренние компетенции
Подготовить команды к миграции на новые версии или альтернативные фреймворки, чтобы при необходимости переход не стал шоком.
Внедрить DevSecOps-подход
Регулярно анализировать уязвимости, оперативно применять исправления и контролировать безопасность собственных решений.
Оценить технологические альтернативы
Помимо международных фреймворков вроде Micronaut и Quarkus, на рынке появляются и отечественные инициативы. Например, новая российская платформа Axiom Spring. В отличии от зарубежных аналогов, разработчики предоставляют компаниям полный контроль над жизненным циклом фреймворка.
Для бизнеса это означает реальную экономию: стоимость коммерческой поддержки часто оказывается ниже фонда оплаты труда двух разработчиков, в то время как самостоятельные миграции обходятся в десятки миллионов рублей и занимают от 6 до 12 месяцев.
Также существенно снижаются риски. Axiom Spring гарантирует регулярные CVE-фиксы и независимую проверку на соответствие ГОСТ Р 56939-2024, что минимизирует регрессии и срывы релизов. Командам это позволит переключиться с поддержки устаревающей инфраструктуры на создание новых сервисов для клиентов.
В свою очередь, разработчикам российская платформа даст возможность оставаться на проверенной версии без срочных и рискованных обновлений, получая при этом исправления уязвимостей через механизм backport-патчей — без изменения бизнес-логики. График обновлений будет определяться потребностями бизнеса, а не релизным циклом upstream-сообщества.
Резюме
Изменения в политике Spring заметно меняют ландшафт Java-разработки в России. Если раньше компании могли без опасений полагаться на стабильность и долгосрочную поддержку фреймворка, то теперь им приходится выстраивать собственные стратегии устойчивости. Одни выбирают коммерческую подписку, другие делают ставку на внутреннюю поддержку и адаптацию патчей, третьи — рассматривают переход на новую российскую платформу Axiom Spring.
Эпоха безусловной опоры на один зарубежный фреймворк уходит в прошлое. Речь не о потере доверия к Spring — он по-прежнему останется частью корпоративного ландшафта, как Java осталась основой разработки, несмотря на переход на коммерческую модель.
Сегодня компании пересматривают подходы к созданию и сопровождению решений на Spring, выстраивая архитектуру с прицелом на технологическую независимость. Особенно это важно для критической инфраструктуры, госсектора и крупных предприятий, где безопасность, предсказуемость и экономика жизненного цикла важнее «моды» на инструменты.
«Spring, как и Java, лежит в основе тысяч критически важных систем в России. А когда меняется жизненный цикл ключевых технологий, это всегда создает проблемы и требует пересмотра планов. Для отечественных компаний риски выше, поскольку даже open source-решения имеют владельцев за рубежом. При этом требования к устранению уязвимостей в системах КИИ остаются жёсткими. И сегодня особенно важно иметь надёжные и производительные отечественные альтернативы, чтобы выстраивать технологическую стратегию с опорой на них. Поэтому мы приняли решение расширить экосистему продуктов Axiom JDK и инвестировали опыт безопасной промышленной разработки в продолжение поддержки Spring в России».
Роман Карпов, директор по стратегии и развитию технологий Axiom JDK
Значимость мировых гигантов в отечественной ИТ-разработке постепенно снижается: появляются зрелые альтернативы, в том числе российские. Инженерная школа в стране сильна, поддержка Java ведется здесь почти с момента появления языка. Отечественные решения уже предлагают расширенные сроки LTS-поддержки, сертификацию ФСТЭК и совместимость с российскими платформами — то, что делает технологический выбор не только стратегически, но и экономически оправданным.