Как избежать привязки к поставщику: полностью ли переносим код, написанный для Windows Azure, на собственные IIS/ASP.NET?

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

Мне очень нравится идея использования решения «Платформа как услуга», такого как Azure, потому что мои навыки администрирования серверов далеко не так надежны, как мои навыки разработки. Таким образом, возможность сосредоточиться только на приложении и аутсорсинге, таких как резервное копирование / балансировка нагрузки и т. Д. привлекателен для меня.

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

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

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

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


azure paas cloud-hosting iaas portability
person JohnFx    schedule 22.02.2011    source источник

Ответы (3)


arrow_upward
6
arrow_downward

Нет, для «веб-сайтов» Microsoft в настоящее время не принуждает вас писать код особым образом для Azure — веб-роль — это, по сути, просто веб-сайт.

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

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

затем вы начнете включать специальные функции Azure.

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

person Stuart    schedule 22.02.2011
comment
Я бы только добавил, что при правильной архитектуре вы можете создать приложение, которое будет легко поддерживать несколько сценариев развертывания (скажем, Azure и onPrem). Обычно я рекомендую, если люди рассматривают возможность этого, они сильно опираются на шаблон провайдера, чтобы любые части, зависящие от среды, можно было легко абстрагировать от вашего основного приложения. - person BrentDaCodeMonkey; 23.02.2011
comment
Какой смысл использовать Azure, если вы не используете хранилище таблиц, очереди или рабочие роли? Вы, вероятно, можете найти более дешевого хостера, если все, что вы ищете, это ASP.NET + SQL Server. - person Panagiotis Kanavos; 25.02.2011
comment
Существует множество способов использования Azure без использования хранилища. Вы всегда можете найти более дешевый хостинг, хотя, как только вы начнете рассматривать услугу корпоративного типа (RackSpace), цены на хостинг вырастут. Для проекта, над которым я недавно работал, где нам нужен был SQL Server и веб-сайт, работающий в течение 3 месяцев, чтобы справиться с где-то между 10 000 и 100 000 пользователей, Azure предложил нам большую гибкость. - person Stuart; 25.02.2011
comment
Кроме того, просто для обеспечения большего баланса вы также можете легко разместить свой веб-сайт за пределами Azure и по-прежнему использовать хранилище таблиц, очередей и BLOB-объектов — для этого есть несколько дополнительных затрат на пропускную способность, и это может сделать приложение немного медленнее, но это жизнеспособное решение. - person Stuart; 25.02.2011

arrow_upward
1
arrow_downward

Это как-то.

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

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

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

person vtortola    schedule 23.02.2011

arrow_upward
1
arrow_downward

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

Буду рад узнать, помогло ли это вам. Офир.

person Ofir Nachmani    schedule 02.10.2011
comment
Я меньше беспокоился о привязке к поставщику и больше беспокоился о привязке к облачной платформе по сравнению с локальным решением. Я был бы согласен перейти с Azure на собственное решение ASP.NET. - person JohnFx; 02.10.2011