Переход в облачный сервис связан с большим числом обстоятельств, и поэтому важно спланировать работу. Перенос инфраструктуры может быть простым, но в то же время, чтобы получить преимущества IaaS, и сэкономить средства может потребоваться полное изменение архитектуры приложения. В общем, придется переписать код заново.
Стратегия миграции приложения
Предварительный анализ приложения позволяет предположить будет ли выгода от переезда в облако или нет. Дело в том, что облачный сервис не самое дешевое решение. И если в обычной ситуации мы арендуем сервер, то в облачной – мы расходуем ресурсы. И снижение этих расходов, оптимизация приложения и использование правильных облачных решений позволит получить отличный результат. Стратегия миграции заключается в постепенной интеграции приложения в облако. Одно из его преимуществ заключается в возможности быстро попробовать и получить результат. И в то же время ничто не помешает вернуться на шаг назад. Постепенное внедрение облачных решений позволит, в конечном счете, использовать те, которые действительно нужны. Самое частое решение – гибридная инфраструктура, когда используются именно те инструменты несущие большие преимущества и выгоду. Теперь рассмотрим стратегии переноса вашего приложения в облако.
Rehost
Первый вариант помогает понять: готово ли приложение к облаку, какие инструменты получиться использовать и что нужно доработать. Этот вариант позволяет быстро развернуть ваше приложение в облаке. Он так же известен как «lift and shift». Приложение переносится так, как оно есть, без изменений кода.
Преимущества: Можно быстро перенести инфраструктуру приложения и испытать ее в облаке.
Для этого нужно скопировать ваши сервера с помощью Azure Site Recovery. Можно копировать как виртуальные машины, так и физические сервера. Облако включает в себя инструменты работы с разными базами данных. Инструмент миграции Azure Database Migration Service поможет в этом деле.
Refactor
Стратегия, которая позволяет сохранить код и логику приложения с минимальными изменениями, но в то же время использовать преимущества облачного сервиса.
По сути, этот вариант предлагает убрать из приложения все, что можно взять в облаке. Допустим, в приложении есть Active Directory. Так как в облаке есть свой сервис Azure Active Directory, обычный из приложения переносить не нужно, и можно использовать облачный. Тоже можно сказать о почтовых сервисах, SharePoint, файлообменниках и многих других, аналоги которых предоставлены в облаке.
Rearchitect
Стратегия заключается в оптимизации приложения под архитектуру облачного сервиса. При этом важно изменить и расширить его так, чтобы использовать преимущества облачного масштабирования. Это позволит повысить производительность и получить гибкое масштабирование.
При таком варианте из многих приложений делают просто статические сайты. Потому что это выгодно. Плата за хранение этого сайта в storage облака мала, так как html файлы занимают минимум места. И клиент платит только за трафик к своему сайту и только за занимаемое место сайта в storage.
Проблемы с миграцией Баз Данных.
Практически взять и перенести даже простую базу данных в Azure затруднительно. Дело в том, что нужно будет создать инстанс базы данных уровня B10, самый дорогой. Далее можно мигрировать базу данных, и только после этого понизить уровень до нормального по производительности и стоимости.
Этапы миграции
До начала миграции нужно оценить архитектуру приложения. Изучить производительность и проанализировать данные (в том числе анализ логов). Разобраться какие процессы обслуживания необходимы. До начала миграции не нужно «учесть всё». Облачные сервисы позволяют попробовать и испытать новые инструменты обратимо. На любом шаге можно вернуться назад. Исправить, доработать приложение или отказаться от внедрения.
Rehost
Основная цель первого этапа – анализ работы приложения путем проб и ошибок. После переноса в облако нужно понять, каким образом нужно доработать приложение, какие облачные средства можно использовать и как это сделать. Если возникли препятствия, всегда можно откатить и попробовать снова. Это большое преимущество облачного сервиса.
Есть два уровня этого этапа – Azure App service и Azure SQL Database. Для миграции SQL используем две утилиты – migration assistants. В результате получаем тот же сайт, написанный на ASP или dot NET и ту же базу данных, которая работает с SQL в облаке. IaaS поддерживает и другие типы баз данных, то есть у Azure есть для этого сервисы
Rebuild
Проанализировав свое приложение, дальше переходим к этапу подключения облачных сервисов. Те части инфраструктуры, которые могут быть заменены, перерабатываем в интерфейсы. Это позволяет создать облачную инфраструктуру.
Можно добавить в приложение облачный storage, cash, очереди и так далее. Получаем двухуровневое приложение в стиле Azure, наш web-application service.
Из него можно убрать постепенно ненужные вещи, которые не предоставляют услуг пользователям. Изменить backend в виде очередей. Добавить storage – чтобы весь контент получать через Content Delivery Network. Подключить redis cash, чтобы запросы кэшировались и база не дергалась лишний раз. Теперь это уже рабочее приложение.
Rearchitect
Меняем приложение – меняем сущность приложения и код. Цель – сделать приложение быстрым, экономичным и отказоустойчивым. Добавляем traffic manager, добавляем второй регион, который будет реплицировать static content, queues, базы. Но идея Azure – отказоустойчивое приложение, которое будет обслуживать пользователей в разных регионах.
Три варианта устойчивых баз данных. Когда не хотим потерять транзакции, потерять пользователей, и когда пользователи скользят по регионам. И для этого нужно переписывать код. Получаем отказоустойчивое масштабируемое приложение, доступное в разных регионах.
Результат.
Результат – ваше приложение улучшенное облачными сервисами. Держать руку на пульсе облачного провайдера выгодно. Новые инструменты появляются достаточно динамично. Их архитектура позволяет относительно просто испытать, попробовать, узнать подходит ли это вам.
Наша компания имеет большой опыт миграции решений в облако, обращайтесь, [email protected]