IaaS, PaaS, SaaS: чем отличаются модели облачных услуг

Любой сервис можно разложить на слои: сеть и физический сервер, виртуализация, операционная система, среда выполнения, само приложение и данные. Три сокращения описывают, где проходит граница между тем, что делает провайдер, и тем, что остаётся клиенту.

Чем выше модель по уровню абстракции, тем меньше вы администрируете и тем меньше контролируете. Это компромисс между удобством и гибкостью, а не рейтинг качества.

Наглядная аналогия: в IaaS вы арендуете пустую кухню, в PaaS получаете кухню с готовой техникой, а в SaaS заказываете готовое блюдо.

Infrastructure as a Service предоставляет виртуальные машины, диски и сети. Провайдер отвечает за оборудование и виртуализацию, а операционную систему, обновления, установку программ и защиту настраиваете вы. Типичный пример — арендованный виртуальный сервер, о котором рассказано на странице про VPS.

Такая модель подходит, когда нужен полный контроль: нестандартное программное обеспечение, специфичная сетевая схема, собственные службы.

В такой модели вы сами решаете, какие порты открыть, какую операционную систему установить, как настроить резервное копирование и мониторинг. Провайдер отвечает за то, чтобы виртуальная машина работала и сеть была доступна.

Platform as a Service убирает заботы об операционной системе и среде выполнения. Разработчик загружает код или контейнер, а платформа сама запускает его, масштабирует и перезапускает при сбоях. Сюда относят управляемые базы данных, платформы для веб-приложений и сервисы запуска контейнеров.

Плюс — скорость: меньше рутины. Минус — ограничения платформы: поддерживаемые языки, версии и способы конфигурации задаёт провайдер, а перенос к другому исполнителю может оказаться трудоёмким.

Разработчики ценят PaaS за то, что развёртывание сводится к отправке кода, а масштабирование включается настройкой без ручной работы с серверами.

Software as a Service — законченное программное обеспечение, работающее в браузере или клиенте: почта, офисные пакеты, системы учёта, хранилища файлов. Пользователь получает доступ и отвечает только за учётные записи и содержимое.

Обновления, резервные копии и работа серверов лежат на поставщике. Но и данные фактически хранятся у него, поэтому вопросы экспорта и защиты аккаунта становятся ключевыми: включённая двухфакторная защита здесь важнее, чем настройки сервера.

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

Ориентир простой: нужен готовый инструмент — SaaS, нужно запускать своё приложение без администрирования — PaaS, нужна полная свобода — IaaS. Часто в одном проекте комбинируются все три.

Типичное заблуждение: SaaS «безопаснее» просто потому, что не требует администрирования. На деле утечки чаще происходят из-за слабых паролей и лишних прав доступа, а не из-за взлома серверов провайдера. Ещё одна путаница — считать любой облачный продукт IaaS. Проверить просто: если вы обязаны обновлять операционную систему сами, это IaaS.

Практическая проверка: спросите себя, кто устанавливает обновления безопасности. Если вы — это IaaS, если платформа — PaaS, а если поставщик приложения — SaaS.

Границы между моделями размыты. Контейнерные платформы, где вы управляете кластером, находятся между IaaS и PaaS. Бессерверные вычисления, или serverless, запускают отдельные функции по событию и выставляют счёт только за время их выполнения; их часто выделяют в отдельную категорию FaaS.

Есть и обозначения вроде DBaaS для управляемых баз данных, BaaS для готовых серверных функций мобильных приложений и другие. Идея везде одна: провайдер берёт на себя всё больше рутины, а клиент получает меньше контроля.

При выборе полезно задать два вопроса: что вы готовы администрировать сами и насколько сложно будет перейти к другому поставщику. Чем выше уровень абстракции, тем выше привязка к конкретным возможностям платформы.