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

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

У большинства компаний имеется несколько способов миграции.

Перенос. Бизнес-приложения переносятся в облако без какой-либо модификации кода. Миграция ускоряется благодаря автоматизации и требует меньше ресурсов.

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

Переход на другую платформу. Активы переносятся в облако с небольшим обновлением. Например, с переходом на управляемую СУБД или с добавлением автоматического масштабирования. Используются преимущества контейнеров и виртуальных машин. Изменения вносятся в код приложений только при необходимости использования платформенных сервисов, таких как Amazon Elasticache, и передовых сервисов Amazon EC2 вроде автоматического масштабирования и Elastic Load Balancer. Оптимизируется базовая стоимость, не требуя таких ресурсов, как рефакторинг.

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

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

Оценка своих возможностей

При определении порядка миграции должны учитываться ее осуществимость и эффективность затрат:

  • Насколько значение данного приложения для бизнеса носит стратегический характер? Это приложение содействует получению дохода или оно поддерживает операции и потому должно иметь минимальную общую стоимость владения? Например, для розничного торговца сайт электронной коммерции является тем приложением, в которое следует вкладывать средства. А система отчетности сотрудников об отпусках для подразделения HR — это то, что может терпеть. Миграции часто ограничены по времени и средствам. Ресурсы, необходимые для смены платформы или рефакторинга, лучше направить на приложения первого рода;
  • Можно ли переместить в облако приложение, которое приходится терпеть? Если да, то лучшим вариантом является перенос. Если нет, следует поискать альтернативу в виде SaaS. Например, если отчеты об отпусках обрабатываются на IBM AS400, может быть лучше заменить приложение другим инструментом или сохранить его в своем ЦОДе и не тратить время разработчиков на его рефакторинг для облака;
  • Заслуживающие инвестиций приложения требуют тщательного анализа эффективности затрат. Проанализируйте затраты на разработку и учтите перерыв в ведении бизнеса, который может возникнуть из-за переписывания большого объема кода.
    Например, если приложение подходит для бессерверных вычислений с использованием модели AWS Lambda, а у разработчиков имеются время и ресурсы, рефакторинг будет правильным решением при условии, что выгоды перевешивают затраты. Однако большинство приложений с трудом поддаются рефакторингу. Обычно компании производят рефакторинг менее чем 10% своего портфеля;
  • Наконец, если рефакторинг невозможен, правильным выбором будет переход на другую платформу. Как правило, компании переносят на новые платформы 25-30% приложений. На команду DevOps возлагается задача без внесения больших изменений в код сделать возможным использование преимуществ облака. Например, таких как автоматическое масштабирование и самолечение. Скажем, можно перенести на другую платформу веб-сайт электронной коммерции, который создан в системе, несовместимой с бессерверными вычислениями.

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