fission-console/doc/thinking/2026-04-25-ai-opinions.md

Мнения AI-моделей об архитектуре Fission Console — 2026-04-25

⚠️ Всё ниже — МНЕНИЯ (не факты). Проверять и применять критически.

---

GEMINI — мнение (пересказ, апрель 2026)

Контекст вопроса: "написан сервис на основе Fission, многопользовательский, с Terraform"

Что сказал:

1. Изоляция: namespace-per-user — самый надёжный путь. Terraform при создании аккаунта создаёт Namespace + ResourceQuota + NetworkPolicy.

2. Fission в multi-tenancy: можно один инстанс Fission на весь кластер, но нужно патчить Router чтобы он понимал принадлежность Environment. Либо (сложнее) — отдельный инстанс Fission/пул экзекуторов на каждый namespace.

3. Terraform как Control Plane: кастомный провайдер должен управлять полным lifecycle — регистрация пользователя в БД, создание K8s ресурсов, создание Fission ресурсов. State изолирован между пользователями.

4. poolmgr vs newdeploy: poolmgr хорош для 100ms cold start, но при 1000 пользователей — RAM кончается (не масштабируется). Рекомендует NewDeploy + HPA для multi-tenant scale.

5. Безопасность выполнения: gVisor/Kata Containers (RuntimeClass=runsc). Для публичного облака — обязательно.

6. Схема: user → .tf файл → Terraform Worker → K8s Namespace+лимиты → Fission деплоит пакет → Router → внешний трафик в нужный Namespace.

Оценка контекста: Gemini отвечал на абстрактный вопрос "как строить managed serverless". Не знал деталей нашей реализации. Часть советов — для масштаба 1000+ пользователей.

---

GPT-4.5 — мнение (апрель 2026)

Контекст вопроса: тот же — многопользовательский managed serverless на Fission

Что сказал:

(Полный текст ответа не сохранён — пользователь описал его как "насочинял", детали были в чате)

⚠️ Полный текст GPT-4.5 не задокументирован. Пользователь охарактеризовал ответ скептически ("насочинял"). Считать неверифицированным.

---

Claude Sonnet 4.6 (я) — мнение (апрель 2026)

Контекст: знаю реальную реализацию (читал main.go, deploy/, repo memory)

Для масштаба ~20 одновременных пользователей:

Что реально надо доделать:

1. ResourceQuota + LimitRange на каждый user namespace — одна функция сейчас может сожрать все ресурсы кластера. Базовая безопасность, не опционально.

2. NetworkPolicy — без этого функции разных пользователей видят друг друга внутри кластера.

3. fission_simple_function Terraform ресурс — сейчас провайдер low-level: нужно вручную создавать Environment + Package + Function + HTTPTrigger. Нужен один высокоуровневый ресурс.

4. Поверхность ошибок в UI — при провале specialization пользователь видит "вероятно не удалось". Надо тянуть реальную причину (статус package, логи executor).

Что НЕ нужно для 20 юзеров:

• gVisor — лишняя сложность для контролируемой среды
• newdeploy вместо poolmgr — poolmgr нормально работает, достаточно подстроить poolsize
• Отдельный billing service — достаточно логировать invoke в postgres

Главный тезис: Gemini описал правильную архитектуру для SaaS на 10k пользователей. Для 20 — текущая архитектура достаточна. Нужна доводка, не redesign.

---

Текущее состояние реализации (факты, не мнение)

• namespace-per-user ✅
• auth token → user namespace ✅
• lazy environments per language ✅
• RBAC для системных и локальных SA (fission-fetcher, fission-builder) ✅
• TTL cleanup + reaper ✅
• NSReconciler для FISSION_RESOURCE_NAMESPACES ✅
• Route prefix per user ✅
• Terraform provider (low-level CRD) ✅
• ResourceQuota / LimitRange per namespace ❌ нет
• NetworkPolicy per namespace ❌ нет
• fission_simple_function Terraform ресурс ❌ не реализован
• Нормальная поверхность ошибок в UI ❌ частично
• gVisor/Kata ❌ нет (осознанное решение)
• Billing/metering ❌ нет