Правильный подход к развертыванию веб-приложения управления контентом для разных учетных записей на платформе Azure.

Я разрабатываю коммерческое веб-приложение Asp.Net MVC. Приложение является стандартным, работает на веб-сервере IIS и использует базу данных SQL Server. Наша бизнес-модель такова, что мы развертываем наше приложение на месте во внутренней сети или центре обработки данных наших клиентов. То есть для каждого такого клиента (аккаунта) мы поставляем полную установку, обычно устанавливаемую на выделенном автономном сервере. У каждой такой учетной записи есть свой личный контент, пользователи, конфигурации и так далее.

Мы хотим расширяться и предлагать наши услуги в WWW (общедоступном Интернете). После некоторых исследований я выбрал облачную платформу Microsoft Azure для размещения нашего приложения. С небольшими усилиями (в основном, с обучением приложения работать с хранилищем файлов Azure с помощью больших двоичных объектов) мне удалось полностью развернуться в облаке с использованием трех облачных служб: веб-сайта, базы данных и хранилища файлов.

Обратите внимание, что я использую одну и ту же кодовую базу для двух типов развертывания (Интранет и Облако), используя разные конфигурации для Отладки, Выпуска — Интранет, Промежуточного этапа — Azure, Производство — Azure.

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

Вопрос: какую из следующих стратегий мне здесь следует использовать?

  1. Измените приложение, чтобы оно поддерживало несколько учетных записей. Это означает изменения как в модели данных (добавление объекта Account на уровне данных, привязка его ко всем типам контента и т. д.), так и в бизнес-логике.

  2. Создайте для каждого Аккаунта свой сайт на облаке (веб-сайт + база данных + сервисы хранения файлов). Это означает развертывание одного и того же приложения несколько раз в разных службах Azure.

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

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

Другой вопрос — стоимость. Является ли такое решение, использующее множество облачных сервисов вместо нескольких, более дорогостоящим, чем более стандартный подход «одно приложение для всех учетных записей».

спасибо,


azure asp.net-mvc multi-tenant multi-instance-deployment
person yarg    schedule 31.03.2014    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Я бы рекомендовал (1). Это более высокая краткосрочная стоимость с точки зрения усилий по разработке, но будет лучше по двум причинам в долгосрочной перспективе:

  1. Более дешевый. Затраты значительно вырастут за счет добавления дополнительных облачных сервисов. Я полагаю, вы могли бы переложить эти расходы на своего клиента?

  2. Становится сложнее управлять выпусками для многих клиентов.

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

Стоит отметить, что существует множество отличных SDK для автоматизации развертывания, масштабирования облачных сервисов и т. д.

person ryan1234    schedule 31.03.2014

arrow_upward
0
arrow_downward

Нашел хорошее чтение по этой проблеме:

MSDN: разработка многопользовательских приложений для облака, 3-е издание

Обеспечивает хорошее сравнение между двумя подходами:

  • Один экземпляр, несколько арендаторов (мой первый вариант)
  • Несколько экземпляров, один клиент (мой второй вариант)

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

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

Разделение данных будет выполнено (высокий уровень):

  • Хранилище файлов (BLOB-объекты): используйте отдельный контейнер для каждого клиента (учетной записи).

  • База данных: используйте уникальный ключ арендатора, чтобы связать контент с арендатором.

  • Cahce: используйте уникальный ключ клиента для создания ключей кэша для кэшированных элементов данных.

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

person yarg    schedule 02.04.2014