Можно ли спроектировать веб-приложение, чтобы оно могло быть развернуто либо в облаке, либо на выделенном сервере / VPS?Как?

Question

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

Приложение будет ASP.NET и / или ASP.MVC. Моя среда разработки - VS 2010. Облако может быть или не быть Azure. Выделенный или VPS будет Win Server 2008. Вероятно.

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

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

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

Answer 1

Да, это возможно.Istelf веб-приложения (MVC или Webforms), вероятно, останется прежним (с изменениями конфигурации).

Если вы рассматриваете Windows Azure в качестве варианта «облачного» развертывания, то следует учитывать следующие основные моменты:

Веб-приложение:

• Управление сессиями: вам придется использовать дружественный к веб-ферме подход (например, нельзя использовать состояние сеанса на стороне сервера в памяти)
• Использование полосы пропускания: при развертывании в облаке задержки превышают 100% локально, вы также платите больше за большее количество битов, отправляемых туда и обратно.Существует стимул для создания более экономных приложений.
• Механизм аутентификации: если вы хотите предложить единый вход, вам, вероятно, нужно перейти на подход, основанный на утверждениях (с использованием WIF).Это в значительной степени то, что вы можете изолировать и изменить (например, локальная встроенная безопасность Windows, заявки на основе облака)
• Использовать всех стандартных поставщиков (например, профиль, членство, отслеживание и т. Д.).Существует множество реализаций Win Azure, поэтому вы можете просто изменить их.

Данные:

• Самый простой подход для максимальной переносимости - использоватьSQL Azure, который является (большим) подмножеством SQL Server.
• Если вы используете другую систему хранения (например, таблицы Windows Azure и т. Д.), То вам необходимо абстрагировать весь доступ к данным в приложении (гораздо сложнее)
• Помимо некоторых функций, недоступных в SQL Azure (например, SQLCLR, SQL Broker), существуют ограничения на размер базы данных (в настоящее время макс. = 50 ГБ).Итак, если базы данных вашего клиента выросли за пределы этого, вам нужно разделить базу данных (что добавляет сложности, но это выполнимо)

Управление:

• Если вы используете стандартные методы ведения журнала и трассировки (например, Systems.Diagnostics и т. Д.), Приложение останется практически неизменным.Ваши процессы должны быть адаптированы (и ваши сценарии и т. Д.)

Более подробная информация доступна здесь .

Я не знаю, для чего вы пытались учесть очереди сообщений, но вы также можете абстрагироваться от них (например, MSMQ для локальной системы, Windows Azure Queue для облака).Вам придется учесть некоторые семантические различия, но это выполнимо.