Архитектура SaaS

Question

[miolini]

Здравствуйте!

Вопрос к подходу построения SaaS сервиса. Вам нужно разработать массовый SaaS сервис. Какой подход вы выберите?

1. Для каждого клиента инсталлируется копия системы со своей базой данных (возможно на отдельный вычислительный юнит). Пример — Microsoft Exchange.
2. Система пишется с учетом множества клиентов, не требует отдельных инсталляций и работает в единой базе данных. Пример — Basecamp.
3. Другой подход — опишите.

Answer 1

[Александр]

Не совсем понятно, какого рода SaaS имеется в виду. Я почему-то подумал сразу о таком сервисе, как Amazon.
Использовал бы Citrix XEN или Eucalyptus

Comments

[miolini]

Если вы имеете в виду Amazon, то это возможно Amazon Web Services (AWS) — это не SaaS, а IaaS.

[fvm]

Ну и правильно все. Amazon даёт infrastructure, вы на ней запиливаете свой software. К чем геморой с администрированием металлолома? Делайте то, что умеете делать лучше всех. Ну и, соответственно, солидарен с первым подходом. К чему шарить данные между клиентами. Да и вот, на вскидку, способ монетизации: вывод saas приложения на собственный сервер — 1000 евро. Реализовать это много проще при варианте, когда все лежит по отдельности.

Answer 2

[4dmonster]

Мне кажется лучше выбрать третий пункт:
Систему надо писать для второго варианта, но предусмотреть инструменты для перевода части клиентов на первый вариант и наоборот.

Answer 3

[Павел Назаров]

Я думаю, это зависит от масштабов. Если сервис действительно массовый, то более логичным выглядит второй вариант, так как меньше накладные расходы на отдельные БД для каждого пользователя. Если вы не предоставляете тем или иным образом прямогодоступа к СУБД (а скорее всего, нет, тк в SaaS-е это не актуально), то вопрос безопасности на уровне СУБД вас не коснётся, и работа множества клиентов в единой БД (не важно даже, в одной или нет схемах) не вызовёт проблем.

Но, на мой взгляд, это не самый корневой вопрос в архитектуре SaaS, и он (как деталь реализации, в общем-то) будет сокрыт от программистов за какой-нибудь прослойкой :)

Comments

[miolini]

Я считаю наоборот — это корневой вопрос. Потому как это влияет прямым образом на разработку, тестирование и вводом в эксплуатацию нового функционала. Во-втором варианте несколько осложняется код, т.к. нужно учитывать конкретного клиента. Усложняется и схема БД. Правда обновлять систему на порядок проще.

[Павел Назаров]

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

Единственая проблема в DB-per-user-схеме в том, что для каждого юзера нужно создавать новую БД со всеми общими данными (аля классификаторы/справочники), что займёт некоторое время. + такие общие данные будут дублироваться для всех юзеров.

[miolini]

Общие данные можно вынести в качестве внешних для экземпляра сервисов.

Answer 4

[Макс Кузнецов]

Тоже задаюсь этим вопросом и склоняюсь ко второму варианту, но лишь в силу специфичности своего SaaS'a: работа без перерыва 24 часа в сутки, 7 дней в неделю и полная кастомизация / допиливание / разработка под нужды каждого конкретного клиента. Считаю, что будет такой разброс вариаций сервиса, что в одну базу не уместить. К тому же, имхо, расширяться проще — закупкой нового железа. Один клиент — один экземпляр, и никаких путаниц.

Comments

[miolini]

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

[Павел Назаров]

Как это «одного экземляра (всмысле масштабирования) мало»?
Т.е. базу никак не смасштабировать и бизнес-логику тоже? Тогда здесь явно что-то не то.