Как обеспечить цифровой суверенитет IT-продуктов

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

Opensourсe vs. Proprietary

Как обеспечить цифровой суверенитет IT-продуктов

Практически любой цифровой продукт использует opensource, и мы не исключение - дорого и бессмысленно изобретать колесо заново, когда в открытом доступе можно найти шины Pirelli.

В архитектуре продуктов для управления знаниями это могут быть как мелкие точечные кусочки функционала, так и самостоятельные продукты типа Liferay (портальный конструктор), Elasticsearch (поисковая система), PostgreSQL (СУБД) и т.д. Elasticsearch и PostgreSQL – уже своего рода неофициальный отраслевой стандарт – сложно найти компанию, в которой не установлены эти решения или их форки*.

Даже для форков первоисточникпрактически всегда - иностранный ресурс. Поэтому с приходом санкций перед вендорами (и нами тоже) встали 2 задачи:

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

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

*Форк - копия открытого кода, на основе которой создается другой программный продукт. Например, LibreOffice можно считать форком OpenOffice.org.

*backdoor (букв. “черный вход, задняя дверь”) - дефекты алгоритма, которые намеренно встраиваются в него разработчиком.

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

Мы руководствуемся следующими правилами:

  • используем только софт, исходники которого доступны;

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

Серверы

Как обеспечить цифровой суверенитет IT-продуктов

Иностранные серверы и ЦОДы раньше использовались повсеместно. Как правило, инфраструктура зарубежных дата-центров была более современной: использовалось свежее оборудование, межсетевые экраны, более высокие стандарты качества и сервиса, был выше уровень безопасности и контроля хранения данных, индивидуальные SLA и т.д.

Например, многие компании с удовольствием пользовались услугами Hetzner, где цены были ощутимо приятнее, чем в российских ЦОДах.

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

У нас серверы всегда размещались в России. Во-первых, мы предоставляем свое решение не только on-premise, но и как готовый облачный сервис, а данные российских пользователей должны храниться на территории России.

Во-вторых, мы используем те же ЦОДы, что и многие наши клиенты. Это, в свою очередь:

  • повышает стабильность релиза – мы банально "набиваем шишки" на инфраструктуре, схожей с той, что будет у заказчика;
  • помогает воспроизвести непонятные фантомные проблемы заказчика, вызванные инфраструктурой, а не нашим ПО.

В общем, тут нам повезло, и проблемы срочного переезда с зарубежных серверов у нас не было.

Софт

Как обеспечить цифровой суверенитет IT-продуктов

Vendorlock - очень неприятная вещь. Поэтому мы изначально проектировали архитектуру таким образом, чтобы InKnowledge не зависела от конкретных сборок open-source-решений (того же Liferay или PostgreSQL).

Например:

  • Inknowledge без разницы – работать с PostgreSQL или Postgres Pro;
  • в зарубежных проектах мы могли ставить наши модули как поверх Liferay DXP (платная версия), т.к. там эта платформа более распространена, и у многих закуплены enterprise-лицензии, так и поверх "чистой" community edition, если она уже используется заказчиком.

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

Также есть Liferay Russian Edition - это форк нашего партнера EmDev, который мы помогаем развивать. Первые версии Russian Edition появились еще в 2018 году. Форк очень живой, последнее обновление было совсем недавно.

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

Остальные небольшие решения мы уже частично хранили и собирали на своих серверах. Часть пришлось оперативно зеркалировать с Гитхаба - весна 22-го у наших девопсов была жаркой. Тогда же мы с болью переезжали с Gsuite на “Яндекс 360”. Но это уже совсем другая история, которой мы когда-нибудь поделимся...

L2U (Listen2U) - один из ведущих российских разработчиков KMS-решений для корпоративного сегмента и госструктур. Компания основана в 2016 году в Москве. За 7 лет работы реализовано более 20 успешных проектов в России, Европе и на Ближнем Востоке, в том числе с «Медси», «Комус», «Локо-банк», Московской городской избирательной комиссией и др.

Продукты компании - система управления знаниями InKnowledge и омниканальная платформа L2U. InKnowledge входит в ТОП рейтингов ведущих систем управления знаниями России по версии CCGuru, FastKMS и PLUS-Consulting (1-е место, 2023 год). Включена в единый реестр отечественного ПО.

11
3 комментария

По поводу Liferay. Их портальный конструктор распространяется по лицензии Liferay Portal CE, зависимой от запретов вендора. А сама Liferay в своей экспортной политике зависима от политики США и возможных санкций. Ваше решение в своей основе использует их конструктор. Вы пишите, что развиваете собственные форки, но получается сейчас вы лишены обновлений от самой Liferay?

Ответить
Автор

У Liferay есть 2 типа - CE и EE. Для Российского рынка мы используем CE. Берутся исходники из github https://github.com/liferay/liferay-portal/blob/master/LICENSING.markdown - никаких экспортных ограничений для людей, использующих исходный код из данного репозитория нет - там LGPL (свободная программная лицензия). Коммерческая лицензия касается только подписчиков Liferay EE.

1
Ответить

К вопросу о форках и совместимости. Текущая поддерживаемая версия - 7.3, но западная компания Liferay Inc уже не вносит никакие изменения в эту версию (можете посмотреть историю коммитов в соотвествующий бранч на гитхабе). Плюс ряд изменений (например список регионов РФ) мировое сообщество вряд ли примет и запулреквестит на гитхаб (потому что в этом форке включены уже все новые регионы). При этом совместимость с основным ядром разработки (текущая версия 7.4) сохраняется. Все актуальные изменения зеркалируются на сервера РФ, сборки осуществляются самостоятельно (https://build.incomand.ru/view/LRE/job/liferay-ce-7.4.x/) На 24-ый год компания ЕМДЕВ запланировала переход на эту версию основного продукта - портала Incomand. Ранее этот переход не осуществлялся, так как версия 7.4 была еще в стадии разработки (новые релизы выходили каждые две недели) - что не совсем Enterprise история.

1
Ответить