Сегодня поговорим о важном – о цифровом суверенитете и возможности автономно развивать российские цифровые продукты в текущих условиях рынка. Тема важна не только для вендоров, но и для заказчиков – никому не хочется завтра внезапно остаться без какой-то части внутренней IT-инфраструктуры и важных данных. Мы расскажем, как обстоят дела у нас и почему именно так.
Opensourсe vs. Proprietary
Практически любой цифровой продукт использует opensource, и мы не исключение - дорого и бессмысленно изобретать колесо заново, когда в открытом доступе можно найти шины Pirelli.
В архитектуре продуктов для управления знаниями это могут быть как мелкие точечные кусочки функционала, так и самостоятельные продукты типа Liferay (портальный конструктор), Elasticsearch (поисковая система), PostgreSQL (СУБД) и т.д. Elasticsearch и PostgreSQL – уже своего рода неофициальный отраслевой стандарт – сложно найти компанию, в которой не установлены эти решения или их форки*.
Даже для форков первоисточник практически всегда - иностранный ресурс. Поэтому с приходом санкций перед вендорами (и нами тоже) встали 2 задачи:
В архитектуре продуктов для управления знаниями это могут быть как мелкие точечные кусочки функционала, так и самостоятельные продукты типа Liferay (портальный конструктор), Elasticsearch (поисковая система), PostgreSQL (СУБД) и т.д. Elasticsearch и PostgreSQL – уже своего рода неофициальный отраслевой стандарт – сложно найти компанию, в которой не установлены эти решения или их форки*.
Даже для форков первоисточник практически всегда - иностранный ресурс. Поэтому с приходом санкций перед вендорами (и нами тоже) встали 2 задачи:
- Защита от потери доступа к исходному коду – снятие риска невозможности внесения необходимых улучшений или исправлений;
- Защита от бэкдоров* и других уязвимостей, которые стали появляться в opensource решениях для ограничения использования странами под санкциями.
*Форк - копия открытого кода, на основе которой создается другой программный продукт. Например, LibreOffice можно считать форком OpenOffice.org.
*backdoor (букв. “черный вход, задняя дверь”) - дефекты алгоритма, которые намеренно встраиваются в него разработчиком.
Поэтому мы всей командой если и используем иностранный софт, то только тот, который не связан с рисками блокировки. Плюс сами дополнительно обеспечиваем безопасность для заказчика.
Мы руководствуемся следующими правилами:
*backdoor (букв. “черный вход, задняя дверь”) - дефекты алгоритма, которые намеренно встраиваются в него разработчиком.
Поэтому мы всей командой если и используем иностранный софт, то только тот, который не связан с рисками блокировки. Плюс сами дополнительно обеспечиваем безопасность для заказчика.
Мы руководствуемся следующими правилами:
- используем только софт, исходники которого доступны;
- исходники всех используемых решений должны храниться на российских серверах, которым не страшны санкции;
- в поставку заказчику должны идти только те версии, по которым мы видели исходники, сами сделали с них сборку, провели регресс-тестирование продукта;
- все это должно жить у нас в инфраструктуре.
Серверы
Иностранные серверы и ЦОДы раньше использовались повсеместно. Как правило, инфраструктура зарубежных дата-центров была более современной: использовалось свежее оборудование, межсетевые экраны, более высокие стандарты качества и сервиса, был выше уровень безопасности и контроля хранения данных, индивидуальные SLA и т.д.
Например, многие компании с удовольствием пользовались услугами Hetzner, где цены были ощутимо приятнее, чем в российских ЦОДах.
Потом в один совершенно понятный момент все это стало недоступно, либо стало требовать сложных окольных путей, а вендоры и заказчики получили еще одну фобию в копилочку.
У нас серверы всегда размещались в России. Во-первых, мы предоставляем свое решение не только on-premise, но и как готовый облачный сервис, а данные российских пользователей должны храниться на территории России.
Во-вторых, мы используем те же ЦОДы, что и многие наши клиенты. Это, в свою очередь:
Например, многие компании с удовольствием пользовались услугами Hetzner, где цены были ощутимо приятнее, чем в российских ЦОДах.
Потом в один совершенно понятный момент все это стало недоступно, либо стало требовать сложных окольных путей, а вендоры и заказчики получили еще одну фобию в копилочку.
У нас серверы всегда размещались в России. Во-первых, мы предоставляем свое решение не только on-premise, но и как готовый облачный сервис, а данные российских пользователей должны храниться на территории России.
Во-вторых, мы используем те же ЦОДы, что и многие наши клиенты. Это, в свою очередь:
- повышает стабильность релиза – мы банально "набиваем шишки" на инфраструктуре, схожей с той, что будет у заказчика;
- помогает воспроизвести непонятные фантомные проблемы заказчика, вызванные инфраструктурой, а не нашим ПО.
В общем, тут нам повезло, и проблемы срочного переезда с зарубежных серверов у нас не было.
Софт
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”. Но это уже совсем другая история, которой мы когда-нибудь поделимся...
Также есть Liferay Russian Edition - это форк нашего партнера EmDev, который мы помогаем развивать. Первые версии Russian Edition появились еще в 2018 году. Форк очень живой, последнее обновление было совсем недавно.
EmDev занимался Liferay много лет, до ухода вендора был золотым партнером, а после стал еще активнее развивать отечественный форк.
Остальные небольшие решения мы уже частично хранили и собирали на своих серверах. Часть пришлось оперативно зеркалировать с Гитхаба - весна 22-го у наших девопсов была жаркой. Тогда же мы с болью переезжали с Gsuite на “Яндекс 360”. Но это уже совсем другая история, которой мы когда-нибудь поделимся...