Представьте, что вы написали скрипт, разместили его как serverless-функцию и неожиданно получили счёт на 75 000$ из-за самой простой ошибки обработки исключений. Представить страшно, а ведь это реальная история.

У каждого типа IT-проектов есть свои особенности, определяющие где, и как, их лучше размещать. Сегодня мы сравним несколько вариантов хостинга, для простых скриптов как парсеры, боты, API и web-приложения.

И начнём с виртуализации. В основе любого облака лежат железные серверы. Вопрос в том, какие абстракции реализованы поверх них для упрощения жизни разработчиков.

VPS или виртуализация на уровне железа

Если взять железный сервер и виртуально “нарезать на кусочки”, мы получим виртуальную машину. Затем ставим на неё операционную систему и подключаемся по SSH. 

Особенностью является хорошая изоляция ресурсов (даёт относительную безопасность, если правильно настроить) и высокую степень свободы. На виртуальной машине можно делать, что хочется, и настраивать, как нравится. В отличие от железного сервера провайдер может делать переподписку по CPU, поэтому производительность процессора у особо жадных компаний может неожиданно проседать из-за шумного соседа. Но вот память и диск переподписать технически невозможно, поэтому когда вы покупаете VPS/VDS хостинг, вы покупаете именно ОЗУ c диском и лимит по CPU. Или платите несколько иксов от цены и получаете гарантированный CPU.

Но со свободой приходит и ответственность. При работе с виртуальной машиной приходится работать с OC, настраивать NGINX, SSL-сертификаты и многое другое.

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

App Engine или виртуализация на уровне операционной системы

Основным отличием сервисов движков приложений (App Engine) является то, что виртуализация идёт через контейнеры, а не виртуальные машины. Таким образом, разделение осуществляется на уровне операционной системы.

Это избавляет от необходимости ставить отдельную операционку для каждого приложения, можно использовать одну ОС на несколько десятков проектов.

Другой важной особенностью является более верхнеуровневый продукт, где провайдер хостинга абстрагирует пользователя от управления инфраструктурой. С точки зрения сложности администирования, настройки и обновления — это самый простой для пользователя продукт.

Надо загрузить код, заполнить простую конфигурацию и многие вещи будут работать из коробки. Платформы подобного плана хорошо подходят индивидуальным разработчикам и маленьким командам без DevOps-специалистов.

Одним из первых провайдеров хостинга для кода с типом App Engine является, во многом легендарная компания Heroku, которая позволяет разворачивать и обновлять код проектов простыми коммитами в Git-репозиторий. В совокупности с другими функциями, это позволяет практически полностью забыть о настройке таких вещей как NGINX, SSL, CI/CD и сосредоточится на коде приложения.

Мы ориентировались на ведущие мировые компании, когда делали собственное облако с движком приложений – Amvera, которое по нашей задумке должно максимально облегчать жизнь разработчиков. В отличии от Heroku мы добавили постоянное хранилище с бэкапами (для работы с SQLite и подобными файлами), возможность деплоя не только через Git, но и через интерфейс, прокси до нейронок и собственный инференс, чтобы была не нужна иностранная карта.

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

Часто в основе таких сервисов лежат Kubernetes-кластеры, позволяющие взять на себя большинство задач автоматизации DevOps. Но вам с ними не придется работать, всё под капотом.

Но надо учитывать, что зона контроля, как и ответственности, меньше, и не всё можно кастомно настроить.

Serverless или виртуализация на уровне кода

Бессерверный подход хостинга кода появился из идеи, что код можно крутить на сервере не 24/7, а запускать в моменты запросов. Таким образом, пока код не работает, он почти не потребляет ресурс.

И виртуализация здесь идёт уже на уровне кода.

Первопроходцем в бессерверных вычислениях является AWS c сервисом Lambda. В РФ функции как сервис можно найти у Яндекса.

Идея оплаты только за работающий код хороша, но есть несколько подводных камней.

Serverless может быть очень-очень дорогим, если вы допустите ошибку. Ценообразование строится из расчёта времени работы кода (и обычно до 10 раз дороже в сравнении с обычной виртуальной машиной в пересчёте на ГБ ОЗУ) и из числа запросов.

Если к вашему коду будет много обращений (к примеру, вы допустили ошибку и идет вал ретрай запросов на ровном месте) или код работает почти постоянно, это может вас «разорить».

Так, в кейсе по ссылке сгорело 75 000$ из-за одного неверного вызова с ретраями. А в этой истории 14 000$ из-за бесконечного цикла.

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

Помимо этого, написание скриптов для бессерверного выполнения требует навыков и создаёт дополнительный Vendor Lock-in в проекте.

Выбираем хостинг для скриптов в зависимости от задачи

Если вам нужен полный контроль над инфраструктурой и не пугает необходимость её администрировать, логично выбрать VPS/VDS.

Если вы не хотите задумываться о настройке NGINX, ОС, SSL и получить из коробки CI/CD (автоматизация развёртывания), мониторинга, бэкапов и подобных вещей, имеет смысл выбрать один из сервисов App Engine.

А если ваш код не должен работать постоянно, вас не пугают сложности, вендорлок и возможность «попасть на деньги», можно использовать Serverless для хостинга вашего скрипта.