Когда дело доходит до миграции в облако, можно выделить два основных ключа успеха этого процесса.

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

Во-вторых, определите как успех выглядит для Вас, команды, организации. Шаги, предпринимаемые сейчас, готовят почву для успеха в будущем.

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

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

Определение (взаимных) зависимостей

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

Application Insights

Полезным инструментом в этом процессе является Application Insights. Хотя его основной функцией является мониторинг приложения, Application Insights может использоваться для формирования осведомленности о службах, к которым подключается приложение.  Существует 2 основных метода интеграции Application Insights  - Codeless Attach и с использованием SDK.

И хотя Application Insights - служба, работающая в Azure, Вы не ограничены в использовании только приложений Azure. Application Insights также предлагает простой доступ к рабочим нагрузкам, работающим в IIS через IIS (или Status Monitor М2).

Application Map

Application Map помогает визуализировать и отслеживать проблемы в распределенных приложениях.

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

Почти у всего остального есть какие-либо взаимодействия, и Application Map помогает обнаружить их.  Это особенно полезно для приложений, когда нет команд, назначенных для их обслуживания или предоставляемых подрядчиками или консультантами.

Codeless Attach

Поговорим о сборе данных с помощью Application Insights. Первый метод - Codeless Attach-  позволяет Application Insights отслеживать приложение без изменения кода.   Настроить его на Windows Server довольно просто.

Сначала, установите  модуль Power Shell Az.ApplicationMonitor.

Enable-ApplicationInsightsMonitoring -ConnectionString xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Теперь любое приложение, которое еще не ссылается на Application Insights SDK будет автоматически инструментировано.

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

Вы можете проверять состояние каждого веб-сайта в IIS с помощью Get-ApplicationInsightsMonitoringStatus cmdlet.

Другой вариант - включить Application Insights SDK в приложение.  Недавние шаблоны .Net приложений уже включают Application Insights SDK; в таком случае речь идет о конфигурации инструментального ключа или о строке подключения.

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

После того как приложение инструментировано, Вам нужно дать ему время поработать. Некоторые зависимости могут быть часто недоступны, поэтому продление периода обнаружения - на дни, недели или даже месяцы может помочь выявить доступные ресурсы.

В то время как Application Insights запущен для сбора сведений Application Map, у Вас есть возможность собирать данные о производительности.  Это может стать основой того, как приложение должно работать в облаке.  Вы увидите вызовы из приложения в зависимости. Это поможет оценить необходимость перемещения зависимости в облако (или же ее можно оставить локально на какое-то время), эффективность сервиса SKU, на котором Вы работаете: нужно ли его масштабировать или у Вас есть место для его уменьшения и экономии денег.

Теперь, когда у Вас есть какие-то данные о приложении и его зависимостях, можно приступать к планированию миграции.

Перемещение приложения и базы данных вместе имеет смысл, учитывая тесную связь и зависимость производительности страницы от результатов работы базы данных.

No Comments