При создании размещенного приложения /SAAS, как вы управляете несколькими версиями, когда пользовательские настройки разрешены?
Представим, что вы создаете приложение для калькулятора. Вы позволите клиентам настраивать этот калькулятор с помощью собственных логотипов и таблиц стилей CSS. Клиенты будут указывать свои домены на ваш размещенный калькулятор, и приложение будет подбирать правильную тему для каждого клиента. Например:
- www.AcmeCalculator.com представит калькулятор с логотипом Acme и мягким фирменным стилем, который они создали.
- www.HellzCalc.com запустит в Калькулятор калькулятор с некоторыми знаками байкеров "Ангелов Ада" и черной кроваво-красной темой, которую они создали.
Вы выпустили Calculator 1.0, и каждый написал свой стиль для работы над этой версией.
В следующем месяце вы готовы к выпуску Calculator 1.1, который добавил новую функцию, скажем, "Scientific Mode", которая потребовала от вас добавить несколько новых UI - HTML в этом примере - компонентов. Это означает, что если вы выйдете 1.1, вы нарушите некоторые стили вашего клиента.
Лучшее решение, которое я придумала, это то, что вы поддерживаете несколько версий своего приложения. Например:
- www.AcmeCalculator.com обращается к вашему серверу приложений, который проверяет, какая версия Acme в данный момент включена, и пересылает на www.AcmeCalculator.com/1.0.
- www.HellzCalc.com разрешает доступ к вашему серверу приложений, который замечает, что они работают на новой версии 1.1, так как они обновили свой CSS для работы с новой версией и нажали кнопку "Завершить обновление" или что-то еще, чтобы они получили перенаправлен на " www.HellzCalc.com/1.1
Одна из проблем этой системы заключается в том, что у вас неизбежно будут ленивые клиенты, которые никогда не вкладывают средства в модернизацию. Вы будете одновременно запускать 200 версий, пытаясь исправить ошибки в каждой из них, в основном сходя с ума.
Одним из решений будет использование части вашей ежемесячной платы за хостинг для привлечения "UI Migration Team", которая будет представлять собой группу дизайнеров, единственной задачей которых является постоянное получение клиентов в очереди, использующих самые старые версии, настройка их CSS и проверка их на запустить на новейшей версии. Это позволило бы вам одновременно поддерживать только версии X, где X - это функция, определяющая, сколько денег вы вкладываете в команду миграции пользовательского интерфейса, добавляя ресурсы для их ускорения или замедления.
Та же идея будет работать с изменениями базы данных: Calculator 1.0 и 1.1 работает на базе данных 1.0, но Calculator 1.2 работает на базе данных 1.1 и т. Д. Вы можете просто добавить схемы с именами версий и использовать аналогичную "команду миграции данных" для перемещения данных из от схемы 1.0 до схемы 1.1, наконец, удаляя схему 1.0, когда не осталось (app) клиентов.
Я уверен, что этот тип проблемы возник раньше, и я хотел бы увидеть, как другие решили ее. Возможно, есть даже "лучшие практики" для этого.
3 ответа
Если вы не находитесь в корпоративной среде, и ваши клиенты не требуют значительных настроек своего приложения, и вы можете взимать с них соответствующую плату, я бы этого не допустил. Как вы обнаруживаете, это вершина айсберга кошмара управления продуктами. Одна из причин, по которой SaaS стал настолько популярным, заключается в том, что очень сложно управлять разными людьми в разных версиях, и сложно заставить людей обновиться.
Сделав это несколько раз (я являюсь менеджером по продукту, а не инженером, так что я, вероятно, чувствую боль почти так же сильно, как инженеры, которые должны внедрять), я бы предложил настраиваемые параметры. Зачастую вы можете брать дополнительные деньги за этот тип конфигурации. То есть базовая цена практически не требует настройки, а более высокие уровни позволяют настраивать CSS, создавать бренды и т. Д. См. Пример на JobScore.com. Хорошая причина для того, чтобы брать деньги за это, заключается в том, что меньшие компании не заботятся и не будут платить, но более крупные компании хотят эту функцию и не будут особо заботиться о стоимости. Получение такого рода ценовой надбавки имеет решающее значение для успешного SaaS-продукта: большинство SaaS-компаний получают 80% своих доходов от "корпоративной" версии своего продукта, поэтому вам необходимо установить соответствующую цену. Если ваш верхний уровень составляет 99 долларов в месяц, а WalMart регистрируется и использует его по 99 долларов в месяц во всей своей компании, вы многое оставите на столе.
В любом случае, вернемся к первоначальному вопросу: не допускайте использования разных версий, которые могут буквально убить вашу компанию. Вместо этого предложите конфигурации / переменные.
Вместо параллельных настраиваемых версий реализуйте одну настраиваемую версию, доступную для всех ваших клиентов.
Это создаст вам больше проблем при кодировании, но когда вы запустите свое приложение и будете работать, вам останется только беспокоиться о том, каковы ваши новые потребности, а не о том, что эти новые потребности сломают.
Вот хорошая статья, которую я нашел о лучших методах управления версиями сервисов программного обеспечения, и я считаю, что то же самое относится и к вашему вопросу. Это в основном описывает два возможных варианта, а также плюсы и минусы каждого из них.
- Поддерживать разные версии программного обеспечения.
- Поддерживать единую базовую версию программного обеспечения.
http://www.thbs.com/thbs-insights/soa-service-versioning-best-practices
При развертывании корпоративного продукта SAAS в какой-то момент станет неизбежным, что вы будете поддерживать несколько версий своего программного продукта (риск потери клиентов, если вы не поддерживаете такую стратегию). У этого подхода есть некоторые преимущества, в частности, тот, который поддерживает массовое переписывание API / сервисов, если это необходимо, и при этом не увязает в проблемах обратной совместимости. Однако было бы неосторожно поддерживать более 200 версий программного обеспечения, и поэтому необходим баланс, ограничивающий количество поддерживаемых версий, а также имеющий устаревшую стратегию, чтобы подтолкнуть клиентов к последней версии продукта.