PaaS

Между арендой голой виртуальной машины и подпиской на готовый сервис есть промежуточная ступень. В модели IaaS клиент сам ставит веб-сервер, PHP и обновления. В SaaS он вообще не видит кода. PaaS забирает у разработчика заботу об окружении, но оставляет ему собственное приложение. Модель стала популярной в конце 2000-х благодаря Heroku и Google App Engine; сегодня похожие услуги есть у большинства облачных провайдеров, включая российских.

К PaaS относят и отдельные управляемые компоненты: базы данных, очереди, хранилища, которые провайдер разворачивает, обновляет и резервирует сам.

Как выглядит работа с платформой

Разработчик описывает, как запускать приложение, и отправляет код — через git, архив или образ контейнера. Платформа сама собирает окружение, ставит зависимости и запускает нужное число копий. Пример файла Procfile для PHP-приложения на Heroku и команды выкладки:

web: heroku-php-apache2 public/

git push heroku main

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

Ограничения, о которых узнают поздно

• Файловая система копий часто временная: всё, что приложение записало на диск, пропадает при перезапуске.
• Нельзя поставить произвольное расширение PHP или поменять настройки веб-сервера за пределами разрешённого.
• Привязка к платформе: переезд с одного PaaS на другой — отдельный проект.
• При росте нагрузки платформа обычно обходится дороже аренды сервера сопоставимой мощности.

PaaS для сайтов на CMS

WordPress и 1С-Битрикс рассчитаны на постоянный диск: туда загружаются картинки, пишется кеш, обновляются плагины и модули. На платформе с временной файловой системой придётся выносить загрузки во внешнее объектное хранилище и отказаться от обновлений через админку. Поэтому типичный сайт на CMS проще разместить на хостинге или своём сервере, а PaaS оставить для приложений, написанных под облако с самого начала.