Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Благодаря четкой инвентаризации и пониманию рабочих нагрузок план внедрения облака должен определить, что делать с каждой рабочей нагрузкой в облаке. Существует несколько стратегий миграции, иногда называемых "R-ами" облачной миграции. Каждая рабочая нагрузка может быть прекращена, сохранена, повторно размещена, переплатформирована, отрефакторена, переархитектурирована, перестроена или заменена. В этом разделе описывается, как выбрать правильный подход для каждой рабочей нагрузки, показывая варианты, когда выбрать каждый из них и преимущества и минусы компромиссов.
Обзор стратегии миграции
В следующей таблице представлен обзор всех доступных стратегий миграции в облако. Используйте эту ссылку, чтобы понять основной бизнес-драйвер каждой стратегии и ключевые индикаторы, которые сигнализируют о применении каждого подхода к рабочим нагрузкам.
| Стратегия миграции в облако | Бизнес-драйвер | Ключевые показатели этой стратегии |
|---|---|---|
| Retire | Требуется вывод избыточных или низкозначных рабочих нагрузок | • Нагрузка на систему имеет ограниченную текущую или будущую бизнес-ценность. • Затраты на миграцию или модернизацию перевешивают бизнес-преимущества. |
| Rehost | Требуется минимальное нарушение бизнеса и отсутствие необходимости в модернизации в ближайшем будущем | • Рабочая нагрузка стабильна • Рабочая нагрузка совместима с Azure • Краткосрочные цели внедрения облака • Не требуется немедленной модернизации • Сокращение капитальных расходов • Освобождение пространства центра обработки данных • Неопытность с Azure |
| Смена платформы | Требуются решения PaaS и минимальные изменения кода для разгрузки обслуживания и повышения надежности. | • Повышение надежности и восстановления после аварий • Сокращение затрат на ОС и лицензирование • Улучшение времени перехода в облако с умеренной инвестицией • Контейнеризация приложения |
| Refactor | Требуется изменение кода для уменьшения технического долга или оптимизации кода для облака | • Снижение затрат на обслуживание • Сокращение технического долга • Использование Azure SDKs • Повышение производительности кода • Оптимизация затрат на код • Применение шаблонов облачного проектирования • Код инструментирования для мониторинга |
| Rearchitect | Требуется изменение архитектуры для разблокировки возможностей в облаке | • Приложению требуется модульность или разбиение на службы • Требования масштабирования зависят от компонентов • Архитектура должна поддерживать будущие инновации • Использование различных стеков технологий |
| Replace | Требуется решение SaaS/AI для упрощения операций | • Упрощение операций • Внутренние ресурсы разработки лучше используются в другом месте • Мало необходимости в настройке |
| Rebuild | Требуется новое облачное решение для удовлетворения требований | • Устаревшая система слишком устаревшая или нефлексная • быстрее создавать приложения • сократить эксплуатационные затраты • Требуются современные платформы и инструменты |
| Удерживать | Требуется стабильность и нет изменений | • Рабочая нагрузка стабильна, соответствует требованиям и соответствует бизнес-потребностям • Нет краткосрочных драйверов для перемещения • низкая рентабельность от миграции |
Определите бизнес-факторы перед миграцией
Бизнес-драйвер определяет, почему рабочая нагрузка должна измениться для поддержки конкретной бизнес-цели. Бизнес-водители подключают решения по внедрению облака к измеримой бизнес-ценности и стратегическим целям. Определение этих драйверов гарантирует, что усилия по миграции предназначены и соответствуют приоритетам организации.
Определение бизнес-целей. Бизнес-цели — это высокоуровневые результаты, которые организация хочет достичь от внедрения облака, таких как внедрение искусственного интеллекта, повышение гибкости, ускорение инноваций, снижение затрат и повышение устойчивости. Эти цели обеспечивают стратегический контекст для всех решений по миграции. Используйте стратегические документы планирования, интервью руководителей или бизнес-семинары для выявления и проверки этих целей с заинтересованными лицами.
Определение пробелов. Выполните высокоуровневый анализ пробелов, чтобы понять, что каждая рабочая нагрузка должна изменить, чтобы повысить поддержку определенных бизнес-целей. Этот анализ должен учитывать текущие ограничения производительности, масштабируемости, соответствия требованиям, взаимодействия с пользователем и архитектуры. Задокументируйте все недостатки, которые не позволяют нагрузке полностью обеспечить нужные результаты.
Определите ключевой фактор бизнеса. Бизнес-драйвер возникает из разрыва между текущим состоянием рабочей нагрузки и его требуемым будущим состоянием. Он представляет определенную, действимую причину изменения. Эти драйверы помогут выбрать соответствующую стратегию миграции.
Бизнес-драйвер Стратегия миграции Требуется вывод избыточных или низкозначных рабочих нагрузок Retire Требуется минимальное нарушение бизнеса и отсутствие необходимости в модернизации в ближайшем будущем Rehost Требуются решения PaaS и минимальные изменения кода для разгрузки обслуживания и повышения надежности. Изменение платформы Требуется изменение кода для уменьшения технического долга или оптимизации кода для облака Refactor Требуется изменение архитектуры для разблокировки возможностей в облаке Rearchitect Требуется решение SaaS/AI для упрощения операций Replace Требуется новое облачное решение для удовлетворения требований Rebuild Требуется стабильность и нет изменений Retain
Выбор правильной стратегии миграции
Стратегия миграции определяет, как каждая рабочая нагрузка переходит в Azure на основе своего бизнес-драйвера. Просмотрите узкий список стратегий и проверьте выбранный вариант с деловыми и техническими заинтересованными лицами. Удалите параметры, конфликтующие с ограничениями соответствия, безопасности или эксплуатации. При завершении стратегии рассмотрите готовность к Azure, навыки команды и сложность интеграции.
1. Выход из эксплуатации (списание)
Вывод из эксплуатации рабочих нагрузок, которые больше не предоставляют бизнес-ценность. Эта стратегия важна, если рабочие нагрузки устарели, недостаточно используются или избыточны. Проверьте это решение, убедив, что рабочая нагрузка устарела и не имеет критически важных зависимостей, которые повлияют на другие системы. Обновите инвентаризацию по мере вывода рабочих нагрузок.
| Бизнес-драйвер | Ключевые показатели этой стратегии |
|---|---|
| Требуется вывод избыточных или низкозначных рабочих нагрузок | • Рабочая нагрузка имеет ограниченную текущую или будущую бизнес-ценность • Затраты на миграцию или модернизацию перевешивают преимущества бизнеса |
2. Повторное размещение (например, миграция)
Стратегия рехостинга обеспечивает быструю миграцию с низким уровнем риска путем перемещения рабочих нагрузок в Azure с минимальными изменениями. Повторное размещение — это миграция один-в-один, которая перемещает виртуальные машины в IaaS, IaaS в IaaS и PaaS в PaaS.
| Бизнес-драйвер | Ключевые показатели этой стратегии |
|---|---|
| Требуется минимальное нарушение бизнеса и отсутствие необходимости в модернизации в ближайшем будущем | • Рабочая нагрузка стабильна • Рабочая нагрузка совместима с Azure • Миграция с низким риском • Краткосрочные цели внедрения облака • Не требуется немедленной модернизации • Сокращение капитальных расходов • Освободить пространство центра обработки данных • Неопытность с Azure |
Не переносите проблемные рабочие задачи. Повторное размещение не устраняет существующие проблемы производительности, надежности или архитектуры. Перенос таких рабочих нагрузок без модернизации может сохранять технический долг и требовать доработки позже. Вместо этого модернизируйте эти рабочие нагрузки во время миграции, чтобы устранить первопричины.
Убедитесь, что рабочая нагрузка не потребует модернизации в течение двух лет. Повторное размещение подходит только в том случае, если вы уверены, что рабочая нагрузка остается в текущем состоянии не менее двух лет. Если модернизация вероятна, рассмотрите возможность рефакторинга или перепроектирования, чтобы избежать дублирования усилий.
Используйте перенастройку для создания основных облачных операций. Повторное размещение помогает командам получать опыт работы с Azure операциями, управлением и управлением затратами. Эта ранняя экспозиция поддерживает более широкие цели внедрения облака и подготавливает команды для более сложных усилий по модернизации.
| Исходная среда | целевой объект Azure | Примеры повторного размещения | Guidance |
|---|---|---|---|
| On-premises | Azure IaaS | Локальные серверы → Виртуальные машины Azure | Руководства по принятию решений по технологии |
| Другие облачные IaaS | Azure IaaS | AWS EC2 → Виртуальные машины Azure Google Cloud Compute Engine → Виртуальные машины Azure |
Сопоставление служб AWS с Azure Сопоставление служб Google Cloud и Azure |
| Другие облачные PaaS | Azure PaaS | AWS Beanstalk → Служба приложений Azure Google Cloud App Engine → Служба приложений Azure |
Сопоставление служб AWS и Azure Сопоставление служб Google Cloud с Azure |
3. Переплатформа (модернизация среды размещения)
Переплатформирование перемещает рабочие нагрузки в современную среду размещения с минимальными изменениями кода. Эта стратегия важна, если вы хотите уменьшить управление инфраструктурой, повысить масштабируемость и упростить операции без полного перезаписи приложения.
| Бизнес-драйвер | Ключевые показатели этой стратегии |
|---|---|
| Требуются решения PaaS и минимальные изменения кода для разгрузки обслуживания и повышения надежности. | • Преимущества рабочей нагрузки от упрощенной надежности и аварийного восстановления • Рабочая нагрузка снижает нагрузку на ОС и расходы на лицензирование • Команда может контейнеризировать или перепаковать приложение с умеренными усилиями • Миграция улучшает время перехода на облачные технологии без значительного рефакторинга. |
Выберите рабочие нагрузки, в которых параметры PaaS снижают эксплуатационные расходы, повышают надежность или упрощают аварийное восстановление. Для использования служб PaaS возможно потребуется минимальный рефакторинг кода.
| Исходная среда | целевой объект Azure | Примеры переплатформирования | Guidance |
|---|---|---|---|
| On-premises | Azure PaaS | Виртуальные машины → Служба приложений Azure SQL Server на виртуальной машине → База данных SQL Azure |
Шаблон надежного веб-приложения Руководства по миграции базы данных |
| Другие облачные IaaS | Azure PaaS | AWS EC2 → Служба приложений Azure MySQL в AWS EC2 → База данных SQL Azure |
Перенос из других облачных сервисов в Azure Руководства по миграции базы данных |
| Azure IaaS | Azure PaaS | Виртуальные машины Azure → Служба приложений Azure SQL Server on Azure Virtual Machines → База данных SQL Azure |
Шаблон надежного веб-приложения Руководства по миграции базы данных |
4. Рефакторинг (модернизировать код)
Рефакторинг улучшает внутреннюю структуру кода без добавления новых функций. Эта практика важна во время внедрения облака, так как она помогает командам модернизировать устаревший код, уменьшить технический долг и подготовить рабочие нагрузки к долгосрочной поддержке в Azure. Необходимо рефакторинг кода, когда процесс миграции создает уникальную возможность для решения технического долга или когда поведение после миграции показывает области улучшения.
| Бизнес-драйвер | Ключевые показатели этой стратегии |
|---|---|
| Требуется изменение кода для уменьшения технического долга или оптимизации кода для облака | • Рабочая нагрузка имеет высокие затраты на обслуживание • База кода содержит значительный технический долг • Azure SDKs или службы могут повысить производительность или наблюдаемость • Команда может оптимизировать затраты на код или применить шаблоны проектирования облака |
5. Реархитектурирование (модернизация архитектуры и кода)
Стратегия повторной иерархии перепроектирует архитектуру рабочей нагрузки, чтобы повысить масштабируемость, гибкость и ориентацию службы. Эта стратегия важна, если необходимо разбить монолитные приложения, внедрить микрослужбы или включить целевое масштабирование. Следует пересмотреть архитектуру, если текущая архитектура ограничивает ваши возможности по достижению бизнес-целей или эффективному масштабированию. Пример см. в статье "Шаблон современного веб-приложения".
| Бизнес-драйвер | Ключевые показатели этой стратегии |
|---|---|
| Требуется изменение архитектуры для разблокировки возможностей в облаке | • Приложению требуется модульность или разбиение на службы • Требования масштабирования зависят от компонента • Архитектура должна поддерживать будущие инновации • Решение использует смешанные стеки технологий |
6. Замена (используйте альтернативу SaaS)
Стратегия замены использует коммерческие решения SaaS для устранения необходимости пользовательской разработки и текущего обслуживания. Эта стратегия идеально подходит, если предложения SaaS соответствуют бизнес-потребностям с минимальными настройками. Замените рабочие нагрузки, когда решения SaaS предлагают сопоставимые функции, возможности интеграции соответствуют требованиям, а общая стоимость владения оправдана переходу. Учитывайте сложность миграции данных, потребности обучения пользователей и изменения процесса при оценке вариантов замены. Распространенные сценарии замены включают системы CRM, платформы кадров и средства совместной работы, где зрелость SaaS обеспечивает надежные альтернативные варианты пользовательских решений.
| Бизнес-драйвер | Ключевые показатели этой стратегии |
|---|---|
| Требуется решение SaaS/AI для упрощения операций | • Устаревшая система слишком устаревшая или негибка • Команда должна ускорить инновации • Для решения требуются современные платформы и инструменты • Операционные затраты слишком высоки в текущей среде |
7. Перестроение (построение облачного нативного)
Стратегия перестроения — это полное перестроение рабочей нагрузки с помощью облачных нативных решений. Этот подход подходит, если устаревшие системы устарели или когда модернизация невозможна. Вместо модернизации устаревших функциональных возможностей можно переимыслить решение для использования Azure возможностей, таких как PaaS, автоматизация и ИИ. Для некоторых рабочих нагрузок требуется перестроение, например DHCP-сервер. Для других рабочих нагрузок лучше развертывать новые экземпляры служб в Azure, а не переносить их, например контроллеры домен Active Directory.
| Бизнес-драйвер | Ключевые показатели этой стратегии |
|---|---|
| Требуется новое облачное решение для удовлетворения требований | • Рабочая нагрузка имеет зрелую альтернативу SaaS • Внутренние ресурсы разработки лучше используются в других местах • Для решения требуется небольшая настройка |
8. Сохранить (сохранить как есть)
Стратегия сохранения сохраняет рабочие нагрузки в текущей среде, когда они стабильны, совместимы и соответствуют всем текущим и будущим бизнес-потребностям без краткосрочных драйверов для перемещения. Необходимо сохранить рабочие нагрузки, которые нельзя перенести из-за ограничений нормативных требований, технических зависимостей или требований к непрерывности бизнес-процессов. Используйте Azure Arc для управления сохраненными локальными рабочими нагрузками из Azure, предоставляя унифицированные возможности управления. Рассмотрим более современное локальное решение, например Azure Local для рабочих нагрузок и подключение к Azure. Смена рабочих нагрузок, которые не могут быть перенесены на другую волну миграции, или повторно их перенесите позже при изменении ограничений.
| Бизнес-драйвер | Ключевые показатели этой стратегии |
|---|---|
| Требуется стабильность и нет изменений | • Рабочая нагрузка стабильна, соответствует требованиям и соответствует бизнес-потребностям. • Нет ближайшего драйвера для миграции • Миграция предлагает низкую отдачу от инвестиций |
Понять, когда модернизировать во время миграции
Модернизация во время миграции подразумевает перенос на другую платформу, перепроектирование или рефакторинг нагрузок, чтобы максимально использовать потенциал облака. Модернизация может обеспечить долгосрочные преимущества, но представляет сложность и риск для временных шкал миграции. Необходимо оценить, следует ли модернизировать во время миграции или отложить модернизацию на этапы после миграции на основе четкого бизнес-обоснования. Следуйте приведенным ниже рекомендациям.
Модернизируйте, когда у вашей команды есть необходимые навыки и время. Попытка модернизации без достаточного опыта или времени увеличивает риск и задержки. Если ваша команда не имеет готовности, отложите модернизацию на более поздний этап.
Модернизация рабочих нагрузок, требующих обновлений совместимости. Устаревшие технологии, неподдерживаемые пакеты SDK или необходимость внедрения решений SaaS могут потребовать модернизации. Обосновывать каждое усилие четким бизнес-обоснованием.
Модернизация при миграции обеспечивает финансирование и выравнивание. Проекты миграции часто открывают возможности для финансирования и поддержки заинтересованных сторон. Используйте эту возможность для согласования модернизации с бизнес-приоритетами. Задержка может привести к неэффективной рабочей нагрузке и пропущенным возможностям.
Доведение решений до сведения заинтересованных лиц
Четкое взаимодействие гарантирует, что все заинтересованные лица понимают и поддерживают решения по миграции во время процесса внедрения. Выравнивание заинтересованных сторон снижает риск выполнения и улучшает результаты проектов путем установления общего понимания приоритетов и ограничений. Необходимо установить структурированный план коммуникации для поддержания выравнивания в процессе миграции. Следуйте приведенным ниже рекомендациям.
Определите метрики успеха, которые проверяют бизнес-результат. Метрики успеха позволяют оценить ценность выбранного действия и проверить, достигается ли бизнес-цель. Этот шаг гарантирует, что решения основаны на бизнес-ценности, а не на техническом завершении. Используйте такие метрики, как:
Стратегия миграции в облако Примеры метрик успешности Retire • Удалите 100% рабочих нагрузок, признанных устаревшими, до миграции. Rehost • Перенос 100% рабочих нагрузок уровня 1 из другого облака в Azure без снижения уровня обслуживания (SLA)
• Вывод из эксплуатации 30% локальной инфраструктуры после миграции.Смена платформы • Сокращение времени выполнения развертывания на 30% для перенесенных приложений
• Сокращение затрат на инфраструктуру и лицензирование на 25% в течение 12 месяцевRefactor • Повышение времени отклика приложения на 40% с помощью Azure собственных служб
• Обеспечьте покрытие наблюдаемости на уровне 95% с помощью инструментирования кодаRearchitect • Поддержка 2x пользовательской нагрузки без снижения производительности
• Интеграция трех новых Azure собственных служб в существующую архитектуруReplace • Перенос CRM на SaaS с 99.9% времени безотказной работы и без кастомного кода
• Перенаправление 30% усилий разработчиков на конкурентные преимущества.Rebuild • Запуск нового облачного приложения за три месяца против шести месяцев в локальной среде
• Сокращение эксплуатационных расходов на 40% с помощью служб PaaSУдерживать • Поддерживать текущее соглашение об уровне обслуживания и соответствие требованиям
• Управление локальными рабочими нагрузками из Azure с помощью Azure ArcДокументируйте и делитесь решениями по обработке рабочей нагрузки со всеми соответствующими заинтересованными лицами. Решения о миграции могут повлиять на несколько организационных функций и требуют широкого участия заинтересованных лиц. Включите владельцев бизнеса, юридические команды, команды безопасности и технических руководителей в обсуждение решений. Объясните, как каждое решение стратегии миграции поддерживает документированные бизнес-цели и решает проблемы заинтересованных лиц.
Координация планов миграции с помощью команды по стратегии облака. Команда по облачной стратегии предоставляет контекст организации и гарантирует соответствие решениям по миграции с более широкими целями внедрения облака. Обычная координация предотвращает конфликты между решениями по отдельным рабочим нагрузкам и стратегией корпоративного облака. Просмотрите выбор стратегии миграции в рамках плана внедрения облака, установленного на этапе стратегии, чтобы обеспечить согласованность.
Регулярное взаимодействие между владельцами мандатов и исполнительными командами. Непрерывное взаимодействие между лицами, принимающими решения, и исполнителями гарантирует, что планы остаются жизнеспособными по мере того, как технические реалии возникают. Назначьте регулярные проверки для отслеживания хода миграции, идентификации рисков и устранения технических проблем. Используйте этот цикл обратной связи для корректировки стратегий миграции при возникновении проблем реализации или новых возможностей.
Просмотрите и обновите стратегии миграции на основе изменяющихся требований. Бизнес-приоритеты и технические аналитические сведения изменяются во время процесса миграции, требуя корректировки стратегии. Создайте регулярный цикл проверки для повторного анализа решений по обработке рабочих нагрузок в отношении текущих бизнес-целей и технических возможностей. Обновите сопоставления стратегий, чтобы отразить новые приоритеты, уроки, полученные и изменяющие потребности организации.