После того, как команда Windows Azure AppFabric объявила о доступности приложений Windows Azure AppFabric (предварительная версия ), я сразу же подписался на ранний доступ и получил доступ . После установки инструментов и создания пространства имен через портал я решил попробовать его посмотреть. о чем это все Обратите внимание, что у Нила Маккензи также есть обширная статья о «WAAFapps», которую я рекомендую вам прочитать.
Так что же это за приложение Windows Azure AppFabric?
Прежде чем ответить на этот вопрос, давайте кратко рассмотрим, что представляет собой Windows Azure сегодня. Согласно Microsoft, Windows Azure является предложением «PaaS» (Платформа как услуга). Это означает, что Windows Azure предлагает вашему приложению ряд компонентов платформы, таких как вычисления, хранение, кэширование, аутентификация, служебная шина, база данных, CDN,….
Однако использование этих компонентов является довольно низким уровнем: чтобы использовать, скажем, кеширование, нужно добавить необходимые ссылки, внести некоторые изменения в web.config и открыть соединение с этими вещами. Хорошо, API предоставляется, но это не тот случай, когда вы можете легко интегрировать кэширование в приложение за считанные секунды (так, как если бы вы интегрировали доступ к файловой системе в приложение, которое вы буквально можете сделать за секунды).
Познакомьтесь с приложениями Windows Azure AppFabric. Приложения Windows Azure AppFabric (почему такие длинные имена, Microsoft!) Переопределяют концепцию «Платформа как услуга»: где Windows Azure «из коробки» больше напоминает «Платформа API как услуга», Windows Azure AppFabric Приложения предлагают инструменты и поддержку платформы для простой интеграции различных компонентов Windows Azure.
Это «переопределение» Windows Azure вводит некоторые новые концепции: в Windows Azure у вас есть роли и экземпляры ролей. В приложениях AppFabric у вас нет такой концепции: AFA (да, мне удалось его сократить!) Использует так называемые контейнеры. Контейнер — это логическая единица, в которой размещены одна или несколько служб приложения. Например, если у вас есть 2 веб-приложения, кэширование и SQL Azure, у вас (по умолчанию) будет один контейнер, содержащий 2 веб-приложения + 2 ссылки на службы: одно для кэширования, одно для SQL Azure.
Контейнеры не ограничены одной ролью или экземпляром роли: контейнер — это набор предварительно развернутых экземпляров роли, на которых будут работать ваши приложения. Например, если вы добавите службу WCF, есть вероятность, что она будет частью того же контейнера. Или другой, если вы укажете иначе.
Довольно интересно, что вы можете масштабировать контейнеры отдельно. Например, можно иметь 2 единицы масштаба для контейнера, содержащего веб-приложения, 3 для контейнера WCF… Единица масштаба не обязательно является просто одним дополнительным экземпляром: это зависит от того, сколько служб находится в контейнере? На самом деле, вам больше не нужно заботиться об экземплярах ролей и виртуальных машинах: с AFA (помните мое сокращение от Windows Azure AppFabric Applications) можно по-настоящему заботиться только об одном: о приложении, которое вы создаете.
Здравствуйте, приложения Windows Azure AppFabric
Поддержка инструментов Visual Studio
Чтобы продемонстрировать несколько концепций, я решил создать простое веб-приложение, которое использует кэширование для хранения количества посещений веб-сайта. После установки инструментария Visual Studio я начал с одного из шаблонов, содержащихся в SDK:
Этот шаблон создает несколько вещей. Для начала в Visual Studio создано 2 проекта: одно приложение MVC, в котором я создам свое веб-приложение, и одно приложение Windows Azure AppFabric, содержащее файл App.cs, который выглядит как DSL для создания приложения Windows Azure AppFabric. Открытие этого DSL дает следующий холст в Visual Studio:
Как видите, это обзор моего приложения, а также того, как они взаимодействуют друг с другом. Например, «MVCWebApp» имеет 1 конечную точку (для обслуживания HTTP-запросов) + 2 ссылки на службы (для кэширования Windows Azure AppFabric и SQL Azure). Это важное понятие, поскольку оно будет генерировать код интеграции для вас. Например, в моем веб-приложении MVC я могу найти файл ServiceReferences.g.cs, содержащий следующий код:
1 class ServiceReferences
2 {
3 public static Microsoft.ApplicationServer.Caching.DataCache CreateImport1()
4 {
5 return Service.ExecutingService.ResolveImport<Microsoft.ApplicationServer.Caching.DataCache>("Import1");
6 }
7
8 public static System.Data.SqlClient.SqlConnection CreateImport2()
9 {
10 return Service.ExecutingService.ResolveImport<System.Data.SqlClient.SqlConnection>("Import2");
11 }
12 }
Подождите минутку … Это выглядит круто! Это в основном фабрика для компонентов, которые могут быть размещены в другом месте! Вызов ServiceReferences.CreateImport1 () даст мне кеширующий клиент, с которым я могу немедленно работать! ServiceReferences.CreateImport2 () (кстати, вы можете изменить эти имена) дает мне соединение с SQL Azure. Нет необходимости добавлять строки подключения в само приложение, не нужно настраивать кэширование в самом приложении. Вместо этого я могу настроить эти вещи на холсте приложения Windows Azure AppFabric и просто слепо использовать их в своем коде. Потрясающие!
Вот код для моего HomeController, где я использую кеш /. Даже моя бабушка может написать это!
[HandleError]
2 public class HomeController : Controller
3 {
4 public ActionResult Index()
5 {
6 var count = 1;
7 var cache = ServiceReferences.CreateImport1();
8 var countItem = cache.GetCacheItem("visits");
9 if (countItem != null)
10 {
11 count = ((int)countItem.Value) + 1;
12 }
13 cache.Put("visits", count);
14
15 ViewData["Message"] = string.Format("You are visitor number {0}.", count);
16
17 return View();
18 }
19
20 public ActionResult About()
21 {
22 return View();
23 }
24 }
Теперь вернемся к основному приложению Windows Azure AppFabric, где я могу перейти к «представлению развертывания»:
Представление развертывания в основном позволяет вам решить, в каком контейнере будет запущено одно или несколько приложений и сколько единиц масштаба должен охватывать контейнер (см. Окно свойств в Visual Studio для этого).
Щелкните правой кнопкой мыши и выберите «Развернуть…», чтобы развернуть приложение Windows Azure AppFabric в производственную среду.
Портал управления
После входа на сайт http://portal.appfabriclabs.com я могу управлять только что опубликованным приложением:
Я не буду вдаваться в подробности, но остановлюсь на некоторых особенностях. Портал позволяет вам управлять своим приложением: развертывать / отменять развертывание, масштабировать, отслеживать, изменять конфигурацию,… В основном все, что вы ожидаете сделать. И более! Например, если вы посмотрите на часть мониторинга, вы увидите некоторые KPI в вашем приложении. Вот что показывает мой пример приложения после развертывания в течение нескольких минут:
Довольно гладко. Он даже контролирует средние задержки и т. Д.!
Вывод
Как вы можете прочитать в этом блоге, я изучал этот продукт и опробовал его основы. Я еще не уверен, подойдет ли эта модель для каждого приложения, но я уверен, что именно такое решение и должно быть в будущем PaaS: больше не нужно заботиться о серверах, виртуальных машинах или экземплярах, просто разверните и дайте платформе понять все вне. Моя бизнес-ценность — это мое приложение, а не тот факт, что оно охватывает 2 виртуальные машины.
Теперь, когда я говорю «будущее PaaS», я также немного скептически отношусь… Большинство клиентов, с которыми я работаю, используют COM, требуют сценарии запуска для настройки среды, заботятся о сервере, на котором работает их приложение. Фактически из-за этого некоторые приложения никогда не смогут быть развернуты в этом решении. В то время как Windows Azure уже представляет собой серьезный сдвиг в терминах парадигмы разработки (слишком большой шаг для многих!), Я считаю, что шаг к приложениям Windows Azure AppFabric для большинства людей является мостом слишком далеко. В настоящий момент.
Но есть и корпорации … Поскольку корпорации всегда на 10 шагов позади, я предвижу, что это станет основной тенденцией только в течение следующих 5-8 лет (для предприятия). Печалька! Я бы хотел, чтобы большинство корпоративных сред двигались быстрее …
Если Microsoft хочет, чтобы эта вещь была успешной, я думаю, что им нужно больше работать над тем, чтобы переключить умы на облачную парадигму и более специфичную для парадигмы PaaS. Возможно, Windows 8 может быть полезной для этого: если Windows 8 перейдет от «программирования для среды Windows» к «программированию для среды PaaS», люди начнут следовать этому направлению. Какого черта, может быть, это даже отличная модель для Joe Average для создания «приложений» для Windows 8! Точно так же, как сегодня пользователь отправляет приложение в AppStore или Marketplace, он / она может отправить приложение в «Windows Marketplace», которое в фоновом режиме просто отбрасывает все на технологии, такие как приложения Windows Azure AppFabric?