Небольшая компания-разработчик, думающая об использовании Azure

Question

Я небольшая компания по разработке программного обеспечения (я и еще одна), и в настоящее время мы платим около 50 фунтов стерлингов в месяц (75 долларов) за наш хостинг. У нас есть 2 VPS-машины для 12 наших веб-сайтов.

Теперь я смотрю на Azure, чтобы посмотреть, будет ли он соответствовать нашим требованиям. У меня есть несколько вопросов, с которыми, я надеюсь, люди могут помочь мне:

1. Сайты, которыми мы располагаем, не используются интенсивно (максимум 100 посетителей в день), однако в настоящее время их 12. С Azure вы платите только тогда, когда используется веб-сайт или когда компьютер включен? Это должно быть 24/7, как у нашего текущего хоста
2. Хотели бы мы создать одну машину для развертывания и разместить там все 12 веб-сайтов? Если нам нужно 12 различных служб, может ли это очень быстро стать дорогим?
3. Что мы будем делать с отправкой / получением электронной почты и запланированными заданиями? Доступен сеанс удаленного рабочего стола, так что, возможно, я мог бы установить Smarter Mail и наши приложения для запланированных задач здесь?

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

Answer 1

1. Вы платите за веб-роль за каждый час ее работы, даже если трафик не попадает в веб-роль.В дополнение к стоимости веб-роли в час вы платите за хранилище таблиц / больших двоичных объектов / очередей (если используется), исходящую пропускную способность (на каждый ГБ используется, входящий бесплатный), SQL Azure (если используется) и другие различные Azure.услуги, на которые вы можете подписаться.См. калькулятор цен Microsoft .

2. . Если вы хотите запустить все 12 сайтов в одной веб-роли, ознакомьтесь с Windows Azure Accelerator для веб-ролей .Он имеет множество полезных функций, которые помогут вам сделать это.

   Однако имейте в виду, что если у вас есть только одна веб-роль, выполняющая эти сайты, у вас будет простои, и это может быть в серединедень.Microsoft постоянно проводит техническое обслуживание, снимает роли, разрушает их, перестраивает их и восстанавливает их для выполнения обновлений, миграций и т. Д., И ваша роль может быть приостановлена ​​на время обслуживания, и вы не можете контролировать этоprocess.

   Чтобы смягчить эту проблему, Microsoft рекомендует иметь как минимум 2 веб-роли.В вашей ситуации каждая из 2 ролей может выполнять все 12 сайтов.Однако, чтобы это работало хорошо, все сайты должны быть построены так, чтобы не было привязки к какому-либо конкретному серверу.То есть, если пользователь входит в систему и нажимает на Сервер A и сервер A помещает что-то о пользователе в кэш, то следующий запрос пользователя отправляется на Сервер B, Сервер B не будет иметь бит данных в своем кеше, и поэтомуВторой запрос может быть неудачным.Вы хотите этого избежать - убедитесь, что ваши сайты написаны так, чтобы они работали должным образом за балансировщиком нагрузки.

3. Yikes, я был бы здесь осторожен.Я настоятельно рекомендую не входить в систему через RDP и устанавливать приложение в веб-роли.Если вы сделаете это, в следующий раз, когда роль будет переработана и перестроена (что произойдет при регулярном обслуживании Microsoft), любые пользовательские установки, которые вы сделали, как это, будут стерты.

   Это две части.Первый - это установить какое-то программное обеспечение для работы с электронной почтой.Вы можете установить почтовое программное обеспечение через командную строку во время инициализации роли в задаче запуска.См. здесь и здесь .Это приведет к переустановке программного обеспечения при каждой перестройке вашей веб-роли Microsoft.Кроме того, вы можете подключаться к сторонним службам электронной почты через API, например MailChimp , и не беспокоиться о том, что обрабатываете электронную почту самостоятельно.Помните, что если вы отправляете электронные письма самостоятельно, у вас могут возникнуть проблемы с SPF, поскольку ваш IP-адрес в Azure может время от времени меняться.

   Вторая часть вопроса 3 связана с запланированными задачами.Существует несколько подходов:

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

     a.Ваше веб-приложение решает, что электронное письмо необходимо отправить.Он сохраняет данные, связанные с электронной почтой, в таблице Azure и создает идентификатор для электронной почты.

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

     c.Ваше веб-приложение забывает об электронной почте и дает ответ пользователю

     d.Рабочая роль (потенциально выполняемая в том же окне, что и веб-роль) выбирает сообщение из очереди, видит, что необходимо отправить сообщение электронной почты, получает данные из таблицы Azure и отправляет сообщение электронной почты.

     е.Затем рабочая роль очищает данные из очереди и таблицы

   • Вы можете использовать запланированные задания. В конце концов, веб-роль является полноценным сервером Windows и имеет запланированные задачи. Однако, как и при установке программного обеспечения, вы должны быть уверены, что настроит свои запланированные задачи с помощью задачи запуска , чтобы они выполнялись даже после повторного использования роли. *

В целом, вы должны думать немного иначе, работая с веб-ролями Azure. Microsoft заставляет вас идти по пути, который делает ваше приложение более масштабируемым и надежным. Удаляя веб-роль и перестраивая ее во время обслуживания, они вынуждают вас автоматизировать установку программного обеспечения / приложений на веб-роль в сценарии. Это обеспечивает лучшую масштабируемость, поскольку все, что вам нужно сделать, когда вам нужно еще 100 экземпляров ваших веб-ролей, это изменить настройку и ждать. Это обеспечивает большую надежность, поскольку означает, что ваши веб-роли каждый раз настраиваются одинаково.

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

Answer 2

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