SaaS — готовое приложение по подписке, запуск типовой задачи за неделю. PaaS — среда для собственного кода (базы данных, очереди, хранилище, вычисления), MVP за 3–5 месяцев, инвестиция от 600 000 рублей.
Выбор простой. Задача типовая и не дает конкурентного преимущества — берите SaaS, запуск займет неделю. Продукт должен принадлежать вам и расти под ваши процессы — собирайте MVP на PaaS: от 600 000 рублей и 3–5 месяцев.
Дальше сравниваем не термины, а сроки, сметы, рост счета за инфраструктуру и цену ухода от провайдера, если решите сменить платформу.
Одна CRM в трех вариантах
Пример — CRM для отдела продаж.
- •SaaS: amoCRM или Битрикс24. CRM открывается в браузере, менеджер ведет сделки и прикладывает документы. На клиенте только данные и настройки.
- •PaaS: своя CRM на платформе, где уже есть Node.js или Python и управляемая PostgreSQL. Команда пишет код, задает переменные окружения и параметры платформы.
- •On-premise: коробочная версия Контур.Толка на своих серверах, если нужен полный контроль над данными.
Критерий: сервис работает сразу в браузере — это SaaS, в него загружают свой код — это PaaS.
На что обратить внимание: в SaaS настраивается только то, что разрешил сервис.
Что сделать сейчас: разложить сервисы, которыми уже пользуется команда, по трем вариантам.
Что вы получаете и теряете на каждом уровне
Ось сравнения — кто за что отвечает, включая безопасность.
Плюсы PaaS работают при условии. Масштабирование и управляемые базы полезны, если есть свои разработчики. Если их нет или продажи закрывает готовая CRM, эти плюсы превращаются в лишние расходы.
Что сделать сейчас: отметить в таблице свою строку.
Где здесь IaaS
IaaS — точка отсчета: клиент получает виртуальный сервер и сам управляет операционной системой. Чем ниже уровень, тем больше свободы и тем шире ваша зона ответственности.
Если нужен контроль над ОС или нестандартная архитектура вроде микросервисов или ML-кластера, выбор уходит ниже PaaS.
Сроки и смета — неделя против 3–5 месяцев
Две сметы отличаются не суммой, а тем, из чего они состоят. Если процесс типовой и нужен всем сотрудникам, берут подписку на SaaS и запускаются за неделю. Если нужно свое веб-приложение, API или backend для мобильного приложения, собирают MVP на PaaS: например, личный кабинет клиента или сервис бронирования со своей логикой.
Чего избегать: сравнивать цену подписки с ценой ресурсов платформы. Такое сравнение забывает про работу разработчиков. Платформа дает базу данных, очереди и вычисления, но продукт из них собирает команда, и ее время входит в смету так же, как счет провайдера.
Что сделать сейчас: расписать, какие функции нужны в первой версии продукта, и проверить, закрывает ли их готовый сервис.
Из чего складывается SaaS-запуск
Смета SaaS-запуска — это подписка за пользователя, настройка полей и прав доступа, перенос данных и обучение сотрудников. Сотрудники работают в браузере, отдельную инфраструктуру никто не поднимает. Неделя получается, когда процесс укладывается в готовые сценарии сервиса, а не требует нестандартной логики.
Пример: отдел продаж переходит с таблиц в облачную CRM, заводит карточки клиентов, настраивает воронку и поля под свой процесс. Если же процесс приходится ломать под возможности сервиса, быстрый старт потом обернется обходными решениями.
Из чего складывается MVP на PaaS
Ориентир редакции — от 600 000 рублей и 3–5 месяцев. В смету входят проектирование, разработка, подключение управляемой базы данных и очередей, тестирование и запуск. Главная статья расходов — время команды, ресурсы платформы идут отдельной строкой.
Срок зависит от числа функций, интеграций и того, насколько готовы требования. Чем больше функций попадает в первую версию, тем дальше сдвигается запуск. Управляемые сервисы ускоряют часть работы: в примере с Хабра MySQL и PostgreSQL проверяют через управляемые СУБД без ручного развертывания серверов, и гипотеза подтверждается быстрее.
Как растет счет за PaaS
Модель pay-as-you-go, как в Yandex Cloud: платите за ресурсы, которые реально работают. Клиентов больше — нагрузка выше — платформа масштабируется и добавляет экземпляры, а отдельной строкой растет управляемая СУБД.
SaaS дорожает с числом сотрудников: новый менеджер — еще одна лицензия. PaaS дорожает с нагрузкой от ваших клиентов.
Для масштаба механики: Civo берет 0,01 фунта за экземпляр в час и дает месяц пробы с лимитом расходов, AWS Free Tier — до 6 месяцев и до 200 долларов кредитов. Это иллюстрация тарификации, а не смета.
Если нагрузка скачет, pay-as-you-go выгоден, но только с лимитом.
На что обратить внимание: без лимита расходов счет растет незаметно — экземпляры добавляются вслед за трафиком.
Что сделать сейчас: прикинуть нагрузку при росте числа клиентов в два раза.
Что переносится, а что переписывается при уходе
Допустим, одна компания без разработчиков подключила облачную CRM, а другая построила бэкенд на PaaS, и обеим понадобилось сменить поставщика. У первой переезжают данные: сделки, контакты и документы выгружаются и загружаются в новый сервис. У второй встает вопрос о коде: часть модулей написана под сервисы конкретной платформы, и просто скопировать их некуда.
Риски разные. В SaaS при уходе выгружаются данные, а код клиента не участвует: приложение принадлежит провайдеру. В PaaS код остается у вас, но часть его может быть завязана на платформу. Эта привязка к провайдеру — главный риск PaaS.
Если продукт будет жить годами, переносимость проверяют до выбора платформы: глоссарий EFSOL выделяет ее в отдельный шаг выбора.
Что сделать сейчас: до подписания задать провайдеру два вопроса:
- •в каком формате и какими средствами отдаются данные;
- •что будет с кодом и конфигурацией при переезде.
Что уедет без потерь
Код на стандартных средах выполнения — Node.js, Python, Java, .NET — переносится вместе с приложением: новый провайдер разворачивает те же файлы. Данные в открытых СУБД PostgreSQL и MySQL выгружаются стандартным дампом и подключаются на новом месте без конвертации.
Переменные окружения и конфигурация переезжают без потерь, если они описаны отдельно от панели провайдера. Пример: API на Node.js с базой PostgreSQL переезжает к другому провайдеру или на свои серверы с настройкой окружения, а не с переписыванием логики.
Что придется переписать
Код, завязанный на фирменные сервисы и лимиты платформы, переносится с трудом. В Oracle Process Automation в одном процессе не больше 100 шагов, и логику, построенную под такие рамки, на новом месте собирают заново.
Управляемая Kafka переносится нормально, если интеграции написаны без привязки к API конкретного провайдера.
На что обратить внимание: каждый удобный фирменный сервис экономит время сейчас и добавляет работы при переезде.
7 вопросов для выбора модели
- •Команда разработки? Нет или процесс типовой — SaaS, есть и задача своя — PaaS.
- •Инструмент или продукт? Инструмент — SaaS, продукт — PaaS.
- •Срок? Неделя — SaaS, 3–5 месяцев — PaaS.
- •Процесс? Типовой — SaaS, уникальный — PaaS.
- •Контроль над данными? Настройки — SaaS, код и база — PaaS, полный — on-premise.
- •Переносимость? Хватит выгрузки данных — SaaS; PaaS — только на стандартных средах и открытых СУБД, иначе on-premise.
- •Нагрузка? Растет от сотрудников — SaaS, от клиентов — PaaS.
Пример: нет команды, процесс типовой, запуск через неделю — вопросы 1, 3 и 4 ведут к SaaS.
На что обратить внимание: два и больше ответа за PaaS без команды значат, что сначала нужна команда.
Что сделать сейчас: ответить письменно вместе с ответственным за бюджет.
Выбрать уровень и посчитать смету: бесплатная оценка, разработка продукта на PaaS — от 600 000 ₽.
Источники
