Вопрос архитектуры Azure

Question

Скажите, пожалуйста, верны ли мои рассуждения ниже.

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

Это означает, что вы не можете начать создавать критически важное для бизнеса приложение Azure, а затем в конце концов по каким-то причинам решили разместить его старомодным способом (возможно,Вы не довольны производительностью или чем-то еще).

Я правильно понимаю?

Answer 1

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

При этом большая часть того, что Azure делает для вас, может быть реплицирована с помощью комбинации баз данных, очередей (например, MSMQ или Tibco), сетевых файловых систем и т. Д. Базы данных NoSQL, такие как HBase , обеспечивают масштабируемость размещать облако в вашей собственной инфраструктуре, но для этого потребуется пересмотреть некоторые предположения, которые вы сделали относительно доступа к данным. Microsoft также продает устройство для частного облака , которое локально реплицирует среду Azure.

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

Answer 2

Если вы проектируете свою бизнес-систему с учетом развязки и доменного дизайна , тогда будет легко перейти в облако (Azure, Amazon и т. Д.), Масштабировать, распространять или делать что угодно нужен.

Только несколько вещей, которые нужно иметь в виду:

• Сообщения
• Домен-управляемый дизайн
• Принципы CQRS Architecture .

Answer 3

Я считаю, что когда дело доходит до IaaS (ОС, среда хостинга), переход на OnPremise может быть не сложным. Но если мы интенсивно используем различные сервисы, которые поставщик облачных услуг предоставляет в качестве части PaaS, то нам придется столкнуться с этим бременем во время миграции.

Answer 4

Существует два основных подхода к этому:

1. Вы можете переместить приложение на себя, не внося никаких изменений, запустив приложение Azure. http://www.microsoft.com/windowsazure/appliance/

2. Вы можете спроектировать решение так, чтобы не использовать функциональность, характерную для Azure. Например, хранить данные в SQL Azure, а не в хранилище таблиц Azure. Веб-интерфейс, встроенный в ASP.Net MVC, будет работать в Azure и IIS.

Answer 5

Да, но все же ... если вы, например, напишите приложение Azure для клиента и развернете его в облаке: -Что если клиент позже решит, что он хочет разместить его для себя? (Может быть несколько причин: производительность, безопасность, нестратегическая привязка к поставщику, стоимость и т. Д.) В этом случае вам придется снова привлекать разработчиков, протестировать его и т. Д. (Это могут быть или не быть одни и те же люди ). Вы не можете перейти на традиционный хостинг, просто изменив одну строку какого-либо параметра конфигурации и т. Д. (Если, конечно, вы изначально не сконструировали его «для двух платформ» с самого начала, не протестировали его для обеих платформ и т. Д.

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

А как насчет этих ролей в Интернете? Это что-то, что блокирует вас в Azure? Это легко можно перенести в традиционное веб-приложение ASP .NET / службу Windows?

Извините, что вы такой скучный скептик! ; -)