От форка к Rust: как два года и четыре провала привели к собственной архитектуре SSH-клиента

ЗАГОЛОВОК От форка к Rust: как два года и четыре провала привели к собственной архитектуре SSH-клиента ===PREVIEW=== Российский разработчик МС22 рассказал, как создавал отечественный менеджер соединений: от форка open source-решения под жёсткий дедлайн до полной переработки backend на Rust. За два года команда прошла через четыре неудачные итерации, переписала интерфейс, самостоятельно реализовала RDP и VNC, добавила клиент баз данных и администраторские инструменты. История будет полезна всем, кто занимается импортозамещением или планирует собственную разработку на базе open source. ===DETAIL === Когда задача звучит как «нам через месяц нужен российский менеджер соединений, который можно официально купить», у команды остаётся не так много вариантов. Разработка собственного SSH-клиента с нуля за такой срок — гарантированный путь к бессоннице и провалу проекта. Поэтому в 2024 году МС22 выбрала прагматичный сценарий: взять open source, сделать форк, адаптировать под требования заказчика и примерно за 35 дней превратить импортозамещение в продукт, готовый к корпоративной закупке. Тогда никто не планировал, что следующие два года уйдут на переписывание интерфейса, споры с архитектурой Electron/NodeJS, самостоятельную переделку RDP и VNC, добавление клиента баз данных и десятка администраторских инструментов. Но главное — в итоге пришлось выбросить почти весь старый backend и переносить приложение на Rust.

Подробности

История МС22 — это не кейс «как мы всё сделали правильно с первого раза», а скорее набор решений, каждое из которых потребовало предварительной ошибки. Авторы честно признают: минимум четыре подхода пришлось сначала реализовать неправильно, чтобы понять, что вообще требуется делать. Хронология выглядит так: - 2024 год — старт с форка open source-решения. За 35 дней продукт был адаптирован под требования заказчика, переведён и подготовлен к закупке. Это позволило закрыть задачу импортозамещения в срок. - Далее — работа с интерфейсом. Первоначальная архитектура на Electron/NodeJS начала создавать ограничения, которые пришлось решать переписыванием UI. - Отдельное направление — RDP и VNC. Вместо использования готовых компонентов команда реализовала их самостоятельно, что потребовало значительных ресурсов. - Расширение функциональности — добавление клиента баз данных и набора администраторских инструментов, превративших продукт из SSH-клиента в полноценный менеджер соединений. - Финальный этап — отказ от прежнего backend и миграция на Rust. Это ключевое архитектурное решение, к которому команда пришла только после серии неудачных итераций. Отдельных CVE или уязвимостей в материале не упоминается — статья носит инженерно-продуктовый, а не security-характер. Тем не менее она напрямую касается вопросов импортозамещения в инфраструктурном ПО и практик разработки клиентов удалённого доступа, которые традиционно относятся к чувствительной зоне ИБ.

Что делать

Для команд, которые сталкиваются с похожими задачами — срочное импортозамещение, форк open source, жёсткие сроки — история МС22 даёт несколько практических выводов: - Оценивайте стоимость поддержки форка заранее. Быстрое получение продукта за 35 дней возможно, но дальнейшая эволюция почти наверняка потребует переписывания значительных частей кода. - Закладывайте ресурсы на смену технологического стека. Миграция с Electron/NodeJS на Rust — не косметическое улучшение, а полноценный проект, который стоит планировать с самого начала. - Не бойтесь пересматривать архитектурные решения. Четыре провала в данном случае не стали финалом, а дали понимание, что реально нужно продукту. - Учитывайте сложность самостоятельной реализации протоколов. Переделка RDP и VNC своими силами — это отдельная инженерная задача с высокой ценой ошибки. - Для заказчиков: наличие российского продукта, который можно официально купить, ещё не означает, что он стабилен архитектурно. Уточняйте roadmap и стек. Итог: путь от форка до собственной архитектуры занял два года и четыре неудачные итерации, но именно этот опыт позволил МС22 получить продукт, который они готовы развивать дальше. Для рынка импортозамещения это честный пример того, что быстрое решение редко бывает окончательным.

Источник: Хабр — Системное администрирование