Экспорт (0) Печать
Развернуть все
Развернуть Свернуть

Проверка применимости приложения для Azure

Обновлено: Апрель 2014 г.

Автор: Джейсон Рот (Jason Roth)
Рецензенты: Полетт Маккей (Paulette McKay), Ральф Скуиллас (Ralph Squillace), Сидни Хига (Sidney Higa), Брайан Свон (Brian Swan), Ларри Фрэнкс (Larry Franks)

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

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

Чтобы определить, подходит ли приложение для Microsoft Azure, необходимо вначале ознакомиться с основными преимуществами этой платформы. Полный список преимуществ можно найти в документации Azure, а также во многих статьях и видеоматериалах о Microsoft Azure. Одна из превосходных статей на тему преимуществ облака — Оптимизация в облаке. Расширение возможностей при согласовании вычислительных потребностей и потребностей организации.

Также важно понимать три основных варианта выполнения приложений на Microsoft Azure: Microsoft Azure Веб-сайты Microsoft Azure, облачные службы Microsoft Azure и виртуальные машины. Веб-сайты и облачные службы являются предложениями "платформа как услуга" (PaaS). Это означает, что Microsoft Azure предоставляет все образы оборудования и операционной системы. Вам необходимо обеспечить код приложения, который выполняется на платформе. Виртуальные машины представляют собой предложение "инфраструктура как услуга" (IaaS). Это означает, что вы управляете образами компьютера, которые выполняются в центрах обработки данных Microsoft Azure. Эти три варианта предоставляют разные преимущества, и ваш выбор будет зависеть от ряда факторов. При этом, учитывая эти варианты и возможности, практически все приложения подходят для Microsoft Azure.

Существует несколько основных преимуществ запуска приложений в облаке. Кратко рассмотрим некоторые из этих преимуществ перед обсуждением сценариев, в которых используются эти функции.

После развертывания приложения и служб в облаке Microsoft Azure предоставляет необходимые виртуальные машины, пропускную способность сети и другие ресурсы инфраструктуры. Если компьютеры останавливаются для обновления оборудования или из-за непредвиденных сбоев, Microsoft Azure автоматически выделяет новые виртуальные машины для приложения.

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

Под динамическим масштабированием подразумевается возможность увеличивать и уменьшать масштаб приложения в зависимости от потребности в ресурсах. Применяется также термин гибкое масштабирование. Перед описанием его работы рассмотрим типичную архитектуру приложения Microsoft Azure, которое использует облачные службы. С облачными службами вы создаете роли, совместно применяемые для реализации логики приложения. Например, в одной веб-роли может размещаться клиентский интерфейс приложения ASP.NET. Одна или несколько рабочих ролей могут выполнять необходимые фоновые задачи. Каждая роль размещается на одной или нескольких виртуальных машинах, называемых экземплярами роли, в центре обработки данных Microsoft Azure. Между этими экземплярами балансируется нагрузка от запросов. Дополнительные сведения о ролях см. в статье Модель программирования Azure.

В этом случае при возрастании потребности в ресурсах для снижения нагрузки могут быть подготовлены к работе новые экземпляры роли. После уменьшения потребности эти экземпляры можно удалить, чтобы не приходилось платить за ненужную вычислительную мощность. Существуют также варианты для автоматического масштабирования в зависимости от предопределенных правил и политик. Это во многом сильно отличается от локального развертывания, при котором приходится иметь "лишнее" оборудование для обработки пиковых нагрузок. Если вы хотите получить больше возможностей управления автоматическим масштабированием, чем предоставляет платформа, можно использовать блок автомасштабирования для приложений, разработанный группой шаблонов и методов Майкрософт.

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

В Microsoft Azure предоставлена платформа для приложений с высоким уровнем доступности, которая позволяет надежно хранить и обеспечивать доступ к серверным данным через службы хранилища или базу База данных SQL Microsoft Azure.

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

Во-вторых, Microsoft Azure гарантирует высокий уровень доступности и устойчивости для данных, сохраненных с помощью одной из служб хранилища. Службы хранилища Microsoft Azure обеспечивают репликацию всех данных по крайней мере на трех разных серверах. По умолчанию данные также реплицируются в дополнительный регион Microsoft Azure. Аналогичным образом в База данных SQL Azure происходит репликация всех данных для обеспечения доступности и устойчивости.

Другие службы Microsoft Azure предоставляют аналогичные гарантии высокого уровня доступности. Дополнительные сведения см. в разделе Техническое руководство по Azure для обеспечения непрерывности работы организации.

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

TipСовет
В настоящем документе основное внимание сосредоточено на приложениях, но для использования можно выбрать и отдельные службы Microsoft Azure. Например, если использование хранилища больших двоичных объектов позволяет решить проблемы с приложением, то для остальной части приложения не требуется перенос в облако. Такие приложения называются гибридными приложениями и рассматриваются ниже в этом разделе.

Microsoft Azure хорошо подходит для размещения служб с высоким уровнем доступности. Рассмотрим интернет-магазин, развернутый в Microsoft Azure. Интернет-магазин — это источник дохода, поэтому необходимо, чтобы он постоянно работал. Чтобы достичь этого, центр обработки данных Microsoft Azure выполняет отслеживание служб и автоматическое управление экземплярами. Кроме того, интернет-магазин должен постоянно обеспечивать быстрый отклик на потребности клиента. Это выполняется с помощью способности Microsoft Azure к гибкому масштабированию. Во время пикового возрастания спроса покупателей в режим «в сети» могут переходить новые экземпляры, которые берут на себя эту нагрузку. Кроме того, интернет-магазин не должен терять заказы или допускать сбои при полной обработке размещенных заказов. Система хранения данных Microsoft Azure и База данных SQL Azure предоставляют в высшей степени доступные и надежные функции хранения данных, позволяющие сохранять подробные сведения о заказах и состоянии на протяжении всего жизненного цикла заказов. Для обеспечения наиболее высокого уровня доступности можно развернуть одно и то же приложение в нескольких регионах Microsoft Azure. Можно создать службу, которая остается доступной, даже при временном сбое всего региона Microsoft Azure. Для этого потребуется соответствующая архитектура синхронизации и процедуры для маршрутизации пользователей.

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

noteПримечание
Примечание. Чтобы избежать получения счетов за время использования вычислительных ресурсов (вычислительное время), необходимо удалить развертывание, а не просто приостановить приложение.

Схема периодически возникающей рабочей нагрузки

А теперь рассмотрим крупную компанию, которая выполняет сложный анализ данных по сбыту в конце каждого месяца. Несмотря на то что объем обработки велик, суммарное время проведения анализа не превышает двух дней. В локальном сценарии серверы, необходимые для выполнения этой работы, останутся недогруженными большую часть месяца. При использовании Microsoft Azure компания платит только за время выполнения аналитического приложения в облаке. Предположим, что архитектура приложения обеспечивает параллельную обработку. Горизонтальное масштабирование функций Microsoft Azure позволит компании создать большое количество экземпляров рабочей роли или виртуальных машин. И при их совместном использовании сложную работу можно будет выполнять быстрее. В этом примере необходимо использовать код или скриптовую поддержку для автоматического развертывания приложения в соответствующее время каждый месяц.

Задачей каждого предприятия является быстрый и устойчивый рост. Но при использовании традиционной локальной модели этот рост очень трудно обеспечить. Если ожидаемого роста так и не произойдет, то окажется, что деньги потрачены на поддержку оборудования и инфраструктуры, которые не используются в полную силу. А если рост происходит быстрее ожидаемого, то может оказаться, что предприятие не справляется с нагрузкой, поэтому теряет деловые возможности и производит плохое впечатление на клиентов. Что касается малых компаний, то они могут даже не иметь достаточного начального капитала, чтобы подготовиться к быстрому росту или справиться с ним.

Схема непредсказуемого роста

Microsoft Azure идеально подходит для использования в этой ситуации. Рассмотрим небольшой веб-сайт спортивных новостей, который зарабатывает на рекламе. Величина дохода прямо пропорциональна объему трафика, создаваемого сайтом. В этом примере начальный капитал предприятия ограничен. Кроме того, компания не имеет необходимых средств для развертывания и эксплуатации собственного центра обработки данных. Но спроектировав веб-сайт для работы на Microsoft Azure, компания может легко развернуть свое решение в качестве приложения ASP.NET. В приложении будет использоваться База данных SQL Azure для хранения реляционных данных и хранилище больших двоичных объектов — для изображений и видео. Если произойдет резкий рост популярности веб-сайта, компания может увеличить число экземпляров веб-роли для сервера переднего плана. Компания может также увеличить размер базы База данных SQL Azure. В Microsoft Azure хранилище больших двоичных объектов имеет встроенные функции масштабирования. Если объемы деловых операций уменьшатся, можно удалить ненужные экземпляры. Поскольку доход пропорционален трафику на сайте, Microsoft Azure поможет компании быстро приступить к работе, обеспечить необходимый рост и уменьшить риски.

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

Это еще один шаблон рабочей нагрузки, который требует гибкого масштабирования. Вернемся к предыдущему примеру веб-сайта спортивных новостей. Даже притом, что объем деловых операций на сайте постоянно растет, остается возможность появления временных пиков или резкого возрастания активности. Например, предположим, сайт указан в другом популярном источнике новостей. Количество его посетителей может резко возрасти за один день. Еще более вероятным является такой сценарий: увеличение активности на сайте будет вызвано проведением важных спортивных мероприятий и чемпионатов.

Схема пикового увеличения рабочей нагрузки

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

Microsoft Azure полностью обеспечивает временное увеличение масштабов приложения для обработки пиковой нагрузки и сворачивание приложения по окончании события.

Как показывают предыдущие примеры, гибкое масштабирование Microsoft Azure приносит пользу во многих самых распространенных сценариях работы в облаке. Но сокращением издержек с помощью Microsoft Azure могут воспользоваться даже приложения со стабильными шаблонами рабочей нагрузки. Эксплуатация собственного центра обработки данных обходится дорого, если учесть расходы на электроэнергию, наем рабочей силы, оборудование, лицензирование программного обеспечения и коммунальные услуги. Кроме того, трудно понять, каковы доли издержек, связанных с отдельными приложениями. С помощью Microsoft Azure можно не только добиться цели сокращения суммарных затрат, но и сделать эти затраты более прозрачными. Рекомендуем ознакомиться со статьей Оптимизация в облаке. Расширение возможностей при согласовании вычислительных потребностей и потребностей организации. Авторы статьи проделали большую работу по изучению типичных расходов на локальное размещение приложений и по определению того, как их можно сократить с помощью Microsoft Azure.

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

В Microsoft Azure предусмотрен калькулятор для определения цен, позволяющий рассчитывать конкретные издержки. Кроме того, в ней предусмотрен калькулятор совокупной стоимости владения (TCO), позволяющий оценить общее сокращение расходов, которого можно добиться, перейдя на Microsoft Azure. Ссылки на этот калькулятор и другие сведения об определении цен см. на веб-сайте Azure.

Microsoft Azure предоставляет службы и возможности, подходящие практически любому приложению. Сюда входят варианты PaaS, такие как облачные службы и веб-сайты, и IaaS с виртуальными машинами и виртуальной сетью. Однако существуют сценарии, которые гарантируют более медленную миграцию или отсутствие миграции в облако.

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

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

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

Безусловно, чтобы оценить возможность перехода на Microsoft Azure, недостаточно только определить, что конкретное приложение или определенные бизнес-цели подходят для облака. Важно также оценить архитектурные и проектные особенности существующего или нового приложения. Быстрый путь к осуществлению этого анализа состоит в использовании средства оценки Майкрософт (MAP) для Microsoft Azure. Работа с этим средством заключается в предоставлении ответов на вопросы, позволяющие определить, какие проблемы могут возникнуть при перемещении на Microsoft Azure. Рядом с каждым вопросом находится ссылка «Полное описание», с помощью которой можно получить дополнительные сведения о данной конкретной области в Microsoft Azure. Эти вопросы и дополнительные сведения помогут выявить изменения, которые, возможно, потребуется внести в проект существующего или нового приложения для облака.

Кроме использования средства MAP, необходимо хорошо понять основы работы платформы Microsoft Azure. В частности, необходимо знать основные принципы проектирования для платформы. Необходимо также рассмотреть технические плакаты для Microsoft Azure. В них содержится подробная информация о возможностях платформы, а также ссылки на дополнительные сведения. Ознакомьтесь с различными службами, доступными в Microsoft Azure, и рассмотрите, какое отношение они могут иметь к разрабатываемому решению. Обзор служб Microsoft Azure см. в разделе Что такое Azure?. При планировании архитектуры изучите статью Подписка Azure и ограничения служб, квоты и ограничения.

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

 

Область Описание

IaaS или PaaS?

"Инфраструктура как услуга" (IaaS) позволяет вам использовать собственные образы в виртуальных машинах на Microsoft Azure. Часто это самый простой способ миграции в облако, поскольку он включает меньшее количество изменений в архитектуре приложения.

Веб-сайты Microsoft Azure и облачные службы Microsoft Azure представляют собой вариант "платформа как услуга" (PaaS). Приложения, разрабатываемые для среды PaaS, часто более гибкие, масштабируемые и управляемые, чем сходные решения в IaaS. Однако миграция на облачные службы обычно занимает больше времени. Веб-сайты отлично совмещают преимущества PaaS с легкостью миграции IaaS.

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

Гибридные решения

Задача перемещения сложных приложений предыдущих версий в Microsoft Azure может оказаться сложной. Кроме того, иногда приходится учитывать законодательные требования, касающиеся хранения данных определенных типов в облаке. Некоторые ответы на вопросы по обеспечению безопасности и соответствию нормативным требованиям находятся в центре управления безопасностью Azure.

Одно из решений для выполнения этих задач — создать гибридное приложение, которое соединяет службы, размещенные в Microsoft Azure, с локальными приложениями и данными. Такая возможность поддерживается многими технологиями Microsoft Azure, включая служебную шину и виртуальную сеть. Дополнительные сведения см. в разделе Создание гибридных приложений в облаке на Azure.

Управление состоянием

Если вы перемещаете существующее приложение на виртуальные машины Microsoft Azure, обычно обработка данных состояния не отличается от локальной. Однако, если вы хотите использовать возможности архитектуры PaaS облачных служб Microsoft Azure, необходимо оценить, как обрабатывать состояние. Во многих локальных приложениях предусмотрено хранение информации о состоянии на локальном жестком диске. Что касается других функций, таких как предусмотренное по умолчанию состояние сеанса ASP.NET, то для управления состоянием используется память локального компьютера. Хотя роли облачных служб и имеют доступ к пространству локального диска и памяти своих виртуальных машин, Microsoft Azure балансирует нагрузку от всех запросов по всем экземплярам роли. Кроме того, экземпляр роли может быть остановлен и перемещен в любое время (например, если компьютер, на котором эксплуатируется экземпляр роли, требует обновления).

Динамическое управление работающими экземплярами роли важно для реализации функций масштабирования и обеспечения доступности облачных служб Microsoft Azure. Следовательно, код приложения в облаке должен быть разработан с учетом дистанционного хранения данных и информации о состоянии с использованием таких служб, как хранилище Microsoft Azure или База данных SQL Azure. Дополнительные сведения о функциях системы хранения данных см. в ресурсах раздела Хранение и доступ к данным на веб-сайте Microsoft Azure.

Требования к системе хранения данных

База данных SQL Azure — это решение по реляционной базе данных в Microsoft Azure. Для тех, кто в настоящее время использует SQL Server, переход на База данных SQL Azure должен оказаться более простым. Можно также запустить SQL Server на виртуальной машине. Если вы используете другую систему баз данных, один из вариантов — перемещение на базу База данных SQL Azure или SQL Server с помощью виртуальной машины. Помощники по миграции на SQL Server могут помочь это сделать. Дополнительные сведения о переносе данных в База данных SQL Azure см. в разделе Перенос данных в базу данных SQL Azure: средства и методы. Другой вариант — перенести стороннюю базу данных прямо на Microsoft Azure. Можно например установить систему баз данных на виртуальную машину. При этом в Магазине Azure существуют и сторонние предложения для таких систем, как MySQL и MongoDB.

Кроме того, рассмотрите возможность применить Microsoft Azure в качестве устойчивой, в высшей степени доступной и масштабируемой системы хранения данных. Один из оправданных подходов к проектированию состоит в применении эффективного сочетания База данных SQL Azure с таблицами, очередями и большими двоичными объектами системы хранения данных Microsoft Azure. Можно часто встретить пример, в котором База данных SQL Azure используется для хранения указателя на большой двоичный объект в хранилище Microsoft Azure. Это делается вместо хранения большого двоичного объекта непосредственно в базе данных. Это и эффективно, и более экономично.

Функциональная совместимость

Пакет SDK Microsoft Azure и средства для Visual Studio сильно упрощают процесс создания или миграции приложений .NET на Microsoft Azure.

Однако предположим, что используются программы с открытым исходным кодом или сторонние языки и средства разработки. Веб-сайты и облачные службы Microsoft Azure поддерживают приложения, написанные на Node.js, PHP, Python и Java (только для облачных служб). Если в вашем приложении используется другой язык, рассмотрите использование виртуальной машины. При работе со службами Microsoft Azure все операции основаны на API REST. Вы можете писать код непосредственно для него. Microsoft Azure также предоставляет официальные пакеты SDK для Java, Node.js, PHP, Python и Ruby, которые обеспечивают оболочки вокруг API REST. Имеются также пакеты SDK, созданные сообществом разработчиков, которые взаимодействуют с Microsoft Azure.

Разумеется, в зависимости от конкретной технологии придется преодолевать те или иные сложности. Для виртуальных машин необходимо установить необходимые среды выполнения и зависимости в образ. Для облачных служб потребуется добавить пользовательское действие при запуске, чтобы установить сторонние зависимости для нужной роли. Для веб-сайтов нужно внести небольшие изменения, чтобы обеспечить работу приложения в среде размещения PaaS. Превосходный ресурс в этой области см. в разделе Мосты функциональной совместимости и центр лабораторных работ.

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

Кроме этих проблем, многое о потенциальных сложностях разработки и решениях можно узнать, ознакомившись с литературой по переносу приложений в Microsoft Azure. Группой специалистов по шаблонам и методам Майкрософт опубликовано следующее руководство по миграции: Перемещение приложений в облако на платформу Microsoft Azure.

Microsoft Azure предоставляет платформу для создания служб, обеспечивающих высокую степень масштабируемости и доступности, и управления ими. Существуют два предложения PaaS: веб-сайты и облачные службы — и предложение виртуальных машин (IaaS). Кроме этих предложений существует множество поддерживающих служб и функций для разных сценариев приложений. Оплата производится только за требуемые ресурсы, причем в любое время можно увеличивать или уменьшать масштабы потребления. И для этого не нужно приобретать оборудование или инфраструктуру поддержки. Если бизнес может воспользоваться данной платформой для повышения гибкости, сокращения издержек и уменьшения риска, то Microsoft Azure хорошо подходит для конкретного приложения. Если дело обстоит именно так, можно рассмотреть конкретную архитектуру и варианты разработки в связи с использованием платформы. В частности, необходимо определить, требуется ли новая разработка, миграция или применение гибридных сценариев. По завершении такого анализа должна быть получена вся необходимая информация для принятия обоснованного решения о том, как наиболее эффективно использовать Microsoft Azure для достижения бизнес-целей.

Показ:
© 2014 Microsoft