Несколько экземпляров для приложений - по одному для каждого клиента?

Я думаю о том, чтобы предлагать мой продукт как услугу - доставлять через Интернет. В настоящее время это сжатое программное обеспечение, которое пользователи загружают на свои серверы и запускают на своих серверах - например, fogbugz.

В моей новой бизнес-модели я предлагаю два бизнес-режима, один из которых представляет собой традиционное программное обеспечение, упакованное в термоусадочную пленку, которое пользователи устанавливают на своих серверах, и выполняет все техническое обслуживание, обновление. Другим является тип программного обеспечения как службы (SaaS), где хостинг выполняется на моих серверах, а пользователям предоставляется один URL для входа в систему. Конечно, у каждой учетной записи клиента будет уникальный URL-адрес, например companya.mysoft.com, companyb.mysoft.com.

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

Что вы думаете об этом несколько экземпляров-один для каждого клиента? Или я должен изменить свой код, чтобы поддерживались оба режима (легко поддерживать и обновлять)?

Изменить: требуется версия для загрузки , избежать этого невозможно.

Изменить 2: Мое приложение - это приложение PHP.

Ответ 1

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

Важные детали для рассмотрения включают:

Сегрегация данных очень важна, поддержка и обновление тысяч отдельных баз данных сопряжено с большими накладными расходами. Основная проблема заключается в том, что клиенты будут беспокоиться о том, что их данные смешиваются с кем-то другим, и это как-то менее безопасно. Я работал в трех разных компаниях, которые предлагали модель SaaS, и смешивание данных не было проблемой для клиентов. В конце дня у вас будут все данные, и они будут или не будут безопасными, на самом деле не имеет значения, сколько dbs вы используете. Если у вас никогда не будет более нескольких десятков клиентов, я настоятельно рекомендую объединить несколько клиентов в единую базу данных и поддерживать несколько dbs, это упрощает управление базами данных. Я работал с системой с несколькими данными PetaBytes для клиентов > 80 тыс., Которые распространялись через пару десятков баз данных, и это было вполне управляемо. Я работал с системой с несколькими TeraBytes данных для нескольких десятков клиентов, каждый со своей собственной БД, и это работало довольно хорошо. Тогда однажды мы получили большое дело, которое добавило 300 клиентов сразу и управление базами данных было неудобно очень быстро.

Брендинг, каждый клиент - отдельный бренд, или многие клиенты разделяют бренд, или все рады использовать бренд ваших компаний. В идеале вы можете найти ресурсы бренда (css/images/etc.) По URL-адресу или логину или, возможно, обоим. Если вам понадобится только несколько брендов, может быть разумно настроить серверы для каждой марки.

Версии, разумно ли "заставить" всех клиентов обновляться одновременно. Я настоятельно рекомендую вам сделать все, что в ваших силах, чтобы держать всех клиентов в одном выпуске, поддерживая несколько выпусков, значительно повысит ваши затраты на поддержку. Как правило, легко вращать "у вас всегда самый последний и самый большой" фасет, но некоторые клиенты действительно неблагоприятны для изменения. Клиенты, которым может потребоваться оставить, должны быть в отдельных случаях.

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

Ответ 2

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

Однако есть альтернатива. Храните базу данных одинаково и установите новый экземпляр базы данных для каждого клиента. Но измените свой интерфейс, чтобы он мог обрабатывать несколько URL-адресов. Таким образом, вы должны иметь только один экземпляр приложения, работающего против нескольких баз данных, в зависимости от URL.

Это также очень хорошо масштабируется, и я думаю, что это модель FogBugz? Тогда, если ваши клиенты хотят его установить, на самом деле нет никаких изменений, потому что у них будет только один URL-адрес, указывающий на одну базу данных. И на вашей стороне у вас будет несколько URL-адресов, указывающих на несколько баз данных, просто программное обеспечение будет работать только после обработки всех этих запросов.

Также, как приятно иметь, вы можете захотеть рассмотреть пользовательские домены. Вместо companya.mysoft.com разрешите companya.com. Это не потребует каких-либо реальных изменений в обработке URL-адресов, а команде просто нужно будет установить запись CNAME и указать ее на своем сервере.

Удача

Ответ 3

"Плохо то, что существует много избыточности и не может быть масштабируемым".

Действительно? Где избыточность?

Если вы использовали хороший набор инструментов, ваша установка SaaS может содержать одну базу кода, используемую несколькими клиентскими сайтами.

Он работает следующим образом.

В некотором базовом каталоге (мы используем такие каталоги, как /opt/theApp) у вас есть программное обеспечение.
В некотором рабочем каталоге (мы используем примеры каталогов /var/www/cust1, /var/www/cust2) у вас есть некоторые файлы конфигурации, которые ссылаются на код.

Одна база кода, несколько установок. В Django (и многих других веб-фреймворках) это относительно легко.

Если вы неправильно выбрали свои инструменты, то один сайт - одна полная копия кода, и у вас есть потенциальная проблема. Однако для этого нужны ссылки. У вас есть "копия", специфичная для клиента, включая "мягкие" ссылки на исходную копию.

После того, как вы попытаетесь разобрать "специфические для клиента функции" из "веб-установки" и "базового кода", вы обнаружите, что можете отлично выполнять QA и предоставлять специфические для клиента функции и расширения.

Несколько экземпляров масштабируются больше. Вы можете без особых трудностей распространить среду SaaS на несколько параллельных процессоров. Каждый экземпляр, специфичный для клиента, обслуживает данные клиента, обеспечивая чистое разделение клиентов. Они могут (если вы справляетесь с этим правильно), все используют общую базу кода, установленную на одном (и только одном) сервере.

Отдельные установки на одного клиента (с общей базой кода) очень приятны для обеспечения клиентов тем, что их данные не случайно отображаются с их данными конкурентов.

Ответ 4

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

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

Ответ 5

Трудно ответить на этот вопрос без дополнительной информации, но с такими проблемами брендинга/многопоточности, один из ключевых вопросов, который нужно задать, заключается в следующем:

Являются ли эти сайты (для разных клиентов) более похожими на разные?

Теперь, когда субъективный вопрос. Сколько стоят два сайта? Можете ли вы количественно оценить это? Не совсем.

Но если ответ: "они почти полностью одинаковы" или даже "они одинаковы" (несмотря на проблемы с брендингом), сделайте себе одолжение и разместите только одну версию кода и укажите на них оба сайта.

Вы можете легко определить, какой сервер был вызван, и соответственно изменить свою логику.

Брендинг - это еще одна проблема, но если вы сделали свое приложение правильно, это должно быть в значительной степени связано с изменением CSS-кода, возможно, ваш Javascript включает (например, стиль jQuery) и (надеюсь, наихудший сценарий), изменяя ваши верхние и нижние колонтитулы (у вас есть глобальные верхние и нижние колонтитулы?).

В принципе, если сайты очень похожи, то передайте код и просто получите исключения для разных. Если они совершенно разные, то делайте наоборот. Соблюдайте наиболее распространенные сценарии.

Ответ 6

DRY говорит, что нет. Лучше добавить в приложение приложение, основанное на ролях, чтобы вы могли легко добавить клиентов 2, 3, 4 и т.д.

Я бы потратил некоторое время на размышления о том, какие изменения для клиентов в вашем приложении и о разработке приложения для управления данными или конфигурацией.

Ответ 7

Из угла БД я бы обязательно пошел с одной БД на модель клиента. Преимущества, связанные с возможностью управления данными каждого клиента независимым образом, являются обязательными. И этот подход позволяет масштабировать, размещая разные данные клиентов на разных серверах по мере роста бизнеса.

Также ваш веб-сервер/сервер приложений должен иметь возможность обрабатывать несколько экземпляров вашего приложения для разных пользователей и клиентов прямо из коробки. Он должен разобрать одну копию кода и несколько сегментов данных (предположим, что модель все еще хранится 20 лет?). Опять же, что масштабируемое - перейдите к веб-ферме, и все это работает, предполагая, что вы можете сортировать свои сеансы.

Таким образом, вы получаете выигрыш/выигрыш, ваша база кода остается практически такой же, и вы получаете масштабируемость в соответствии с используемой вами средой. Вы также можете настроить разные версии, выпуски для клиентов, чтобы попробовать - мы часто поддерживали несколько версий одного и того же сайта, работая параллельно, чтобы мы могли откатиться, если фатальная ошибка ударила нас по новой версии.

Ключом к получению этой работы является просмотр заголовков HTTP и ссылка на конфигурацию, т.е. на какую именно БД и версию программного обеспечения на самом деле указывают на это.