# Мнения 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 ❌ нет