# Что такое облачное приложение

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

## Цель

Понять определение **облачного приложения**, чем оно отличается от локальной программы и от простого статического сайта, и из каких **частей** оно обычно состоит на высоком уровне.

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

- [Оглавление раздела 01](README.md)
- Пользовательский опыт: браузер, мобильное приложение

## Время

**2–3 часа** (чтение + упражнение со схемой)

---

## Простое определение

**Облачное приложение** — программа, чья **основная логика и данные** работают на серверах в дата-центре и доступны пользователю **по сети** (интернет или корпоративная сеть). Пользовательский интерфейс может быть:

- в браузере (веб-приложение);
- в мобильном приложении;
- в десктоп-клиенте — но данные всё равно часто приходят с сервера.

«Облако» здесь — метафора: вам не нужно покупать и ставить сервер в шкаф; вы **пользуетесь** вычислениями и хранилищем как услугой.

---

## Не облако vs облако

| Признак | Локальная программа (например, Excel без OneDrive) | Облачное приложение |
|---------|---------------------------------------------------|---------------------|
| Где данные | На вашем диске | На серверах провайдера (часто с копией у клиента) |
| Обновления | Вы скачиваете новую версию | Часто на стороне сервера без действий пользователя |
| Доступ с телефона | Ограничен или нет | Обычно да, через клиент или браузер |
| Совместная работа | Сложно в реальном времени | Заложено в архитектуру (несколько пользователей) |
| Масштаб | Один компьютер | Много серверов за балансировщиком |

**Статический сайт** (только HTML/CSS на хостинге) — пограничный случай: если нет логики на сервере и личных данных, это скорее «витрина», а не полноценное приложение. Как только появляются **логин, база, API** — это уже приложение.

---

## Учебный пример: «Умный список покупок»

Пользователь Анна:

1. Открывает приложение на телефоне.
2. Добавляет «молоко» в список «Продукты».
3. Муж видит тот же список на своём телефоне через 2 секунды.

Чтобы это работало, где-то в облаке:

- **принимается** запрос «добавить пункт»;
- **проверяется**, что Анна авторизована;
- **сохраняется** запись в базе;
- **уведомляется** второй клиент (push или при следующем запросе).

```mermaid
sequenceDiagram
  participant Phone as Телефон Анны
  participant API as Сервер API
  participant DB as База данных
  participant Phone2 as Телефон мужа
  Phone->>API: POST /lists/items (молоко)
  API->>DB: INSERT item
  DB-->>API: OK
  API-->>Phone: 201 Created
  Phone2->>API: GET /lists/shared
  API->>DB: SELECT items
  DB-->>API: данные
  API-->>Phone2: список с молоком
```

---

## Из чего состоит (упрощённо)

| Часть | Роль | Пример технологии (не обязательно знать сейчас) |
|-------|------|--------------------------------------------------|
| Клиент | UI, ввод пользователя | React, Swift, Android |
| API / backend | Бизнес-правила, авторизация | Node.js, Go, Python |
| База данных | Долговременное хранение | PostgreSQL |
| Кэш | Ускорение чтения | Redis |
| Файловое хранилище | Картинки, вложения | S3-совместимое хранилище |
| Внешние сервисы | Платежи, SMS, карты | Stripe, Twilio (как SaaS) |

Архитектор на этом этапе **не выбирает** конкретный язык — он **видит роли** и связи.

---

## Облачное приложение ≠ один сервер

На старте стартапа часто один сервер «и сайт, и API, и БД». Архитектурно всё равно полезно **мыслить слоями**:

```mermaid
flowchart TB
  subgraph clients [Клиенты]
    Web[Веб]
    Mobile[Мобильное]
  end
  subgraph cloud [Облако]
    API[Backend API]
    DB[(База данных)]
  end
  Web --> API
  Mobile --> API
  API --> DB
```

При росте API и БД **разделяют**, добавляют балансировщик и несколько копий API — это тема [раздела 06](../06-masshtabirovanie/README.md).

---

## Преимущества и компромиссы

| Плюс | Минус / риск |
|------|----------------|
| Доступ откуда угодно | Зависимость от интернета и провайдера |
| Централизованные обновления | Нужна эксплуатация 24/7 для критичных сервисов |
| Масштабирование | Сложнее, чем один .exe; нужны навыки |
| Оплата по использованию | Счёт может расти при неудачной архитектуре |

---

## Монолит и микросервисы (введение)

- **Монолит** — одно развёртываемое приложение со всеми функциями.
- **Микросервисы** — несколько маленьких сервисов (списки, пользователи, уведомления), каждый деплоится отдельно.

Для «Умного списка» на старте **монолит часто достаточен**. Микросервисы появляются, когда команда и нагрузка растут — не «потому что модно».

---

## Практика

1. Возьмите сервис, которым пользуетесь (банк, такси, мессенджер). Выпишите: клиент, что хранится в облаке, что должно работать офлайн.
2. Нарисуйте для учебного кейса три прямоугольника: Клиент → API → БД.

---

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

1. Почему нельзя отдать мобильному приложению прямой пароль от базы данных?
2. Чем облачное приложение отличается от сайта-визитки компании?
3. Назовите три компонента между телефоном пользователя и строкой «молоко» в базе.

---

## Дальше

→ [Модели облака](modeli-oblaka.md)