Большинство программ миграции в облако начинаются со сканирования инфраструктуры. Azure Migrate обнаруживает виртуальные машины. AWS Application Discovery Service сопоставляет серверы. Google Migration Center составляет инвентаризационную таблицу рабочих нагрузок. В течение нескольких дней команда получает электронную таблицу со списком каждого сервера, его загрузкой ЦП, объемом используемой памяти и оценочной стоимостью запуска аналогичной конфигурации в целевом облаке. Оценка инфраструктуры завершена. Можно начинать планирование.
Однако это невозможно. Потому что инвентаризация инфраструктуры показывает, на каком оборудовании работают ваши приложения, а не то, могут ли эти приложения работать в облаке, сколько будет стоить их перенастройка, какие из них имеют зависимости, которые нарушатся при миграции, какие написаны с использованием устаревших API, которые облачная платформа не поддерживает, или какие содержат десятилетнюю недокументированную бизнес-логику, которую необходимо будет понять, прежде чем можно будет подтвердить возможность преобразования. Обнаружение инфраструктуры является необходимым условием для оценки миграции в облако. Это не сама оценка.
Оцените свой код, прежде чем его переносить.
SMART TS XL Составляет карту всех зависимостей, блокирующих процессов и потенциальных кандидатов на рефакторинг по всему портфелю ваших приложений.
ПодробнееЧто такое оценка миграции в облако?
Оценка миграции в облако — это структурированный анализ, определяющий, можно ли, как и с какой стоимостью перенести набор рабочих нагрузок в облако. Она формирует доказательную базу для принятия трех решений: какую стратегию миграции применить к каждой рабочей нагрузке, сколько фактически будут стоить миграция с точки зрения трудозатрат и расходов на облако, и в какой последовательности следует мигрировать рабочие нагрузки для управления рисками зависимостей.
Комплексная оценка миграции в облако охватывает пять различных аспектов. Инструменты обнаружения инфраструктуры позволяют решить одну из них. Для остальных четырех требуются разные инструменты, разные методы и разные экспертные знания.
| Измерение оценки | На что он отвечает | Основные инструменты |
|---|---|---|
| Инфраструктура | Какие серверы, виртуальные машины и сервисы существуют? Каков профиль их использования? | Azure Migrate, AWS Application Discovery, Google Migration Center |
| Код приложения | Совместим ли код с облачными платформами? Что нужно изменить? | Основные моменты актерского состава SMART TS XLCloudPilot, GitHub Copilot App Modernization |
| Данные | Какие объемы данных существуют? Где хранятся данные? Какова сложность миграции и ограничения, связанные с соблюдением нормативных требований? | AWS Database Migration Service, Azure Database Migration Service, Striim |
| Безопасность и соответствие | Какие нормативные требования действуют? Какие существуют пробелы в безопасности? Какие изменения в области управления идентификацией и доступом (IAM) и шифрования необходимы? | AWS Security Hub, Microsoft Defender for Cloud, Prisma Cloud |
| Стоимость и совокупная стоимость владения | Какова полная стоимость миграции и общая стоимость владения после миграции? | Калькулятор цен AWS, калькулятор совокупной стоимости владения Azure, Infracost, Apptio Cloudability |
Организации, которые занимаются только инфраструктурой, разрабатывают планы миграции с неизвестным масштабом. В ходе миграции они обнаруживают неожиданные проблемы с приложениями, данными, безопасностью и затратами, когда устранение этих проблем обходится дороже всего.
Пять измерений оценки миграции в облако
Оценка инфраструктуры
Отправной точкой является оценка инфраструктуры. Она включает в себя инвентаризацию исходной среды: каждого сервера, виртуальной машины, контейнера и сервиса, с указанием их конфигурации, данных об использовании и зависимостей от других компонентов инфраструктуры.
Такие инструменты, как Azure Migrate или другие продукты, автоматизируют обнаружение компонентов и конфигураций рабочих нагрузок. Эти инструменты сокращают трудозатраты и обеспечивают согласованный сбор данных во всей вашей среде, хотя они могут упускать из виду недокументированные зависимости.
Azure Migrate — это стандарт для организаций, переходящих на Azure. Он выполняет обнаружение сред VMware vSphere, Hyper-V и физических серверов без использования агентов, предоставляя оценки готовности, рекомендации по оптимизации производительности и сметы расходов еще до переноса хотя бы одной рабочей нагрузки.
Сервисы AWS Application Migration Service (MGN) и AWS Application Discovery Service выполняют аналогичную функцию для целевых сред AWS. Discovery Service собирает данные о конфигурации и производительности локальных систем с помощью сбора данных без агентов или с помощью локально установленного агента.
Центр миграции Google обеспечивает унифицированный поиск и оценку возможностей миграции в Google Cloud, объединяя инвентаризацию активов, анализ зависимостей и моделирование совокупной стоимости владения в единой консоли.
Что предоставляют инструменты для управления инфраструктурой: инвентаризацию серверов, базовые показатели использования ресурсов, карты сетевых зависимостей между компонентами инфраструктуры и рекомендации по оптимизации размера целевого облачного уровня. Что они не предоставляют: никакой информации о совместимости приложений, работающих на этих серверах, с облаком, о стоимости изменения кода или о том, как будут мигрировать данные внутри этих приложений.
Оценка кода приложения
Анализ кода приложения выявляет проблемы совместимости и возможности модернизации, которые могут повлиять на успех миграции. Этот анализ необходим для обеспечения надежной работы приложений в Azure и эффективного планирования этапов миграции. Анализ кода приложения необходим для раннего выявления препятствий, снижения риска сбоя миграции и принятия решений относительно целевой архитектуры.
Анализ кода приложения выявляет четыре категории проблем, которые сканирование инфраструктуры обнаружить не может:
Препятствия совместимости , API, фреймворки или функции среды выполнения, которые отсутствуют или ведут себя иначе в целевой облачной среде. Java-приложение, созданное для сервера приложений Java EE, недоступного в целевой PaaS-службе, требует внесения изменений в код перед развертыванием. Приложение, использующее специфическое для Windows соглашение о путях к файлам, не может работать на облачном экземпляре на базе Linux без модификации.
Встроенные в код жестко закодированные предположения об инфраструктуре , IP-адреса, пути к файловым системам, имена серверов или номера портов больше не будут действительны в облачной среде. Это препятствия для миграции, которые не обнаружит ни одно сканирование инфраструктуры, поскольку они находятся внутри кода приложения, а не в конфигурации инфраструктуры.
Использование устаревших API , вызовов API, библиотек или функций платформы, которые целевая облачная среда не поддерживает или которые были заменены более старыми версиями. Поставщики облачных платформ регулярно объявляют устаревшими старые версии API, и приложения, использующие их, будут работать некорректно на новой платформе, даже если сегодня они работают правильно.
Сложность зависимостей — это внутренняя структура приложения, которая определяет, насколько сложно его мигрировать и можно ли его разбить на независимо развертываемые сервисы. Монолитное приложение с высокой внутренней связанностью сложнее и дороже мигрировать, чем приложение со слабой связанной структурой, независимо от данных инвентаризации инфраструктуры.
CAST Highlight выполняет автоматизированную оценку кода приложений на уровне портфеля, сканируя исходный код на нескольких языках для получения оценок готовности к облачным технологиям, выявления препятствий и анализа рисков, связанных с открытым исходным кодом. Он упоминается в рамках платформы внедрения облачных технологий Azure как рекомендуемый инструмент для рабочих нагрузок, не использующих .NET и Java.
Компания CloudPilot специализируется на детальной оценке готовности к облачным технологиям с оценкой совместимости и составлением планов миграции для JavaScript, Python, Node.js и Go.
GitHub Copilot App Modernization сочетает в себе возможности оценки AppCAT от CAST с помощью искусственного интеллекта для исправления кода, специально разработанного для рабочих нагрузок .NET и Java.
Для корпоративных сред, использующих COBOL, JCL, PL/I, RPG и другие языки программирования для мэйнфреймов наряду с современными стеками, эти инструменты не подходят. Оценка кода приложений для устаревших систем требует совершенно иного типа инструментов.
Оценка данных
Оценка данных определяет сложность, объем, требования к соответствию стандартам и метод миграции для каждого хранилища данных, находящегося в зоне ответственности. Ее часто недооценивают, поскольку она кажется простой: переместить базу данных, переместить данные, пока не выявится реальная сложность.
Ключевые вопросы, на которые должна ответить оценка данных:
Объём и пропускная способность : Какой объём данных существует? Какова скорость изменения? Можно ли перенести данные с простоем, или необходимо использовать непрерывную репликацию для достижения практически нулевого времени простоя при переключении?
Совместимость схемы : Поддерживает ли целевая база данных те же функции схемы, типы данных и хранимые процедуры, что и исходная? Конструкции PL/SQL, специфичные для Oracle, требуют преобразования перед миграцией на PostgreSQL или облачную альтернативу.
Суверенитет данных и соответствие нормативным требованиям : Где должны храниться данные в соответствии с законом? GDPR, HIPAA, PCI-DSS и отраслевые правила могут ограничивать выбор облачных регионов для размещения определенных категорий данных.
Взаимосвязь приложения : Насколько тесно код приложения связан с конкретной схемой базы данных? Изменение схемы, которое технически просто, может потребовать значительных изменений в коде приложения для его адаптации.
Сервисы AWS Database Migration Service и Azure Database Migration Service поддерживают непрерывную репликацию с минимальным временем простоя для однородных миграций (Oracle в Oracle, SQL Server в SQL Server) и преобразование схемы для неоднородных миграций (Oracle в PostgreSQL, SQL Server в Aurora).
Striim и Attunity обеспечивают потоковую передачу и репликацию данных в реальном времени для сценариев миграции с целью обеспечения высокой доступности, где простой базы данных недопустим.
Оценка безопасности и соответствия нормативным требованиям
Оценка безопасности определяет текущее состояние безопасности каждой рабочей нагрузки и выявляет изменения, необходимые для соответствия стандартам безопасности облачных вычислений, нормативным требованиям и принципам архитектуры нулевого доверия.
Оценка безопасности по параметрам должна включать в себя:
Управление идентификацией и доступом (IAM) : В локальных приложениях часто используются служебные учетные записи с широкими правами доступа и аутентификацией на основе паролей. Облачные среды требуют управления доступом на основе ролей, идентификаторов служб с минимальными привилегиями и аутентификации на основе сертификатов или токенов. Разрыв между текущим и требуемым IAM — это процесс миграции, не имеющий ничего общего с инвентаризацией инфраструктуры.
Шифрование : Требования к шифрованию данных в состоянии покоя и при передаче различаются в локальных и облачных средах. Приложения, которые управляют собственным шифрованием на уровне приложения, должны интегрироваться с облачными сервисами управления ключами. Незашифрованные хранилища данных, допустимые в частных сетях, должны быть зашифрованы перед переносом в облачные сервисы.
Сетевая безопасность : правила брандмауэра, сегментация сети и проверка трафика, реализованные на локальном сетевом оборудовании, должны быть переработаны в группы безопасности облака, конфигурации виртуальных сетей и правила брандмауэра для облачной среды.
Согласование нормативных требований : Каждая регулируемая отрасль имеет свои специфические требования к соответствию, которые соответствуют конкретным облачным конфигурациям. Рабочие нагрузки, соответствующие требованиям HIPAA, требуют выбора конкретных параметров конфигурации в отношении хранения данных, регистрации доступа и шифрования. PCI-DSS требует сегментации сети, которая должна быть реализована по-разному в облачной VPC и в физической сетевой инфраструктуре.
Microsoft Defender for Cloud обеспечивает оценку уровня безопасности и соответствие стандартам CIS, NIST, PCI-DSS и другим требованиям для рабочих нагрузок Azure.
Prisma Cloud (Palo Alto Networks) и AWS Security Hub предоставляют эквивалентные услуги по оценке безопасности в мультиоблачной среде и мониторингу соответствия требованиям.
Оценка затрат и совокупной стоимости владения
Оценка затрат — наиболее заметный результат миграции для заинтересованных сторон бизнеса, и именно она чаще всего выполняется неправильно. Распространенная ошибка заключается в сравнении текущих затрат на локальное оборудование с затратами на облачные вычисления и хранилище, что приводит к неполному и обычно вводящему в заблуждение сравнению.
Полная оценка совокупной стоимости владения включает в себя:
Затраты на облачную инфраструктуру : вычислительные ресурсы, хранилище, сети и управляемые сервисы в целевой облачной конфигурации. Оптимизация размеров на основе фактических данных об использовании (а не выделенной мощности) — это разница между точными и завышенными оценками.
Затраты на миграцию : трудозатраты инженеров, необходимые для внесения изменений в код приложения, миграции данных, перенастройки безопасности и тестирования. Оценки, основанные только на инфраструктуре, систематически недооценивают эти затраты, поскольку не дают представления о сложности приложения.
Изменения в лицензировании : переход от бессрочных локальных лицензий к облачным моделям лицензирования или от программного обеспечения конкретного поставщика к облачным альтернативам коренным образом меняет структуру затрат на лицензирование.
Изменения в операционной модели : команды, занимающиеся эксплуатацией физического оборудования на локальных серверах, заменяются командами, управляющими облачными сервисами. Меняются навыки, инструменты и численность персонала.
Затраты на обучение и переход : Команды, осваивающие новые облачные платформы, новые модели развертывания и новые операционные процедуры, несут потери производительности в период перехода.
Калькуляторы цен AWS , Azure TCO и Google Cloud учитывают стоимость облачной инфраструктуры. Infracost предоставляет оценку стоимости, интегрированную в конвейеры IaC, формируя сметы затрат в рамках процесса CI/CD. Apptio Cloudability и аналогичные инструменты FinOps обеспечивают постоянную прозрачность затрат после миграции.
Семь миграционных стратегий: как оценка определяет, какая из них применима.
Концепция «7 R» описывает стратегии, доступные для миграции каждой рабочей нагрузки. Оценка определяет, какая стратегия подходит именно вам, и неправильная оценка означает применение неправильной стратегии, что является основной причиной большинства перерасходов средств на миграцию.
| Стратегии | Что это значит | Сигнал оценки, указывающий на это |
|---|---|---|
| Повторный хост (подъем и перемещение) | Переход в облако без изменений кода. | Низкая сложность приложения, отсутствие препятствий для совместимости, совместимость с инфраструктурой. |
| Реплатформа | Незначительные изменения для использования облачных сервисов (например, переход на управляемую базу данных). | Умеренная взаимосвязь компонентов, возможность обновления конкретной платформы, допустимый объем изменений в коде. |
| Рефакторинг | Перепроектирование под облачные архитектуры (микросервисы, контейнеры) | Высокая степень связанности монолитных систем, значительные требования к масштабируемости, оправданные ожидаемым ростом трафика. |
| Реархитектор | Значительная переработка архитектуры приложения. | Приложение принципиально несовместимо с облачными технологиями; новая архитектура обеспечивает значительные преимущества для бизнеса. |
| Перестраивать | Переписать с нуля | Повреждение не подлежит экономически целесообразному восстановлению; замена обходится дешевле, чем устранение последствий. |
| Замените | Откажитесь от собственного приложения и перейдите на SaaS-альтернативу. | Приложение предоставляет стандартные функции, которые лучше реализуются с помощью существующего облачного сервиса. |
| Уход на пенсию | В связи с выводом приложения из эксплуатации оно больше не требуется. | В ходе оценки было установлено, что приложение устарело, дублирует существующие функции или заменено более старыми версиями. |
Инвентаризация инфраструктуры не может различить кандидатов на перенос, переплатформирование, рефакторинг и перестройку, все они выглядят одинаково на уровне инфраструктуры. Различие определяется оценкой кода приложения.
Оценка возможности миграции в облако для устаревших и мэйнфреймовых систем
Стандартные инструменты оценки миграции в облако разработаны для современной инфраструктуры: виртуальных машин, контейнеров, микросервисов и облачных приложений. Они плохо или совсем не работают с рабочими нагрузками мэйнфреймов, программами COBOL, работающими на IBM z/OS, потоками заданий JCL, управляющими пакетной обработкой, приложениями PL/I, обрабатывающими финансовые транзакции, и программами RPG, встроенными в системы AS/400.
Оценка миграции мэйнфреймов в облако требует принципиально иного подхода, поскольку ограничением является не уровень инфраструктуры. Ограничением является код приложения, накопленная за десятилетия бизнес-логика, неявные зависимости через общие наборы данных и книги сценариев, а также особенности поведения во время выполнения, которые невозможно выявить с помощью сканирования инфраструктуры.
Восемь анализов, необходимых перед ответственным планированием миграции на мэйнфрейм: инвентаризация программ, отображение зависимостей, извлечение бизнес-логики, выявление мертвого кода, классификация сложности, анализ пакетного планирования, оценка качества данных и отображение интеграции, подробно описаны в контексте снижения рисков миграции на мэйнфрейм . Каждый из этих анализов представляет собой оценку на уровне кода, а не на уровне инфраструктуры.
Сравнение инструментов оценки миграции в облако
В таблице ниже приведено сопоставление основных инструментов оценки миграции в облако с аспектами оценки, которые они охватывают, и наиболее подходящими для них сценариями.
| Инструмент | Уровень оценки | облачная цель | Для каких задач |
|---|---|---|---|
| Миграция Azure | Инфраструктура | Лазурный | Обнаружение виртуальных машин и серверов, оптимизация размеров, оценка стоимости Azure. |
| Служба обнаружения приложений AWS | Инфраструктура | AWS | Обнаружение локальных серверов для миграции в AWS. |
| Центр миграции Google | Инфраструктура | GCP | Инвентаризация активов и расчет совокупной стоимости владения при миграции в GCP. |
| КАСТ Основные моменты | Код приложения | Мульти-облако | Оценка готовности кода в масштабе всего портфолио для разных языков программирования |
| CloudPilot | Код приложения | Мульти-облако | Подробный анализ совместимости для Python, JS, Node.js, Go. |
| SMART TS XL | Код приложения + сопоставление зависимостей | Мульти-облако | COBOL, JCL, мэйнфреймы и многоязычный анализ портфеля |
| АМС DMS | Данные | AWS | Миграция базы данных с преобразованием схемы. |
| Служба миграции базы данных Azure | Данные | Лазурный | Миграция SQL Server, MySQL, PostgreSQL в Azure. |
| Стриим | Данные | Мульти-облако | Репликация в реальном времени для миграции данных без простоев |
| Защитник Майкрософт для облака | Безопасность. | Azure / Мультиоблачная среда | Оценка уровня безопасности и соответствия требованиям. |
| Призма Облако | Безопасность. | Мульти-облако | CSPM и обеспечение соответствия нормативным требованиям в средах WS, Azure и GCP. |
| Инфракост | Стоимость | Мульти-облако | Интегрированная с IaC оценка затрат в конвейерах CI/CD |
| Облачность приложения | Стоимость | Мульти-облако | Финансовые операции и текущее управление затратами на облачные сервисы. |
| Corent SurPaaS | Инфраструктура + приложение | Мульти-облако | Обнаружение, оценка и организация миграции с помощью ИИ |
Как SMART TS XL Выполняет анализ кода приложения для миграции в облако.
SMART TS XL Эта функция решает проблему оценки кода приложений, недоступную для инфраструктурных инструментов, особенно в корпоративных и устаревших средах, где портфель приложений охватывает множество языков, платформ и поколений технологий.
Для программы миграции, включающей программы на COBOL, потоки заданий JCL, сервисы Java, конвейеры Python и схемы SQL, SMART TS XL Создает единую модель зависимостей для всех них одновременно. Прежде чем команда миграции решит, что перенести на другой сервер, что переработать и что вывести из эксплуатации, SMART TS XL обеспечивает:
Полный перечень программного обеспечения : каждый исходный код программы, копибук, процедура и схема на всех языках программирования в среде, фактический перечень, а не документированный, который в устаревших средах обычно отличается на 20-30%.
Межъязыковое сопоставление зависимостей : Возможность сопоставления зависимостей приложения отслеживает, как программа на COBOL подключается к схеме DB2, которую запрашивает служба на Java, которая, в свою очередь, передает данные в конвейер Python, генерирующий выходные данные, используемые современным фронтендом на React. Эта цепочка межъязыковых зависимостей определяет последовательность миграции: компоненты с большим количеством зависимостей должны мигрировать после того, как их зависимые компоненты будут готовы.
Выявление мертвого кода : программы и процедуры, которые никогда не вызываются ни одним из путей выполнения в производственной среде, могут быть полностью исключены из области миграции. В крупных устаревших средах это обычно составляет 10-25% от общего объема кода, что позволяет значительно снизить затраты на этапе оценки.
Классификация сложности : Функция статического анализа кода классифицирует каждую программу по цикломатической сложности, количеству зависимостей копибука, количеству вызываемых функций и другим показателям, определяющим сложность миграции. Программы высокой сложности с большим количеством вызывающих функций являются кандидатами на рефакторинг или перестройку. Программы низкой сложности и с малым количеством зависимостей являются кандидатами на перенос на другую платформу.
Анализ воздействия до любых изменений : Возможность анализа воздействия позволяет ответить на вопрос «что будет затронуто, если эта программа изменится?» до начала любых миграционных мероприятий, преобразуя неизвестные риски в структурированный, перечисленный объем рисков.
Для организаций, планирующих программы миграции с мэйнфреймов в облако, SMART TS XLАвтора модернизация наследия Анализ позволяет провести предварительную оценку миграции, необходимую поставщикам услуг по миграции до начала работ по преобразованию: полный структурный перечень, граф зависимостей, классификация сложности и отчет об исключении неиспользуемого кода.
Что должна дать комплексная оценка миграции в облако?
Ценность оценки определяется только теми решениями, которые она позволяет принять. Полная оценка миграции в облако должна дать пять результатов, которые в совокупности определяют программу миграции:
Инвентаризация портфеля приложений с назначением стратегии миграции : каждое приложение в рамках проекта классифицируется как «Перенос на другую платформу», «Перенос на другую платформу», «Рефакторинг», «Реархитектура», «Перестройка», «Замена» или «Вывод из эксплуатации», с подтверждающими документами, обосновывающими каждую классификацию.
План миграции на основе зависимостей : последовательность миграции приложений, определяемая графом зависимостей, а не произвольными группировками. Приложения, не имеющие входящих зависимостей от других приложений, находящихся в области действия, могут мигрировать на ранних этапах. Приложения, от которых зависит множество других приложений, мигрируют на более поздних этапах, после того как их зависимые приложения будут готовы.
Общая смета затрат на миграцию включает в себя : инженерные работы, затраты на инструменты миграции, затраты на временное параллельное выполнение и затраты на обучение, а не только разницу в стоимости инфраструктуры.
Модель совокупной стоимости владения (TCO) после миграции : прогнозируемые затраты на облачные ресурсы, основанные на оптимально подобранных конфигурациях и фактических данных об использовании, в сравнении с текущими операционными затратами на локальных серверах, с учетом реалистичных предположений об изменениях в лицензировании и переходе к новой операционной модели.
Реестр рисков : выявленные риски, препятствия совместимости, сложные миграции данных, недокументированные зависимости, ограничения соответствия, с указанием вероятности их возникновения, влияния и предлагаемых мер по смягчению последствий для каждого из них.
Организации, которые предоставляют все пять этих результатов до начала миграции, обладают всей необходимой информацией для успешного завершения программы. Организации, которые пропускают оценку кода приложения, оценку данных или оценку безопасности, предоставляют неполные версии этих результатов и обнаруживают недостающие элементы во время миграции, когда каждое обнаружение обходится дороже.