У SaaS-проекта есть неприятная особенность: инфраструктуру очень легко усложнить раньше, чем появятся первые клиенты. Разработчик еще заканчивает MVP, а на схеме уже нарисованы несколько серверов, балансировщик, отдельная база данных, Redis, очереди, объектное хранилище и целый набор облачных сервисов.
Выглядит солидно. Но небольшому SaaS все это может оказаться совершенно не нужно.
На старте собственный онлайн-сервис нередко прекрасно работает на одном VPS или управляемой платформе. Frontend, backend и база данных могут находиться рядом, а ежемесячные расходы на инфраструктуру оставаться небольшими. Усложнять систему разумнее постепенно, когда для этого появляются реальные причины: растет нагрузка, увеличивается база, становится много пользовательских файлов или простой сервиса начинает обходиться бизнесу слишком дорого.
Но SaaS нельзя рассматривать и как обычный небольшой сайт. Если сайт временно перестал открываться, посетитель может вернуться позже. Когда недоступен рабочий онлайн-сервис, клиенты не могут выполнять свои задачи. А если SaaS хранит информацию нескольких компаний, ошибка в разграничении доступа способна привести к гораздо более серьезной проблеме, чем обычный сбой страницы.
Поэтому хостинг для SaaS выбирают не только по процессору, памяти и цене. Нужно учитывать архитектуру приложения, способ хранения данных разных клиентов, резервное копирование, безопасность, возможность масштабирования и стоимость инфраструктуры по мере роста проекта.
Разберемся, когда SaaS достаточно одного VPS, стоит ли начинать с облака, когда выносить базу данных на отдельный сервер и как не построить дорогую инфраструктуру для сервиса, которым пока пользуются двадцать человек.
Что такое SaaS с точки зрения хостинга
SaaS расшифровывается как Software as a Service — программное обеспечение как услуга.
Пользователь не покупает программу только для установки на свой компьютер, а получает доступ к работающему сервису. Обычно через браузер, иногда дополнительно через мобильное или настольное приложение.
Онлайн-бухгалтерия, CRM, сервис управления проектами, редактор документов, система аналитики, конструктор сайтов, сервис рассылок, облачная система учета — все это может работать по модели SaaS.
Для владельца такого проекта принципиально важно, что приложение работает на его инфраструктуре или на выбранной им облачной платформе. Именно владелец сервиса должен обеспечить работу backend, базы данных и остальных компонентов.
Если компания просто пользуется чужим SaaS по подписке, покупать для него сервер не требуется. Инфраструктурой занимается поставщик сервиса.
В этой статье нас интересует противоположная ситуация: вы разрабатываете собственный SaaS и выбираете, где его разместить.
Простейшая архитектура может выглядеть так:
пользователь → веб-приложение → backend → база данных.
По мере развития к ней могут добавиться:
- Redis или другой кеш;
- очереди задач;
- worker-процессы;
- объектное хранилище;
- CDN;
- почтовый сервис;
- платежная система;
- система мониторинга;
- отдельная аналитика;
- несколько экземпляров backend;
- балансировщик нагрузки.
Однако это не список того, что нужно купить перед запуском. Это лишь возможные компоненты, которые появляются по мере необходимости.
Хорошая архитектура SaaS не та, где больше технологий. Она должна решать текущую задачу и оставлять понятный путь для дальнейшего роста.
Можно ли запустить SaaS на одном VPS
Не только можно — для многих новых проектов это один из самых разумных вариантов.
Представим небольшой SaaS, который только выходит на рынок. У него несколько десятков пользователей, относительно небольшая база и простой backend.
Для такого проекта один VPS может одновременно выполнять несколько функций.
На нем работает веб-сервер, приложение и база данных. Там же может находиться Redis, если он действительно нужен. Файлы проекта тоже можно первоначально хранить на этом сервере.
Получается простая архитектура, которую легко понимать и относительно недорого содержать.
Это особенно важно для MVP.
На раннем этапе главный риск проекта часто заключается вовсе не в том, что сервер не выдержит миллион пользователей. Намного вероятнее, что продукт придется несколько раз серьезно изменить после обратной связи первых клиентов.
Поэтому вкладывать много времени и денег в инфраструктуру под гипотетическую огромную аудиторию бывает преждевременно.
Если один VPS справляется с нагрузкой и его отказоустойчивость соответствует текущим требованиям бизнеса, нет ничего неправильного в такой архитектуре.
Увеличить сложность можно позже.
Один сервер не означает один процесс
При этом простой VPS не обязательно означает, что SaaS должен состоять из единственной программы.
На одной виртуальной машине могут работать веб-сервер, backend, база данных и фоновые процессы.
Например, Nginx принимает HTTPS-запросы и передает их приложению. PostgreSQL хранит данные. Отдельный worker выполняет задачи из очереди.
Физически все находится на одной виртуальной машине, но логически система уже разделена на компоненты.
Это удобно: если проект вырастет, отдельные части можно постепенно переносить на другие серверы, не переписывая всю архитектуру с нуля.
Виртуальный хостинг для SaaS тоже не всегда исключен
Слово SaaS звучит достаточно серьезно, поэтому обычный виртуальный хостинг кажется неподходящим по определению. Но технически все зависит от самого приложения.
Если небольшой сервис написан на PHP, использует поддерживаемую СУБД и не требует собственных постоянно работающих служб, он вполне может работать на хорошем виртуальном хостинге.
Для совсем небольшого проекта это способ снизить стоимость и практически избавиться от системного администрирования.
Провайдер уже обслуживает операционную систему, веб-сервер и другие базовые компоненты.
Но ограничения shared-хостинга для SaaS проявляются довольно быстро.
Может потребоваться постоянно работающий worker. Появляются очереди. Нужен Redis. Требуется нестандартная конфигурация среды или Docker. Возникает необходимость управлять серверными процессами.
В этот момент VPS становится значительно удобнее.
Поэтому виртуальный хостинг можно рассматривать для простого SaaS, но при выборе стоит заранее понимать, насколько легко будет перенести проект на VPS, если он перерастет возможности тарифа.
Почему количество клиентов SaaS почти ничего не говорит о нагрузке
У SaaS есть интересная особенность: понятие «клиент» может означать совершенно разные объемы использования.
Представим сервис управления задачами.
Первая компания купила подписку и добавила трех сотрудников.
Вторая — пятьдесят.
Третья импортировала десятки тысяч задач и активно использует API.
Формально это три клиента. Но нагрузка, которую они создают, различается радикально.
Поэтому фраза «наш сервер рассчитан на тысячу клиентов» без дополнительного контекста мало что значит.
Гораздо полезнее измерять реальные технические показатели:
- количество активных пользователей;
- число одновременных сессий;
- частоту API-запросов;
- сложность операций с базой;
- объем данных одного клиента;
- количество фоновых задач;
- объем загружаемых файлов;
- сетевой трафик;
- пиковую нагрузку.
Именно поэтому подобрать сервер для нового SaaS с математической точностью до запуска практически невозможно.
Можно оценить стартовую конфигурацию, провести нагрузочные тесты, а после появления реальных пользователей ориентироваться на мониторинг.
Multi-tenancy меняет требования к SaaS
Одно из ключевых отличий SaaS от обычного корпоративного веб-приложения — системой часто одновременно пользуются несколько независимых клиентов.
В английской терминологии такую архитектуру называют multi-tenant.
Tenant в данном случае — отдельный клиент или организация внутри SaaS.
Например, сервисом учета пользуются сто компаний. Каждая должна видеть только собственных сотрудников, документы и операции.
При этом физически все они могут работать с одним экземпляром приложения и одной инфраструктурой.
Именно здесь архитектура хранения и разграничения данных становится критически важной.
Есть несколько подходов.
Данные разных клиентов могут находиться в общей базе и разделяться идентификатором tenant.
Можно использовать отдельные схемы.
В некоторых проектах каждому крупному клиенту выделяется отдельная база данных.
У каждого варианта есть преимущества и недостатки.
Общая база обычно проще и дешевле на старте. Но приложение должно безошибочно контролировать принадлежность каждой записи конкретному клиенту.
Отдельные базы усиливают изоляцию и могут упростить некоторые сценарии переноса конкретного клиента, но значительно усложняют управление при большом количестве tenants.
Поэтому универсального правила «каждому клиенту отдельная база» не существует.
Архитектура зависит от характера SaaS, требований к изоляции, количества клиентов и особенностей эксплуатации.
Самая опасная ошибка — смешать данные разных клиентов
Для SaaS проблема разграничения доступа намного серьезнее обычной ошибки интерфейса.
Представим, что сотрудник компании A изменяет параметр запроса и получает документ компании B.
Это уже серьезный инцидент безопасности.
Поэтому проверка tenant должна выполняться на серверной стороне при каждой операции, где это необходимо.
Нельзя полагаться на то, что пользователь просто не видит чужие данные в интерфейсе.
Frontend не является границей безопасности.
Backend должен самостоятельно определить, имеет ли текущий пользователь право получить или изменить конкретный объект.
Это вопрос архитектуры приложения, а не характеристик хостинга. Но инфраструктуру SaaS невозможно рассматривать отдельно от безопасности данных.
База данных обычно растет быстрее самого приложения
Код SaaS может годами занимать примерно одинаковый объем.
С базой ситуация противоположная.
Каждый новый клиент создает пользователей, проекты, документы, операции, настройки и историю действий.
Даже после ухода клиента часть информации иногда необходимо сохранять определенное время в соответствии с правилами сервиса и применимыми требованиями.
Поэтому база постоянно растет.
Поначалу это практически незаметно.
Запросы выполняются быстро, backup занимает минуты, а весь объем данных легко помещается на диске небольшого VPS.
По мере роста начинают проявляться архитектурные решения, которые раньше не имели значения.
Отсутствующий индекс превращает простой поиск в тяжелую операцию. Неудачный запрос начинает просматривать огромное количество строк. Формирование отчета заметно нагружает сервер.
Именно поэтому увеличение мощности VPS не должно быть единственным способом ускорения SaaS.
Иногда дополнительная память действительно нужна базе. В другой ситуации правильный индекс дает больший эффект, чем переход на более дорогой сервер.
Мониторинг медленных запросов и состояние СУБД по мере роста проекта становятся обязательной частью эксплуатации.
Когда базу SaaS пора вынести отдельно
На раннем этапе база и приложение вполне могут работать на одной машине.
Это просто, дешево и избавляет от лишнего сетевого взаимодействия.
Переносить СУБД отдельно имеет смысл не по достижении какого-то магического количества клиентов, а когда появляется техническая или организационная причина.
Например, база начинает конкурировать с backend за оперативную память.
Или приложение нужно масштабировать независимо от СУБД.
Или команда хочет перейти на управляемую базу данных, обслуживание которой частично берет на себя облачный провайдер.
После разделения можно независимо изменять ресурсы backend и базы.
Но появляются новые вопросы: сетевой доступ, задержка, защита соединения, резервирование и стоимость отдельного сервиса.
Поэтому выносить базу только ради более красивой архитектурной схемы не стоит.
Фоновые задачи в SaaS появляются очень быстро
Многие операции пользователю необязательно выполнять прямо во время HTTP-запроса.
Представим SaaS для аналитики.
Клиент загрузил большой файл и попросил сформировать отчет.
Если обработка занимает несколько минут, держать браузерный запрос открытым до завершения операции неудобно.
Гораздо разумнее принять задачу, поставить ее в очередь и сообщить пользователю, что обработка началась.
Отдельный worker выполнит работу в фоне.
Подобным образом можно отправлять письма, создавать PDF, импортировать данные, синхронизироваться с внешними API, обрабатывать изображения и выполнять другие тяжелые операции.
Так в инфраструктуре появляются очереди и worker-процессы.
На одном VPS все это может прекрасно работать вместе с основным backend.
По мере роста workers можно вынести на отдельные машины и масштабировать независимо.
Например, если приложение получает много задач по обработке файлов, можно увеличить количество worker-процессов, не добавляя лишние ресурсы веб-части.
Нужен ли SaaS Redis
Не обязательно.
Redis часто используют для кеша, сессий, временных данных и очередей.
Но устанавливать его только потому, что он присутствует в типичных схемах SaaS, бессмысленно.
Кеш полезен, когда приложение регулярно выполняет дорогую операцию, результат которой можно некоторое время переиспользовать.
Если данные и так извлекаются из базы практически мгновенно, дополнительный слой кеширования может лишь усложнить систему.
Более того, кеш создает собственную проблему — его нужно правильно инвалидировать.
Пользователь изменил данные, а приложение продолжает показывать старое значение из кеша. В результате ускорение превращается в источник ошибок.
Поэтому Redis стоит добавлять под конкретную задачу.
Для очередей он действительно может оказаться полезным довольно рано, особенно если SaaS активно выполняет фоновые операции.
Пользовательские файлы могут стать отдельной статьей расходов
Некоторые SaaS почти не хранят файлов.
Другие буквально построены вокруг них.
Сервис электронного документооборота, облачный редактор изображений и система аналитики загружаемых файлов предъявляют совершенно разные требования к диску.
На старте файлы можно хранить на VPS.
Но здесь полезно заранее посмотреть на экономику.
Если один клиент в среднем занимает 5 ГБ, сто клиентов потенциально потребуют уже около 500 ГБ только пользовательского пространства.
При этом резервные копии тоже увеличиваются.
По мере роста проекта объектное хранилище часто становится удобнее обычного диска сервера.
Backend сохраняет информацию о файле, а сам объект хранится отдельно.
Такое разделение особенно удобно, когда запускается несколько экземпляров приложения.
Все они обращаются к общему хранилищу, вместо того чтобы пытаться синхронизировать локальные каталоги.
Но если SaaS хранит десять мегабайт файлов на клиента, строить сложную систему ради будущих петабайт тоже не нужно.
Инфраструктура должна учитывать тарифы самого SaaS
У SaaS есть еще одна особенность, которой нет у обычного информационного сайта: владелец сам продает клиентам определенные лимиты.
Например:
- количество сотрудников;
- объем файлов;
- число проектов;
- количество операций;
- число API-запросов;
- частоту формирования отчетов.
Эти ограничения имеют прямое отношение к инфраструктуре.
Если клиент платит 500 рублей в месяц, но способен создать серверную нагрузку на несколько тысяч рублей, бизнес-модель требует пересмотра.
Поэтому разработчик SaaS должен понимать приблизительную себестоимость использования сервиса.
Особенно это важно для ресурсоемких функций.
Например, обработка видео, генерация больших отчетов или выполнение сложных вычислений может потреблять значительно больше ресурсов, чем обычная работа с интерфейсом.
Иногда правильнее ограничить такие операции конкретным тарифом, чем бесконечно увеличивать сервер.
Платежи и подписки не должны зависеть от одной кнопки
Для SaaS биллинг является частью продукта.
Пользователь оплачивает подписку, платежная система сообщает об успешной операции, после чего аккаунт получает соответствующий тариф.
Но сетевые взаимодействия могут завершаться ошибками.
Webhook способен прийти повторно. Ответ может задержаться. Пользователь может закрыть страницу сразу после оплаты.
Поэтому серверная логика должна корректно обрабатывать такие ситуации.
Одна и та же информация об успешной операции не должна случайно дважды начислять баланс или создавать две подписки.
Это уже не столько вопрос выбора VPS, сколько надежности самого backend.
Но для SaaS важно понимать: хороший хостинг не исправляет ошибки бизнес-логики.
Надежность сервиса складывается одновременно из качества инфраструктуры и качества приложения.
Резервные копии для SaaS нужно проектировать от допустимой потери данных
Фраза «хостинг делает ежедневные backup» сама по себе мало о чем говорит.
Представим SaaS, которым активно пользуются сотни клиентов.
Если единственная резервная копия базы создается раз в сутки, серьезная авария вечером потенциально означает потерю почти целого рабочего дня.
Подходит ли это бизнесу?
Ответ зависит от продукта.
Для небольшого вспомогательного сервиса потеря нескольких часов изменений может быть неприятной, но допустимой.
Для финансовой или операционной системы последствия могут оказаться совершенно неприемлемыми.
Поэтому нужно определить RPO — какой объем данных допустимо потерять.
Если приемлема потеря максимум одного часа информации, резервирование должно соответствовать этому требованию.
Есть и второй вопрос — сколько времени SaaS может оставаться недоступным после серьезной аварии.
Это уже связано с RTO.
Если восстановление сервера из backup занимает восемь часов, а клиенты ожидают возобновления работы через пятнадцать минут, инфраструктура не соответствует бизнес-требованиям.
На раннем этапе SaaS редко нуждается в сложной катастрофоустойчивой архитектуре. Но владелец хотя бы должен понимать эти два показателя и принимать риск осознанно.
Backup должен находиться отдельно
Хранить единственную резервную копию на том же VPS, где работает SaaS, опасно.
При потере сервера можно одновременно потерять рабочие данные и backup.
Поэтому хотя бы одна актуальная копия важных данных должна находиться независимо от основного сервера.
И резервные копии необходимо проверять восстановлением.
Файл с названием backup.sql еще не гарантирует, что из него действительно получится восстановить рабочую систему.
Мониторинг SaaS нужен раньше сложного масштабирования
До того как покупать дополнительные серверы, стоит научиться понимать состояние уже существующего.
Минимальный мониторинг должен отвечать на простые вопросы.
Работает ли сервис сейчас? Сколько занимает ответ API? Не заканчивается ли оперативная память? Сколько осталось дискового пространства? Не растет ли количество ошибок?
Для базы полезно следить за соединениями и медленными запросами.
Для очередей — за количеством ожидающих задач и временем их обработки.
Для диска — не только за текущим свободным местом, но и за скоростью его уменьшения.
Если SaaS неожиданно перестал отвечать, владелец должен узнать об этом от системы мониторинга, а не из письма клиента «у вас ничего не работает».
По мере развития мониторинг становится подробнее, но начинать можно с базовых метрик.
Они же помогают принимать решения о масштабировании на основании фактов.
Когда SaaS перерастает один VPS
Нет определенного количества клиентов, после которого нужно обязательно переходить на несколько серверов.
Один хорошо оптимизированный сервис способен обслуживать очень большую аудиторию на относительно скромной машине.
Другой проект из-за тяжелых операций упрется в ресурсы намного раньше.
Обычно развитие инфраструктуры происходит постепенно.
Первый шаг — увеличить ресурсы текущего VPS.
Если не хватает памяти или CPU, перейти на более мощную конфигурацию часто значительно проще, чем сразу строить распределенную систему.
Затем можно вынести наиболее требовательный компонент.
Очень часто это база данных.
В другом проекте первыми отделяются worker-процессы.
Пользовательские файлы переезжают в объектное хранилище.
После этого может появиться необходимость запускать несколько экземпляров backend.
Перед ними устанавливается балансировщик, который распределяет запросы.
На этом этапе особенно важно, чтобы приложение не зависело от локального состояния конкретного экземпляра.
Если пользователь авторизовался через сервер A, следующий запрос, попавший на сервер B, тоже должен корректно обработаться.
Поэтому общие сессии, файлы и другое необходимое состояние выносят в доступные всем экземплярам системы.
Это уже настоящее горизонтальное масштабирование.
Но переходить к нему нужно тогда, когда вертикальное масштабирование перестает удовлетворять требованиям по нагрузке, доступности или экономике.
Отказоустойчивость и масштабирование — не одно и то же
Можно иметь очень мощный сервер, который легко выдерживает всю нагрузку, но при его отказе SaaS полностью перестанет работать.
Это проблема доступности, а не производительности.
И наоборот, можно запустить два слабых сервера, но оба будут перегружены.
Поэтому масштабирование и отказоустойчивость решают разные задачи.
Для нового SaaS допустимый простой обычно определяется стадией бизнеса.
MVP с несколькими тестовыми пользователями может позволить себе уровень инфраструктуры, который был бы неприемлем для сервиса с тысячами платящих компаний.
По мере роста стоимости простоя имеет смысл уменьшать количество единичных точек отказа.
Могут появляться резервные экземпляры, балансировка, репликация базы и более сложная схема восстановления.
Но отказоустойчивость стоит строить от реального ущерба простоя.
Иначе можно потратить огромные деньги на защиту от пятнадцатиминутного сбоя сервиса, который пока приносит меньше стоимости этой инфраструктуры.
VPS или облако для SaaS
На ранней стадии обычный VPS имеет сильное преимущество — простоту.
Есть понятное количество CPU, памяти и диска. Есть фиксированная или относительно предсказуемая стоимость.
Сервер легко представить как одну машину, которую можно увеличить по мере необходимости.
Облако предоставляет больше строительных блоков.
Виртуальные машины, управляемые базы данных, балансировщики, объектное хранилище, сети и другие сервисы можно комбинировать в более сложную инфраструктуру.
Это удобно для растущего SaaS.
Но каждый компонент может иметь собственную тарификацию.
Поэтому облачная архитектура требует внимательного контроля расходов.
Само слово «облако» не означает автоматически дешевле, быстрее или надежнее.
Преимущество появляется тогда, когда проект действительно использует возможности облачной платформы.
Для MVP один VPS может быть лучшим решением именно потому, что он скучный и понятный.
Для крупного SaaS возможность независимо масштабировать приложение, базу, workers и хранилище уже становится намного ценнее.
Нужен ли SaaS Kubernetes
Для большинства начинающих SaaS — нет.
Kubernetes предназначен для управления контейнеризированными приложениями и способен решать сложные задачи развертывания и масштабирования.
Но вместе с возможностями появляется серьезная дополнительная сложность.
Если весь SaaS спокойно работает на одном или двух серверах, внедрение Kubernetes может создать больше работы, чем пользы.
Нужно обслуживать не только приложение, но и саму инфраструктурную платформу либо платить за управляемое решение.
Это не означает, что Kubernetes плох.
Для определенного масштаба, архитектуры и команды он может быть отличным инструментом.
Просто использовать его стоит для решения существующей проблемы, а не для придания стартапу внешних признаков крупного технологического проекта.
Безопасность SaaS начинается не с firewall
Firewall и защита сервера важны, но одна из наиболее опасных областей SaaS находится непосредственно в приложении.
Это авторизация и разграничение данных клиентов.
Каждый запрос должен выполняться в контексте конкретного пользователя и, если используется multi-tenancy, конкретного tenant.
Секретные ключи сторонних сервисов нельзя помещать в публичный frontend.
Пароли должны храниться с использованием подходящих современных механизмов хеширования, а не в открытом виде.
Соединение пользователей с сервисом должно быть защищено HTTPS.
Для административных аккаунтов и других чувствительных сценариев полезно предусмотреть многофакторную аутентификацию, если она соответствует модели продукта.
На VPS необходимо следить за обновлениями операционной системы и серверных компонентов.
Доступ к СУБД не стоит без необходимости открывать всему интернету.
Также необходимо защищать резервные копии.
Незашифрованный backup с полной базой клиентов, доступный постороннему человеку, ничем не лучше утечки рабочей базы.
География сервера SaaS
Расположение инфраструктуры влияет на задержку, доступность внешних сервисов и требования к работе с данными.
Если SaaS ориентирован преимущественно на российскую аудиторию, логично учитывать доступность инфраструктуры для пользователей из России и применимые требования законодательства.
Если сервис международный, задача становится сложнее.
Клиенты могут находиться на разных континентах, а данные подпадать под различные требования.
Но новому SaaS редко нужно сразу разворачивать backend в пяти регионах мира.
Для ускорения статического контента можно использовать CDN, тогда как основное приложение и база продолжают работать в одном выбранном регионе.
Мультирегиональная архитектура имеет смысл, когда аудитория и требования бизнеса действительно до нее доросли.
Стоимость инфраструктуры должна расти вместе с SaaS
Для коммерческого сервиса сервер — не просто техническая деталь, а часть себестоимости продукта.
Представим SaaS с ежемесячной выручкой 30 тысяч рублей, инфраструктура которого обходится в 25 тысяч.
Даже если архитектура технически прекрасна, у бизнеса возникает очевидный вопрос.
На ранней стадии особенно важно не оплачивать ресурсы, которые не используются.
Это одна из причин, почему простой VPS часто является хорошей отправной точкой.
По мере роста количества платящих клиентов можно увеличивать расходы на надежность и масштабирование.
В идеальном сценарии инфраструктура растет вслед за реальным использованием сервиса.
Сначала один сервер.
Затем больше ресурсов.
Потом отдельная база или хранилище, если это необходимо.
Дальше несколько экземпляров приложения и более сложная инфраструктура.
Необязательно проходить все эти этапы. Некоторые SaaS годами остаются на относительно простой архитектуре.
И это скорее преимущество, чем недостаток.
Что проверить перед выбором хостинга для SaaS
До просмотра тарифов стоит описать хотя бы базовую архитектуру продукта.
Как запускается backend? Какая используется база? Есть ли фоновые задачи? Хранят ли пользователи файлы? Требуется ли Redis? Нужны ли WebSocket? Как будут выполняться резервные копии?
После этого можно оценивать конкретную площадку.
Для SaaS я бы проверила:
- поддержку необходимого технологического стека;
- возможность использовать нужные версии среды выполнения;
- доступные CPU и RAM;
- тип и производительность дисков;
- условия сетевого трафика;
- возможность быстро увеличить ресурсы;
- наличие SSH;
- возможность запуска постоянно работающих процессов;
- поддержку фоновых worker-задач;
- возможность использования Redis и очередей;
- поддержку Docker, если он нужен проекту;
- доступные базы данных;
- возможность подключения отдельной или управляемой СУБД;
- объектное хранилище либо возможность подключить внешний сервис;
- SSL;
- наличие статического IP, если этого требуют интеграции;
- резервные копии;
- возможность хранить backup отдельно от рабочего сервера;
- снимки виртуальных машин;
- мониторинг;
- доступ к логам;
- географию дата-центров;
- возможность дальнейшего горизонтального масштабирования;
- качество технической поддержки;
- наличие администрирования, если в команде нет специалиста по серверам.
Отдельно стоит оценить стоимость будущего роста.
Недорогая стартовая конфигурация хороша, но полезно заранее посмотреть, сколько стоят следующий объем RAM, дополнительный диск, backup и трафик.
Это позволит избежать ситуации, когда перенос к другому провайдеру становится необходим сразу после первых успехов проекта.
Какой хостинг для SaaS выбрать в итоге
Небольшому SaaS совершенно необязательно начинать жизнь в сложной облачной инфраструктуре.
Если проект только выходит на рынок, один VPS или подходящая управляемая платформа часто являются рациональным вариантом.
Backend и база данных могут находиться на одной машине. Там же могут работать фоновые процессы и кеш, если ресурсов достаточно.
Такую систему проще обслуживать и дешевле содержать.
Виртуальный хостинг тоже нельзя полностью исключать. Для простого SaaS на поддерживаемом стеке его возможностей иногда хватает, особенно на раннем этапе. Но стоит заранее учитывать ограничения и возможность будущего переезда.
Не выбирайте сервер по количеству зарегистрированных клиентов.
Один клиент способен создать десять пользователей, а другой — тысячу. Один хранит несколько записей, другой загружает огромный объем данных и постоянно обращается к API.
Ориентируйтесь на реальную нагрузку.
Особое внимание уделите базе данных и изоляции tenants. Клиент SaaS должен видеть только собственную информацию независимо от того, как физически организовано ее хранение.
Резервное копирование проектируйте исходя из того, сколько данных бизнес готов потерять и как быстро сервис должен восстановиться после серьезной аварии.
Настройте мониторинг раньше, чем понадобится масштабирование. Без измерений легко потратить деньги не на тот ресурс и не решить настоящую проблему.
Когда одному VPS становится тесно, необязательно сразу строить кластер. Сначала можно увеличить ресурсы машины. Затем постепенно вынести базу, файлы или workers. И только при необходимости запускать несколько экземпляров приложения и балансировку.
Облако полезно тогда, когда SaaS действительно начинает пользоваться преимуществами облачной инфраструктуры: независимым масштабированием компонентов, управляемыми сервисами и более гибкой архитектурой.
А Kubernetes нужен далеко не каждому проекту. Если сервис прекрасно работает без него, отсутствие сложного оркестратора не делает SaaS менее профессиональным.
Самая разумная инфраструктура для SaaS — та, стоимость и сложность которой соответствуют текущему бизнесу.
На старте важнее запустить надежный продукт и получить первых платящих клиентов, чем построить систему для миллиона пользователей, которых пока нет. А когда аудитория действительно начнет расти, правильно спроектированное приложение можно масштабировать постепенно — вместе с нагрузкой, требованиями к надежности и выручкой самого сервиса.
