4. Дополнительные модели

4.1. FaaS / Serverless (Function as a Service)

Часто рассматривается как эволюция PaaS. Пользователь загружает не целое приложение, а отдельные функции (куски кода). Платформа сама запускает функцию в ответ на событие (HTTP-запрос, загрузка файла, сообщение в очереди) и масштабирует её.

Примеры: AWS Lambda, Google Cloud Functions, Яндекс.Облако Functions, Azure Functions.

Для кого: Разработчики микросервисов и событийно-ориентированных приложений.

4.2. CaaS (Containers as a Service)

Предоставление среды для запуска и оркестрации контейнеров (Docker, Kubernetes). Пользователь управляет контейнерами, а провайдер — кластером.

Примеры: Amazon EKS (Kubernetes), Google Kubernetes Engine (GKE), Azure Kubernetes Service (AKS), Яндекс.Облако Managed Kubernetes.

4.3. DBaaS (Database as a Service)

Управляемые базы данных. Провайдер предоставляет готовую БД (MySQL, PostgreSQL, MongoDB, Redis) и берёт на себя администрирование, резервное копирование, обновления.

Примеры: Amazon RDS, Google Cloud SQL, Яндекс.Облако Managed Databases.

5. Сравнительная таблица моделей

Характеристика	On-Premise	IaaS	PaaS	SaaS
Пример	Собственный сервер в офисе	Amazon EC2	Google App Engine	Google Workspace
Управление приложением	Клиент	Клиент	Клиент	Провайдер
Управление данными	Клиент	Клиент	Клиент	Провайдер
Управление рантаймом	Клиент	Клиент	Провайдер	Провайдер
Управление middleware	Клиент	Клиент	Провайдер	Провайдер
Управление ОС	Клиент	Клиент	Провайдер	Провайдер
Управление виртуализацией	Клиент	Провайдер	Провайдер	Провайдер
Управление серверами	Клиент	Провайдер	Провайдер	Провайдер
Управление сетью	Клиент	Провайдер/Клиент*	Провайдер	Провайдер
Управление дата-центром	Клиент	Провайдер	Провайдер	Провайдер
Уровень контроля	Максимальный	Высокий	Средний	Низкий
Простота использования	Низкая	Средняя	Высокая	Максимальная

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

6. Как выбрать модель?

Выбор модели зависит от многих факторов:

Критерий	Скорее IaaS	Скорее PaaS	Скорее SaaS
Уровень контроля	Нужен полный контроль	Контроль не критичен, важна скорость	Вообще не нужен контроль
Команда	Есть опытные администраторы	Есть разработчики, мало админов	Нет своей IT-команды
Приложение	Уникальное, требует специфической настройки	Типовое веб-приложение	Готовая бизнес-функция (почта, CRM)
Бюджет	Есть бюджет на администрирование	Хочется сэкономить на администрировании	Платим за пользование
Время	Есть время на развёртывание	Нужно запустить быстро	Нужно прямо сейчас

7. Пример: Разработка и размещение веб-приложения

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

Вариант IaaS:

• Арендуем виртуальный сервер (например, Ubuntu 22.04).

• Устанавливаем Nginx, PostgreSQL, Python, зависимости проекта.

• Настраиваем firewall, автоматическое обновление ОС.

• Размещаем код, настраиваем systemd для запуска приложения.

• При росте нагрузки вручную (или через скрипты) создаём ещё серверы и настраиваем балансировку.

Вариант PaaS:

• Выбираем Heroku или Google App Engine.

• Создаём приложение через веб-интерфейс или CLI.

• Указываем тип приложения (Python) и подключаем БД (как сервис).

• Загружаем код через git push.

• Платформа сама запускает приложение, назначает URL, масштабирует при росте нагрузки.

Вариант SaaS:

• Покупаем подписку на готовую CRM (например, Salesforce) и настраиваем её под свои бизнес-процессы.

• Ничего не разрабатываем, только настраиваем.

8. Заключение

Ключевые выводы:

1. IaaS — аренда "голой" инфраструктуры (серверы, диски, сети). Максимальный контроль, но и максимум ответственности.

2. PaaS — аренда платформы для разработки. Разработчик фокусируется на коде, платформа управляет средой.

3. SaaS — аренда готового ПО. Пользователь просто работает.

4. Модели не исключают друг друга — в одной компании могут использоваться все три (например, 1С в SaaS, собственное приложение на PaaS, а legacy-системы на IaaS).

5. Выбор модели зависит от потребностей бизнеса, компетенций команды и требований к контролю.