Сегодня я начинаю серию статей, в которых постараюсь рассказать об особенностях разработки приложений под прогрессивную платформу Windows Azure.
Проектирование.
И начинать следует первым делом с проектирования. На стадии проектирования необходимо в целом понять необходимо ли вам облачное приложение или все таки можно обойтись стандартными средствами. Можно разводить длительную дискуссию по поводу преимуществ и недостатков размещения приложений в облаке. Мое субъективное мнение следующее: если Вы собираетесь разрабатывать приложение которое будет работать на единственном сервере и разворачиваться простейшим образом, возможно облако это не для Вас. Если же Вам требуются следующие характеристики как:
.
Итак, мы решили писать приложение для облака. Сразу же сталкиваемся со следующими проблемами:
Все же основное в проектировании облачного приложения – это масштабируемость. Мне видится, что основная цель проекта Azure – это возможность невероятного масштабирования вашего приложения, поэтому Вы, как разработчик, должны думать в контексте этого преимущества и разрабатывать приложение с учетом того, что возможно оно будет работать на множестве физических машин.
Ну и еще одна особенность – это разработка с учетом стоимости. Вот этот аспект совершенно новый для большинства современных программистов, никогда раньше мы не задумывались над тем, что от особенностей проектирования может зависеть стоимость поддержки и сопровождения. В контексте Windows Azure это становится мега актуальным.
Разработка.
Первое, что следует отметить в разработке – это то, что в процессе девелопмента вы используете тот же инструментарий, вы используете свой опыт в разработке и отладке приложений. Фактически для разработки Вам необходимо установить Windows Azure SDK и Windows Azure Visual Studio Tools, после чего у вас появляется новый темплейт в VS2010. Кстати, обещают в ближайшем будущем интегрировать темплейты Windows Azure и Visual Studio без необходимости их дополнительной установки. Также на последнем PDC была анонсирована поддержка IntelliTrace в облаке, это значит, что вы можете собирать отладочную информацию прямо из облака.
Итак, создаем проект, нажимаем F5 и видим, как наше приложение компилируется, с помощью утилиты CSPack формируется пакет, загружаемый в локальную среду – эмуляцию облака, так называемую Development Fabric. Параллельно у нас запускается локальная эмуляция Windows Azure Storage под названием Development Storage.
Я не буду сильно углубляться в особенности использования Dev Fabric и Dev Storage, так как думаю большинство из вас знакомы с этим.
На последнем PDC был значительно расширен Server Explorer, были добавлены возможности мониторинга состояния вашего приложения в облаке а также удобный вьювер вашего Windows Azure Storage.
Итак, мы написали, протестировали наше приложение. Пришло время задеплоить его в облако. Первый вариант это создать пакет и вручную его загрузить на dev-портале.
Здесь мы указываем формальные параметры такие как название сервиса, метку деплоймента. А также сам пакет, конфигурационный файл, url по которому будет осуществляться доступ к приложению, географическое размещение вашего сервиса и слот куда Вы загружаете пакет (либо сразу же продакшен либо на тестовый слот). В целом я бы рекомендовал следующий подход к разработке и разворачиванию ваших приложений:
Если следовать этой последовательности, то первым делом мы разрабатываем и тестируем приложение на локальных эмуляторах: Development Fabric и Development Storage. Как только мы видим, что приложение работает безошибочно пытаемся исключить из процесса Development Storage. а работаем напрямую с облачной версией Windows Azure Storage. Если на этой стадии не наблюдается неправильной работы системы, переводим полностью проект в облако, сначала разворачивая на тестовом слоте (Staging Slot). На этой стадии проводится окончательная проверка приложения перед его переводом в стадию продакшена – фактически загрузкой системы на продакшен слот.
Итак, после успешной загрузки пакета мы терпеливо ждем 12-15 минут и получаем работающее облачное приложение на выходе:
Это первый вариант разворачивания приложений и как по мне сильно устаревший в плане наличия более совершенного и прогрессивного способа. Я имею ввиду автоматический билд проекта в пакет и автоматическая заливка этого пакета прямо из студии. Все это выполняется благодаря Windows Azure Service Management API. Для начала нам необходим сертификат. Извините, ошибся 2 сертификата. Начнем с первого, который необходимо добавить на dev-портале в раздел Management Certificates.
Как видите у меня уже установлен сертификат в этом разделе. Создал я его на своей локальной машине с помощью стандартных средств IIS. Дальше больше, нам необходим 2-й сертификат, который устанавливается для каждого конкретного сервиса в Azure. Для этого я зашел в меню Publish своего проекта и добавил новые криденшиалы посредством удобного визарда.
В процессе добавления новых криденшиалов Вы можете сгенерировать сертификат, устанавливаемый в хранилище сертификатов локального пользователя. Именно из этого хранилища мы на следующем шаге будем экспортировать только что созданный сертификат в виде pfx-файла.
И заливать этот pfx-файл на dev-портал.
На этом процесс установки доверенных отношений между Visual Studio и Windows Azure закончен. В итоге настройки получаем данное окошко, свидетельствующее о успешной операции.
Нажимаем Ок если нас устраивает целевой слот и метка деплоймента и видим как студия билдит и деплоит все за нас.
За процессом разворачивания можем следить как из Windows Azure Activity Log, так и из Server Explorer, ну и собственно с самого dev-портала.
На этом я хотел бы завершить этот пост, посвященный проектированию, разработке и разворачиванию приложений под платформу Windows Azure. В последующих постах постараюсь рассказать о особенностях работы с Windows Azure Storage, Windows Azure AppFabric а также других не менее интересных облачных технологиях. Спасибо за внимание !
Проектирование.
И начинать следует первым делом с проектирования. На стадии проектирования необходимо в целом понять необходимо ли вам облачное приложение или все таки можно обойтись стандартными средствами. Можно разводить длительную дискуссию по поводу преимуществ и недостатков размещения приложений в облаке. Мое субъективное мнение следующее: если Вы собираетесь разрабатывать приложение которое будет работать на единственном сервере и разворачиваться простейшим образом, возможно облако это не для Вас. Если же Вам требуются следующие характеристики как:
- Надежность
- Масштабируемость
- Доступность
. Итак, мы решили писать приложение для облака. Сразу же сталкиваемся со следующими проблемами:
- Во-первых Вы разрабатываете высокомасштабируемое облачное приложение, а это накладывает в свою очередь определенные ограничения и особенности на сам процесс.
- Во-вторых следует учитывать саму модель разработки Windows Azure, которая предполагает проектирование и выбор ролей (а выбрать Вы можете либо Web-роль, либо Worker-роль, либо VM-роль).
- В конце концов следует продумать механизм коммуникации между ролями, благо, Windows Azure предлагает Вам просто потрясающие возможности (Windows Azure Queues, например)
Все же основное в проектировании облачного приложения – это масштабируемость. Мне видится, что основная цель проекта Azure – это возможность невероятного масштабирования вашего приложения, поэтому Вы, как разработчик, должны думать в контексте этого преимущества и разрабатывать приложение с учетом того, что возможно оно будет работать на множестве физических машин.
Ну и еще одна особенность – это разработка с учетом стоимости. Вот этот аспект совершенно новый для большинства современных программистов, никогда раньше мы не задумывались над тем, что от особенностей проектирования может зависеть стоимость поддержки и сопровождения. В контексте Windows Azure это становится мега актуальным.
Разработка.
Первое, что следует отметить в разработке – это то, что в процессе девелопмента вы используете тот же инструментарий, вы используете свой опыт в разработке и отладке приложений. Фактически для разработки Вам необходимо установить Windows Azure SDK и Windows Azure Visual Studio Tools, после чего у вас появляется новый темплейт в VS2010. Кстати, обещают в ближайшем будущем интегрировать темплейты Windows Azure и Visual Studio без необходимости их дополнительной установки. Также на последнем PDC была анонсирована поддержка IntelliTrace в облаке, это значит, что вы можете собирать отладочную информацию прямо из облака.
Итак, создаем проект, нажимаем F5 и видим, как наше приложение компилируется, с помощью утилиты CSPack формируется пакет, загружаемый в локальную среду – эмуляцию облака, так называемую Development Fabric. Параллельно у нас запускается локальная эмуляция Windows Azure Storage под названием Development Storage.
На последнем PDC был значительно расширен Server Explorer, были добавлены возможности мониторинга состояния вашего приложения в облаке а также удобный вьювер вашего Windows Azure Storage.
Итак, мы написали, протестировали наше приложение. Пришло время задеплоить его в облако. Первый вариант это создать пакет и вручную его загрузить на dev-портале.
Здесь мы указываем формальные параметры такие как название сервиса, метку деплоймента. А также сам пакет, конфигурационный файл, url по которому будет осуществляться доступ к приложению, географическое размещение вашего сервиса и слот куда Вы загружаете пакет (либо сразу же продакшен либо на тестовый слот). В целом я бы рекомендовал следующий подход к разработке и разворачиванию ваших приложений:
Если следовать этой последовательности, то первым делом мы разрабатываем и тестируем приложение на локальных эмуляторах: Development Fabric и Development Storage. Как только мы видим, что приложение работает безошибочно пытаемся исключить из процесса Development Storage. а работаем напрямую с облачной версией Windows Azure Storage. Если на этой стадии не наблюдается неправильной работы системы, переводим полностью проект в облако, сначала разворачивая на тестовом слоте (Staging Slot). На этой стадии проводится окончательная проверка приложения перед его переводом в стадию продакшена – фактически загрузкой системы на продакшен слот.
Итак, после успешной загрузки пакета мы терпеливо ждем 12-15 минут и получаем работающее облачное приложение на выходе:
Это первый вариант разворачивания приложений и как по мне сильно устаревший в плане наличия более совершенного и прогрессивного способа. Я имею ввиду автоматический билд проекта в пакет и автоматическая заливка этого пакета прямо из студии. Все это выполняется благодаря Windows Azure Service Management API. Для начала нам необходим сертификат. Извините, ошибся 2 сертификата. Начнем с первого, который необходимо добавить на dev-портале в раздел Management Certificates.
Как видите у меня уже установлен сертификат в этом разделе. Создал я его на своей локальной машине с помощью стандартных средств IIS. Дальше больше, нам необходим 2-й сертификат, который устанавливается для каждого конкретного сервиса в Azure. Для этого я зашел в меню Publish своего проекта и добавил новые криденшиалы посредством удобного визарда.
В процессе добавления новых криденшиалов Вы можете сгенерировать сертификат, устанавливаемый в хранилище сертификатов локального пользователя. Именно из этого хранилища мы на следующем шаге будем экспортировать только что созданный сертификат в виде pfx-файла.
И заливать этот pfx-файл на dev-портал.
На этом процесс установки доверенных отношений между Visual Studio и Windows Azure закончен. В итоге настройки получаем данное окошко, свидетельствующее о успешной операции.
Нажимаем Ок если нас устраивает целевой слот и метка деплоймента и видим как студия билдит и деплоит все за нас.
За процессом разворачивания можем следить как из Windows Azure Activity Log, так и из Server Explorer, ну и собственно с самого dev-портала.
На этом я хотел бы завершить этот пост, посвященный проектированию, разработке и разворачиванию приложений под платформу Windows Azure. В последующих постах постараюсь рассказать о особенностях работы с Windows Azure Storage, Windows Azure AppFabric а также других не менее интересных облачных технологиях. Спасибо за внимание !
Комментариев нет:
Отправить комментарий