Разработка облачного сервиса: от идеи до production-ready SaaS

Облачный сервис — это любой программный продукт, который работает на удалённой инфраструктуре и доставляется клиенту через интернет. Внутри этого широкого определения живут разные модели: SaaS (программа как услуга), IaaS (инфраструктура), PaaS (платформа), FaaS (функции по запросу), API-сервисы и BaaS (бэкенд как услуга). Если вы переводите бизнес в облако, важно понимать, какой именно сервис вы строите, какая архитектура подходит, какого провайдера выбрать и каких показателей надёжности достаточно.

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

Облачный сервис vs SaaS: где граница

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

Пять типов облачных сервисов:

• SaaS (Software as a Service). Готовый продукт для пользователя через браузер: CRM, бухгалтерия, мессенджер, аналитика. Битрикс24, amoCRM, Salesforce, Notion.
• PaaS (Platform as a Service). Среда выполнения и базы данных для разработчиков: Yandex Managed Kubernetes, Heroku-подобные платформы.
• IaaS (Infrastructure as a Service). Виртуальные машины, сети, хранилища: Yandex Compute Cloud, VK Cloud Servers.
• FaaS / Serverless. Запуск функций по запросу: Yandex Cloud Functions, AWS Lambda.
• API-сервисы и BaaS. Готовая бизнес-функциональность через API: Dadata, ЮKassa, SmartCAPTCHA, OpenAI.

Если вы продаёте подписку и доступ через браузер — вы строите SaaS. Если продаёте API или вычислительную функцию — это облачный сервис в широком смысле. Архитектурные решения для них пересекаются, но не одинаковы.

Архитектура облачного приложения: три подхода

Модульный монолит

Одна кодовая база, одна СУБД, один деплой. Внутри — модули с чёткими границами: подписки, пользователи, биллинг, события. Применяется почти всегда на старте: дешевле в разработке, проще в эксплуатации, меньше latency между компонентами. Типичный стек в РФ: Python (Django/FastAPI) или Node.js (NestJS) + PostgreSQL + Redis. Подходит до 100-500 клиентов и до 50-100 запросов в секунду.

Микросервисы

Разделение по бизнес-доменам: отдельный сервис на платежи, отдельный — на уведомления, отдельный — на отчёты. У каждого своя БД и своя команда. Применяется, когда: несколько команд работают параллельно; компоненты системы должны масштабироваться независимо (например, обработка отчётов в 10 раз нагруженнее, чем биллинг); требуется высокая доступность отдельных частей. Минусы: сетевые вызовы вместо локальных, сложность распределённых транзакций, рост накладных расходов на инфраструктуру в 2-3 раза.

Serverless и FaaS

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

Типичная зрелая архитектура для SaaS на 1000 клиентов: модульный монолит-ядро с подписками + Managed PostgreSQL + Redis + 2-3 serverless-функции для фоновых задач + микросервис для тяжёлых операций (например, генерации отчётов). Это и есть «правильное» облачное приложение в 2026 году для B2B SMB-сегмента.

Облачные провайдеры РФ: где разворачивать

Провайдер	Сильные стороны	Слабые стороны	Цена
Yandex Cloud	Managed-сервисы, удобная консоль, Terraform	Меньше готовых интеграций с европейскими сервисами	средне-низкая
VK Cloud	Государственный и корпоративный сегмент	Меньше документации, медленнее развитие managed	средне-низкая
SberCloud	Финтех, enterprise, ИБ-аттестации	Высокий порог входа, дороже	высокая
Selectel / Timeweb Cloud	Дешёвые VPS, простое подключение	Меньше managed-сервисов	низкая

Выбор сводится к двум критериям: где у целевого клиента уже есть аккаунт (часто решает) и какие managed-сервисы вам нужны без самостоятельного администрирования. Большинство B2B SaaS-стартапов в 2024-2026 годах стартуют в Yandex Cloud — это самый зрелый по managed-инструментам российский провайдер.

Стоимость инфраструктуры

На старте (до 100 клиентов):

• 1-2 ВМ под backend (4-8 vCPU, 16-32 ГБ) — 8-15 тысяч ₽/мес.
• Managed PostgreSQL (4 vCPU, 16 ГБ, 100 ГБ диск) — 12-20 тысяч ₽/мес.
• Redis — 3-5 тысяч ₽/мес.
• S3-совместимое объектное хранилище — 1-3 тысячи ₽/мес.
• Балансировщик нагрузки — 1,5-3 тысячи ₽/мес.
• Бэкапы — 2-5 тысяч ₽/мес.

Итого: 30-60 тысяч ₽/мес по on-demand тарифу, 20-40 тысяч при reserved на год.

На 1000 клиентов: 150-300 тысяч ₽/мес. Расходы на инфраструктуру обычно составляют 5-15% от выручки SaaS. Если у вас выходит больше — у вас или дорогой стек, или слабая монетизация.

SLA для B2B: что обещать клиенту

Стандартный диапазон для B2B SaaS:

• 99,9% — 8,76 часа простоя в год. Базовый уровень для SMB.
• 99,95% — 4,38 часа. Подходящий уровень для среднего B2B.
• 99,99% — 52 минуты. Требует резервирования по регионам, втрое дороже инфраструктура. Оправдано для финтеха.

Что входит в SLA-документ:

• Доступность API и UI в процентах за период.
• Скорость реакции поддержки по приоритетам (P1 30 минут, P2 4 часа, P3 24 часа).
• Окно регламентных работ (например, ночь субботы с уведомлением за 7 дней).
• Штрафы при невыполнении: обычно кредит на будущий период (5-20% подписки).
• Что не входит в SLA: проблемы на стороне клиента, форс-мажор, регламентные работы.

Ваш SLA клиентам не может быть выше, чем у вашего провайдера. Yandex Cloud и VK Cloud дают 99,95% на managed-PostgreSQL и 99,9% на ВМ.

Безопасность данных и регуляторика

Облачный сервис в РФ обязан соблюдать:

• 152-ФЗ «О персональных данных» — хранение в РФ, согласие пользователя, ответственный по защите данных.
• 54-ФЗ — онлайн-кассы и фискальные чеки для любых платежей физлиц, включая ИП без сотрудников.
• 187-ФЗ — если работаете с критической информационной инфраструктурой (для энергетики, банков, транспорта).

Базовый набор безопасности:

• Шифрование данных при передаче (TLS) и хранении (диски ВМ, бэкапы).
• Изоляция сетей и групп безопасности.
• Бэкапы с тестируемым восстановлением.
• Логирование действий и хранение журналов 90+ дней.
• Регулярные обновления зависимостей и сканирование уязвимостей.

Для SaaS подробнее об архитектурных решениях по изоляции данных арендаторов — в гиде по архитектуре SaaS-платформ, а о биллинге и 54-ФЗ — в материале о приёме платежей онлайн.

Сроки разработки облачного приложения

Этап	Длительность	Что происходит
Архитектура и инфраструктура	2-3 недели	Выбор провайдера, развёртывание базовой инфры, CI/CD
Ядро функциональности	6-10 недель	Backend, frontend, авторизация, базовые модули
Биллинг и интеграции	3-5 недель	Платёжный шлюз, ОФД, внешние API
Тестирование и обкатка	2-3 недели	Нагрузка, безопасность, восстановление

Итого 13-21 неделя или 3-5 месяцев. Команда — 4-7 человек в эквиваленте полной занятости: продакт, архитектор, 2 разработчика, frontend, QA, DevOps.

Что упускают чаще всего

• Привязка к одному провайдеру (vendor lock-in). Используйте абстракции для сервисов, которые есть у разных провайдеров (объектное хранилище, очереди), и стандартные интерфейсы (Postgres, Redis). Это даст возможность мигрировать без переписывания.
• Нет инфраструктуры как кода. Конфигурация в Terraform или Pulumi с первого дня. Иначе через полгода вы не сможете воспроизвести окружение.
• Игнорирование наблюдаемости. Метрики, логи и трассы — это не «потом». Закладывайте Prometheus или Grafana Cloud с релиза.
• Отсутствие плана восстановления (DR). Что если основной регион упал на 6 часов? Сценарий должен быть отрепетирован, а не записан в Confluence.

Что дальше

Если вы определились, какой облачный сервис строите, и понимаете архитектурный путь — следующий шаг это предпроектное обследование с архитектором: 2-3 недели работы, на выходе техническое задание, диаграмма облачной инфраструктуры, оценка бюджета и сроков по этапам. Это даст вам осязаемый план разработки облачного приложения и точку отсчёта для общения с командой и инвесторами. Если в продолжение вы переходите к продуктовой части — переходите к гиду по разработке SaaS под ключ.