A Tale of Two Fludes: Архитектурное разделение Enterprise и SaaS-моделей
· 3 min read
Выделение специфичного кода в независимый приватный сабмодуль, описанное в предыдущей статье, позволило нам стабилизировать ядро движка. Юридические границы были очерчены, а базовая архитектура — умный парсер и двухуровневое кэширование — доказала свою эффективность.
Следующим логическим шагом был переход от внутреннего инструмента к коммерческому продукту. Однако на этом этапе мы столкнулись с фундаментальным противоречием между корпоративной моделью эксплуатации и требованиями массового рынка.
Иллюзия универсальной дистрибуции
Изначально архитектура Flude формировалась в рамках разработки системы для крупной корпорации. Требования к безопасности в таких условиях категоричны: инструмент обязан функционировать в закрытом контуре, гарантируя, что исходный код никогда не покинет периметр серверов компании.
Для решения этой задачи мы интегрировались напрямую. Пакет со скриптами передавался заказчику и запускался локально в их CI-конвейере, считывая файлы конфигурации непосредственно из репозитория. В рамках корпоративной среды такая модель поставки исходного (или байт-кода) идеальна: закрытый периметр и строгие юридические обязательства надежно гарантируют сохранность интеллектуальной собственности.
Однако при планировании масштабирования на публичный рынок стало очевидно, что прямое копирование Enterprise-подхода к дистрибуции технически и концептуально неприменимо.
Потеря контроля над распространением
Модель закрытых контрактов отлично работает в Enterprise-секторе, но для обеспечения стабильного роста продукту необходим выход на массовый B2B/B2C рынок: к небольшим командам и независимым разработчикам.
Очевидная проблема заключалась в том, что передача исходных Python-скриптов или готового Docker-образа пользователям вне рамок корпоративных соглашений неизбежно ведет к потере контроля над распространением продукта. При отсутствии жестких юридических барьеров открытая дистрибуция технически позволяет обходить механизмы лицензирования и неконтролируемо тиражировать ядро системы.
Следовательно, подход, являющийся стандартом для доверенной корпоративной среды, оказался структурно несовместимым с публичной бизнес-моделью.
Расхождение путей (The Divergence)
Для обеспечения защиты ядра продукта нам потребовалось пересмотреть саму парадигму доставки. Архитектура Flude была физически разделена на две независимые модели:
- Enterprise Flude: Автономное, локальное решение. Поставляется исключительно в рамках целевых контрактов. Функционирует оффлайн, обрабатывает код локально и интегрируется с конфигурацией непосредственно в репозитории клиента.
- SaaS Flude (Публичный рынок): Облако-ориентированная модель. Ядро парсера никогда не передается конечным пользователям. Вместо этого предоставляется «тонкий клиент» (легковесные CI-скрипты), задача которого — исключительно упаковка исходных файлов и их безопасная передача по API. Вся вычислительная нагрузка и логика парсинга остаются инкапсулированными на наших серверах.
Переход к облачной архитектуре и неожиданная польза бинарников
Приняв SaaS-модель, мы обезопасили свои алгоритмы, но существенно усложнили техническую реализацию. Предстояло с нуля спроектировать распределенную систему, способную принимать и обрабатывать сторонний код.
Интересно, что именно на этом этапе концепция “единого бинарника”, от которой мы отказались для публичной дистрибуции, оказалась спасением для нас самих. Чтобы не управлять сложными Python-окружениями и зависимостями на каждом облачном воркере, мы скомпилировали наше ядро. Автономный бинарник стал идеальным решением для быстрого запуска внутри нашей собственной SaaS-инфраструктуры (а впоследствии — и удобным форматом поставки для Enterprise-клиентов).
О том, как мы спроектировали облако с учетом концепции Zero-Trust, и почему конфигурационные файлы, безупречно работавшие локально, превратились в SaaS в критический вектор атак (RCE), мы расскажем в следующем эпизоде.