Правилен подход за внедряване на уеб приложение за управление на съдържание за различни акаунти на платформата Azure

Разработвам търговско Asp.Net MVC уеб приложение. Приложението е стандартно, работи на IIS Web Server и използва SQL Server база данни. Нашият бизнес модел е такъв, че внедряваме нашето приложение на място в интранет или център за данни на нашите клиенти. Тоест, за всеки такъв клиент (акаунт) ние доставяме пълната настройка, обикновено инсталирана в специален самостоятелен сървър. Всеки такъв акаунт има собствено лично съдържание, потребители, конфигурации и така нататък.

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

Моля, обърнете внимание, че използвам една и съща кодова база за двата типа внедряване (интранет и облак), като използвам различни конфигурации за отстраняване на грешки, издаване – интранет, етап – Azure, производство – Azure.

Въпреки това, приложението (както е написано сега) може да обслужва само един клиентски акаунт, докато имам нужда от нашата облачна версия, за да обслужва многобройни акаунти (надявам се много;) ... всеки със собствен набор от лични данни.

Въпрос: коя от следните стратегии трябва да използвам тук?

  1. Променете приложението, така че да поддържа множество акаунти. Това означава промени както в модела на данни (добавяне на обект на акаунт в слоя данни, обвързването му с всички типове съдържание и т.н.), така и в бизнес логиката.

  2. Създайте за всеки акаунт собствен сайт в облака (уеб сайт + база данни + услуги за съхранение на файлове). Това означава внедряване няколко пъти на едно и също приложение в различни услуги на Azure.

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

Не ми е ясно обаче как да управлявам набор от много идентични услуги (приложения), всяка от които обслужва различен клиентски акаунт. Започнах да търся някои инструменти, които да ми помогнат тук (напр. 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-то издание

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

  • Единичен екземпляр, множество наематели (първата ми опция)
  • Много екземпляри, един наемател (втората ми опция)

Както изглежда, ще използвам подхода с множество наематели. Като се имат предвид всички неща, изглежда, че ще изисква по-малко усилия за разработка и ще изисква по-малко усилия за поддръжка. Освен това моята експертиза е в разработването на приложения и по-малко в системното администриране (което е необходимо за истинско внедряване на решение с няколко екземпляра).

Други причини: има нужда да се споделя част от съдържанието между акаунти (наематели) и това ще бъде по-лесно постигнато, когато се използва една база данни. Освен това има бъдещи планове за продукта, който може да използва това решение.

Ще бъде направено Сегрегиране на данни (високо ниво):

  • Съхранение на файлове (блобове): използвайте отделен контейнер за всеки наемател (акаунт).

  • База данни: използвайте уникален ключ на клиента, за да свържете съдържание с клиента

  • Cahce: използвайте уникален ключ на клиента, за да генерирате кеш ключове за кеширани елементи от данни.

Мащабируемост: по-лесно е с помощта на един екземпляр просто да увеличите неговите възможности или дори да преместите уеб сайта на специална виртуална машина. В бъдеще може също да подобри системата до структура Multi-instance, Multi-tenant, създавайки нови отделни екземпляри за големи наематели.

person yarg    schedule 02.04.2014