Поделиться через

Выбор правильного размещения в Azure

В этой статье приводятся рекомендации и сравнения между несколькими вариантами, которые вы используете в Azure при переносе существующих приложений .NET Framework из локальной среды в Azure.

Основными областями, которые следует учитывать при переносе существующих приложений .NET в Azure:

  1. Варианты вычислений
  2. Выбор базы данных
  3. Рекомендации по работе с сетями и безопасностью
  4. Рекомендации по проверке подлинности и авторизации

Варианты вычислений

При переносе существующих приложений .NET Framework в Azure имеется несколько вариантов. Однако, так как платформа .NET Framework зависит от Windows, следующие варианты ограничены службами вычислений на основе Windows.

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

Виртуальные машины Azure Служба приложений Azure Контейнеры Windows
Когда использовать
  • Приложение имеет существенные зависимости от сервера и локальных установок .msi.
  • Вам нужен самый простой путь миграции приложений
 Приложение не имеет зависимостей на сервере, это просто чистое ASP.NET веб-приложение (MVC, WebForm) или N-уровень приложения (веб-API, WCf), обращающегося к серверу базы данных.
  • Приложение имеет зависимости на исходном сервере, но эти зависимости можно включить в образ Docker Windows.
Преимущества и выгоды
  • Самый простой путь миграции
  • Знакомая среда. Среда развертывания — это виртуальная машина, поэтому она похожа на локальные серверы.
 Текущее обслуживание PaaS, самый простой способ управления и масштабирования приложений в Azure.
  • Готов к будущему, Cloud DevOps-Ready с зависимостями, включенными в контейнеры приложения.
  • Почти не требуется рефакторинг кода .NET /C#.
Минусы Это IaaS. Обслуживание является дорогостоящим. Необходимо управлять инфраструктурой виртуальной машины, включая сетевую инфраструктуру, балансировщик нагрузки, увеличение ресурсов, управление IIS и т. д.
  • Не все приложения поддерживаются
  • Некоторым приложениям может потребоваться рефакторинг и даже немного перепроектировать, поэтому они поддерживают службу приложений Azure.
  • Кривая обучения навыков Docker
  • Некоторые изменения параметров кода и конфигурации приложения
Требования Виртуальная машина Windows Server с теми же требованиями, что и приложение для локальной среды Требования службы приложений Azure, указанные в проверках готовности.
Миграция См . статью "Миграция на виртуальные машины Azure" См. статью "Миграция службы приложений Azure" Следуйте рекомендациям, сценариям и пошаговые руководствам, описанным в статье "Модернизация существующих приложений .NET с помощью Электронной книги контейнеров Azure и Windows"

На следующей блок-схеме показано дерево решений при планировании миграции в Azure для ваших существующих приложений .NET Framework. Если это жизнеспособно, попробуйте сначала вариант A, но вариант B — самый простой путь для выполнения.

Блок-схема, представляющая дерево принятия решений по хостингу

Выбор базы данных

При переносе реляционных баз данных в Azure у вас есть несколько вариантов. См. статью "Миграция базы данных SQL Server в Azure ", чтобы выбрать правильный путь миграции базы данных для существующего приложения .NET.

Рекомендации по работе с сетями и безопасностью

При развертывании приложений в общедоступном облаке, например Microsoft Azure, вы можете изолировать и защитить определенные сети путем создания сетевых dmZ, таких как dmZ между Azure и локальной средой или dmZ между Azure и Интернетом. DmZ можно реализовать с помощью виртуальной сети Azure.

Виртуальные сети Azure позволяют:

  • Создание гибридной инфраструктуры, которую вы управляете
  • Использование собственных IP-адресов и DNS-серверов
  • Защита подключений с помощью VPN-подключения IPsec или ExpressRoute
  • Получение детализированного управления трафиком между подсетями
  • Создание сложных топологий сети с помощью виртуальных устройств
  • Получение изолированной и высокобезопасной среды для приложений

Чтобы приступить к созданию собственной виртуальной сети, ознакомьтесь с документацией по виртуальной сети Azure.

Рекомендации по проверке подлинности и авторизации при миграции в Azure

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

Многие существующие корпоративные приложения B2E .NET, работающие в локальной среде, используют Active Directory для проверки подлинности и управления удостоверениями. Azure AD Connect позволяет интегрировать локальные каталоги с Azure Active Directory. Чтобы приступить к работе, см. статью "Интеграция локальных каталогов с Azure Active Directory".

Дополнительные сведения о планировании в связи с Azure Active Directory см. в статье "Требования к идентификации" для решения гибридной идентификации.

Другие варианты протокола проверки подлинности — OAuth и OpenID, которые часто используются в приложениях, подключенных к потребителю. При использовании автономных баз данных идентичностей, таких как база данных SQL ASP.NET, объединённая с IdentityServer4 с использованием OAuth, подключение к локальным базам данных или каталогам обычно не требуется.

Дальнейшие шаги

Перенос веб-приложения ASP.NET в службу приложений Azure