Follow Me Widget

четверг, 20 января 2011 г.

Разработка приложений под Windows Azure. Жизненный цикл разработки.Часть №1 - Проектирование и разработка.

Сегодня я начинаю серию статей, в которых постараюсь рассказать об особенностях разработки приложений под прогрессивную платформу Windows Azure.
Проектирование.
И начинать следует первым делом с проектирования. На стадии проектирования необходимо в целом понять необходимо ли вам облачное приложение или все таки можно обойтись стандартными средствами. Можно разводить длительную дискуссию по поводу преимуществ и недостатков размещения приложений в облаке. Мое субъективное мнение следующее: если Вы собираетесь разрабатывать приложение которое будет работать на единственном сервере и разворачиваться простейшим образом, возможно облако это не для Вас. Если же Вам требуются следующие характеристики как:
  1. Надежность
  2. Масштабируемость
  3. Доступность
, то лучшего решения чем облако Вам не найти Улыбка.  
Итак, мы решили писать приложение для облака. Сразу же сталкиваемся со следующими проблемами:
  1. Во-первых Вы разрабатываете высокомасштабируемое облачное приложение, а это накладывает в свою очередь определенные ограничения и особенности на сам процесс.
  2. Во-вторых следует учитывать саму модель разработки Windows Azure, которая предполагает проектирование и выбор ролей (а выбрать Вы можете либо Web-роль, либо Worker-роль, либо VM-роль).
  3. В конце концов следует продумать механизм коммуникации между ролями, благо, Windows Azure предлагает Вам просто потрясающие возможности (Windows Azure Queues, например)
Не стоит забывать, что Azure это просто потрясающе гибкая платформа. Вам не обязательно выносить все приложение в облако. С помощью таких прекрасных технологий как Windows Azure AppFabric и Windows Azure Connect можно объединять облачное приложение с приложением на ваших собственных серверах и работать это будет как одно единое целое (к примеру, можно вынести хранилище данных на ваш собственный сервер, тогда как вычислительную часть поместить в облако).
Все же основное в проектировании облачного приложения – это масштабируемость. Мне видится, что основная цель проекта 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 Storage And Dev Fabric
Я не буду сильно углубляться в особенности использования Dev Fabric и Dev Storage, так как думаю большинство из вас знакомы с этим.
На последнем PDC был значительно расширен Server Explorer, были добавлены возможности мониторинга состояния вашего приложения в облаке а также удобный вьювер вашего Windows  Azure Storage. 

Server Explorer

Итак, мы написали, протестировали наше приложение. Пришло время задеплоить его в облако. Первый вариант это создать пакет и вручную его загрузить на dev-портале.

Creating New Hosted Service
Здесь мы указываем формальные параметры такие как  название сервиса, метку деплоймента. А также сам пакет, конфигурационный файл, url по которому будет осуществляться доступ к приложению, географическое размещение вашего сервиса и слот куда Вы загружаете пакет (либо сразу же продакшен либо на тестовый слот). В целом я бы рекомендовал следующий подход к разработке и разворачиванию ваших приложений:

Stages Of Service Deployment

Если следовать этой последовательности, то первым делом мы разрабатываем и тестируем приложение на локальных эмуляторах: Development Fabric и Development Storage. Как только мы видим, что приложение работает безошибочно пытаемся исключить из процесса Development Storage. а работаем напрямую с облачной версией Windows Azure Storage. Если на этой стадии не наблюдается неправильной работы системы, переводим полностью проект в облако, сначала разворачивая на тестовом слоте (Staging Slot). На этой стадии проводится окончательная проверка приложения перед его переводом в стадию продакшена – фактически загрузкой системы на продакшен слот.
Итак, после успешной загрузки пакета мы терпеливо ждем 12-15 минут и получаем работающее облачное приложение на выходе:

Hosted Service on Development Portal

















Это первый вариант разворачивания приложений и как по мне сильно устаревший в плане наличия более совершенного и прогрессивного способа. Я имею ввиду автоматический билд проекта в пакет и автоматическая заливка этого пакета прямо из студии. Все это выполняется благодаря Windows Azure Service Management API. Для начала нам необходим сертификат. Извините, ошибся 2 сертификата. Начнем с первого, который необходимо добавить на dev-портале в раздел Management Certificates.

Certificate Management

Как видите у меня уже установлен сертификат в этом разделе. Создал я его на своей локальной машине с помощью стандартных средств IIS. Дальше больше, нам необходим 2-й сертификат, который устанавливается для каждого конкретного сервиса в Azure. Для этого я зашел в меню Publish своего проекта и добавил новые криденшиалы посредством удобного визарда.
Automatic Cloud Publishing

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

Certificate Exporting

И заливать этот pfx-файл на dev-портал.

Certificate Importing on Development Portal

На этом процесс установки доверенных отношений между Visual Studio и Windows Azure закончен. В итоге настройки получаем данное окошко, свидетельствующее о успешной операции.

Publish Cloud Service

Нажимаем Ок если нас устраивает целевой слот и метка деплоймента и видим как студия билдит и деплоит все за нас. 

Windows Azure Activity Log

За процессом разворачивания можем следить как из Windows Azure Activity Log, так и из Server Explorer, ну и собственно с самого dev-портала. 
На этом я хотел бы завершить этот пост, посвященный проектированию, разработке и разворачиванию приложений под платформу Windows Azure. В последующих постах постараюсь рассказать о особенностях работы с Windows Azure Storage, Windows Azure AppFabric а также других не менее интересных облачных технологиях. Спасибо за внимание ! Улыбка

Комментариев нет: