82 lines
5.5 KiB
Markdown
82 lines
5.5 KiB
Markdown
# Мнения 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 ❌ нет
|