← [Раздел](README.md) · [Главная](../README.md)

# Serverless и FaaS

## Цель

Понять **serverless** как модель эксплуатации: функции как сервис (FaaS), событийные триггеры, ограничения по времени и состоянию, модель оплаты и когда serverless **дополняет**, а не заменяет контейнерный API.

## Предварительно

- [Монолит vs микросервисы](monolit-vs-microservices.md)
- Понимание HTTP API и очередей сообщений

## Время

~60 минут

---

## Что значит serverless

**Serverless** — вы не управляете серверами; провайдер масштабирует исполнение. Платите за **фактическое использование** (вызовы, GB-секунды).

Включает:

- **FaaS** — AWS Lambda, Cloud Functions, Azure Functions;
- **managed** БД, очереди, API Gateway;
- иногда **serverless containers** (Fargate, Cloud Run).

---

## FaaS — модель выполнения

```text
Событие (HTTP, S3 upload, cron)
    → провайдер поднимает sandbox
    → выполняется handler
    → sandbox уничтожается (или замораживается)
```

| Параметр | Типичное ограничение |
|----------|---------------------|
| Timeout | 15 мин max (провайдер) |
| Память | 128 MB – 10 GB |
| Cold start | 100 ms – несколько с |
| Локальный диск | Эфемерный, малый |
| Состояние в памяти | Не сохраняется между вызовами |

---

## Хорошие use cases

| Задача | Почему serverless |
|--------|-------------------|
| Обработка загруженного файла | Редкие пики, S3 trigger |
| Webhook от платёжки | Мало RPS, быстрый deploy |
| Cron-отчёт раз в сутки | Не держать VM |
| Прокси-трансформация JSON | Короткая логика |
| Постобработка событий из очереди | Авто-scale consumers |

---

## Плохие use cases

| Задача | Почему не serverless |
|--------|---------------------|
| Долгие WebSocket сессии | Модель не та |
| Низкая латентность p99 | Cold start |
| Тяжёлый CPU постоянно | Дороже VM/k8s |
| Монолитная логика 50k строк | Разбейте или контейнер |
| Жёсткие требования к сети | VPC complexity |

---

## Событийная архитектура

```mermaid
flowchart LR
  API[API Gateway] --> L[Lambda handler]
  S3[S3 bucket] --> L
  Q[SQS queue] --> L
  L --> DB[(DynamoDB)]
  L --> Topic[SNS / EventBridge]
```

Функции **компонуются** через события, не через прямые вызовы — слабая связность.

---

## Холодный старт

**Cold start** — инициализация runtime при первом или редком вызове.

| Смягчение | Описание |
|-----------|----------|
| Provisioned concurrency | Держать warm instances (дороже) |
| Меньший runtime / образ | Custom runtime оптимизация |
| Разогрев по cron | Хак, не гарантия |
| Архитектурно | Критичный sync path — на k8s |

---

## Безопасность и IAM

Каждая функция — **отдельная роль IAM** с минимальными правами:

```json
{
  "Effect": "Allow",
  "Action": ["s3:GetObject"],
  "Resource": "arn:aws:s3:::uploads-example/*"
}
```

Не одна «god role» на все функции.

---

## Стоимость

Платите за:

- число вызовов;
- GB-секунды памяти;
- исходящий трафик;
- связанные сервисы (API GW, DynamoDB).

При **стабильно высоком** RPS контейнеры на k8s часто дешевле — считайте **unit economics**.

---

## Serverless + Kubernetes

Гибрид распространён:

| Слой | Технология |
|------|------------|
| Core API, WebSocket | Deployment в k8s |
| Async workers | Lambda / Knative |
| Ingress | API Gateway → ALB → k8s |

**Knative** — serverless-абстракция поверх Kubernetes (scale to zero).

---

## Локальная разработка

- SAM, Serverless Framework, LocalStack — эмуляция.
- Всегда есть расхождение с облаком — **интеграционные тесты** в staging.

---

## Самопроверка

1. Что такое cold start?
2. Назовите два подходящих и два неподходящих сценария для FaaS.
3. Почему состояние нельзя хранить в глобальной переменной функции?
4. Когда k8s выгоднее serverless по деньгам?

---

## Дальше

→ [Антипаттерны и smells](anti-patterny-i-smells.md)  
← [Монолит vs микросервисы](monolit-vs-microservices.md)