Предотвращение блокировки поставщиков: полностью ли переносим код, написанный для Windows Azure, в автономный IIS / ASP.NET? - PullRequest
1 голос
/ 22 февраля 2011

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

Мне очень нравится идея использовать решение Platform-as-a-Service, такое как Azure, потому что мои навыки администрирования сервера не так сильны, как мои навыки разработки.Таким образом, возможность сосредоточиться только на приложениях и сторонних задачах, таких как резервное копирование / балансировка нагрузки / и т.д.привлекателен для меня.

ОДНАКО, я также обеспокоен блокировкой поставщика.Я ожидаю, что поля в моем приложении будут довольно узкими, и я должен внимательно следить за контролем затрат.Если я выберу решение PaaS, такое как Azure, и MS решит существенно повысить свои цены, я бы хотел довести свой бизнес до более дешевого поставщика.

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

Вопрос
Являются ли приложения Azure, как правило, переносимыми в не облачные версии IIS / ASP.NET, что позволяет легко переносить их на одного из многочисленных поставщиков IaaS / HaaS без особыххирургия?

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

Ответы [ 3 ]

6 голосов
/ 23 февраля 2011

Нет, для "веб-сайтов" Microsoft в настоящее время не вынуждает вас писать код очень специфично для Azure - веб-роль - это просто веб-сайт.

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

Однако, если вы начнете включать: - рабочие роли - хранение таблицы, блоба или очереди - расширенная настройка Azure - Лазурная диагностика - управление Azure (например, для масштабирования или развертывания)

тогда вы начнете включать специфическую функциональность Azure.

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

1 голос
/ 02 октября 2011

Блокировка будет присутствовать в каждой системе, которую вы решите использовать, особенно если вы говорите о PaaS, который вы будете использовать для своих онлайн-сервисов.Это вопрос уровня по сравнению с другими поставщиками.В ходе глубокого исследования, проведенного мной на облачном рынке, включая IaaS и PaaS (в двух разных публикациях я обнаружил, что Azure обладает наивысшим уровнем привязки к поставщику PaaS, который на самом деле не соответствует его преимуществам.- Cloud Lock-In (Часть 2): Великий Lock-in PaaS - http://www.iamondemand.com/post/10120499126/the-cloud-lock-in-part-2-the-great-lock-in-of-paas

Я буду рад узнать, помогло ли это вам. Ofir.

1 голос
/ 24 февраля 2011

Это как-то.

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

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

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

...