6 стратегий миграции приложений в облако

«Какой бывает эмиграция? Что ж, это зависит от многих факторов: образования, экономического положения, языка, нового места и того, какую поддержку там можно найти.» — Даниэль Аларкон

В первом посте серии представлена концепция массовой миграции, которую мы будем называть просто «миграцией» в каждом из материалов. Во втором посте серии описан процесс массовой миграции в облако, а в материале ниже — третьем по счету и заключительном — описаны 6 различных стратегий миграции, которые мы видим у клиентов для переноса приложений в облако. Стратегии основаны на 5 R, которые компания Gartner описала в 2011 году. Хотя каждый из этих постов является самостоятельным, мы считем, что их лучше читать вместе.

Разработка стратегии миграции

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

Используя эти знания, организации могут составить план (который может быть изменен по мере продвижения миграции и извлеченных уроков) того, как они будут подходить к миграции каждого из приложений в своем портфеле и в каком порядке.

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

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

6 стратегий миграции приложений: «6 R’s»

Мы видим 6 наиболее распространенных стратегий миграции приложений:

1. Рехостинг (rehosting)  или “lift-and-shift” – перенос приложений “как есть”.

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

В большинстве случаев, процесс рехостинга можно автоматизировать с помощью инструментов (например, AWS Application Migration Service, AWS VM Import/Export), хотя некоторые клиенты предпочитают делать это вручную, пока они учатся применять свои устаревшие системы на новой облачной платформе.

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

2. Смена платформы (Replatforming) — перенос с оптимизацией.

Здесь вы можете сделать несколько облачных (или других) оптимизаций, чтобы получить ощутимую выгоду, но в остальном вы не меняете основную архитектуру приложения. Возможно, вы хотите сократить количество времени, которое вы тратите на управление экземплярами баз данных, путем перехода на платформу “база данных как сервис”, например Amazon Relational Database Service (Amazon RDS), или переведя свое приложение на полностью управляемую платформу, например Amazon Elastic Beanstalk.

Крупная медиакомпания, с которой мы сотрудничаем, перенесла сотни веб-серверов, которые работали локальном дата центре, на AWS, и в процессе перешла с WebLogic (контейнер приложений Java, требующий дорогостоящей лицензии) на Apache Tomcat, аналог с открытым исходным кодом. Эта медиа-компания сэкономила миллионы на лицензионных расходах вдобавок к экономии и гибкости, которые она получила благодаря переходу на AWS.

3. Повторная покупка (Repurchasing) — переход на другой продукт.

Чаще всего мы видим (repurchasing), как переход на SaaS платформу. Переход CRM на Salesforce.com, HR-системы на Workday, CMS на Drupal и так далее.

4. Рефакторинг / смена архитектуры (Refactoring / Re-architecting)

Переосмысление архитектуры и разработки приложения, как правило, с использованием нативных облачных (cloud-native) функций.

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

Если вы хотите перейти от монолитной архитектуры к сервис-ориентированной (или беcсерверной) архитектуре, чтобы повысить гибкость или улучшить непрерывность бизнеса (я слышал истории о том, как ремни вентиляторов для мейнфреймов заказывали на e-bay)? Этот подход миграции, как правило, самый дорогой, но, если ваш продукт востребован на рынке, он может быть и самым выгодным.

5. Вывести из эксплуатации (Retire) – избавиться от приложения.

После составления списка приложений, вы можете определить бизнес-заказчиков каждого приложения. Мы обнаружили, что до 10% (мы встречали и 20%) приложений корпоративного портфеля приложений больше не используются и их можно просто отключить. Такая экономия может повысить эффективность бизнеса, направив высвободившиеся бюджет другим командам на то, чем пользуются люди, а также сократить низкоприоритетные области, которые требуют обеспечения безопасности.

6. Оставить (Retain)

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

***

Каков ваш опыт миграции? Мы бы хотели услышать об этом и разместить это в своем блоге!