Веб-сервисы с Google Apps Engine или Azure? - PullRequest
5 голосов
/ 08 мая 2011

Простая проблема, на самом деле. Я пытаюсь оценить возможности Google Apps, используя Python в качестве языка разработки. Кажется практичным создать веб-приложение или веб-сайт с ним, но как насчет создания веб-служб?
Меня не слишком интересуют решения для создания службы SOAP или REST в Python для Служб Google, поскольку простой поиск в Google должен предоставить множество решений. Меня больше интересует опыт и простота использования.

Но реальный вопрос заключается в следующем: при сравнении веб-службы в Службах Google с веб-службами в среде Microsoft Azure, которая обеспечит более высокую производительность? Лучший пользовательский опыт? Я не забочусь о реальных языках разработки, но мне нужно хорошее сравнение плюсов и минусов веб-сервисов как в Google App Engine, так и в Microsoft Azure.

Почему-то Azure лучше подходит для сервисов, а Google - для сайтов. Трудный выбор ...
Было бы очень интересно посмотреть, можно ли объединить оба в одно решение. : -)
Кстати, выбор используемого движка также означает выбор подходящей среды разработки и языка программирования. Хотя я хорошо знаком с .NET, Python и многими другими языками, выбор сервисного движка определяет мою направленность на будущие проекты.

1 Ответ

2 голосов
/ 08 мая 2011

При создании служб в Windows Azure они будут просто процессами, работающими на вашей виртуальной машине (Windows Server 2008 SP2 или R2 SP1). Вы можете легко размещать службы в любом из трех типов ролей:

  • Веб-роль (по сути, Windows Server с запущенным IIS) - просто добавьте конечную точку WCF в IIS или сам хост в своем собственном процессе).
  • Рабочая роль (Windows Server с IIS не запущен) - самостоятельное размещение из собственного процесса
  • Роль виртуальной машины (ваша собственная виртуальная машина Windows 2008 Server отправлена ​​в Windows Azure) - хост с любым механизмом, который вы устанавливаете / настраиваете.

Каждая виртуальная машина в Windows Azure может предоставлять в общей сложности 5 конечных точек. Это может быть комбинация входа (внешняя сторона) и внутренней конечной точки, каждый порт поддерживает tcp, http или https. Вы определяете конечные точки в свойствах своей роли vm.

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

Если вы хотите, чтобы приложение, работающее в Google, получало доступ к вашей службе Windows Azure, просто подключитесь к конечной точке через порт ip +. Одна вещь, о которой вы хотите знать, это использование полосы пропускания. Поскольку ваше приложение, размещенное в Google, будет находиться в одном центре обработки данных, а служба Windows Azure - в другом, вы будете платить за вход / выход за данные, поступающие в службу Windows Azure и выходящие из нее (и я предполагаю, что за использование соответствующей пропускной способности сторона Google, но я не уверен).

На самом деле довольно просто настроить службу. Для примеров на основе .NET посмотрите лабораторные занятия в Windows Azure Platform Training Kit (это также другие хорошие примеры, такие как настройка вашего первого приложения Windows Azure). Для хоста службы Python вам нужно будет выполнить python.exe из обработчика событий OnStart () вашей роли виртуальной машины, передав имя вашего скрипта (и, необязательно, номер порта для прослушивания). Простой пример запуска python.exe смотрите в блоге Стива Маркса здесь .

РЕДАКТИРОВАТЬ: Если вы хотите разместить несколько служб (например, несколько портов), вы можете разместить их в одной роли виртуальной машины или в разных ролях, чтобы оптимизировать расходы (с известным пределом в 5 конечных точек) или производительность (масштабируйте каждую услугу отдельно).

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...