Найти в Дзене
DevOps Qazaqstan

3 пути миграции в облако: инструкция для DevOps

В прошлый раз мы говорили о том, что нужно учитывать при миграции в облако. Сегодня расскажем о конкретных вариантах. Из множества возможных путей к миграции в облако наиболее известны варианты облачной миграции Gartner и AWS3. Но с большим количеством рекомендаций из множества источников, выбор стал сложным и запутанным. Некоторые советы от одних лидеров мнений вступают в противоречие с другими. Но мы в CORE 24/7 любим, чтобы все было просто. У каждого пути есть свои плюсы и минусы, и вполне вероятно, что вы будете использовать все три в той или иной степени для миграции разных приложений. 1. Lift and shift Это то, что Gartner и AWS называют rehosting. Это самый быстрый и простой путь к облаку, подразумевающий массовую репликацию инфраструктуры на платформу as-a-service framework. Правда Lift и shift не в состоянии раскрыть все возможности, которые предлагаются в рамках современных высокофункциональных гипермасштабируемых облачных платформ. Более того, пока вы не проведете оптимизацию
Оглавление

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

Из множества возможных путей к миграции в облако наиболее известны варианты облачной миграции Gartner и AWS3. Но с большим количеством рекомендаций из множества источников, выбор стал сложным и запутанным. Некоторые советы от одних лидеров мнений вступают в противоречие с другими.

Но мы в CORE 24/7 любим, чтобы все было просто. У каждого пути есть свои плюсы и минусы, и вполне вероятно, что вы будете использовать все три в той или иной степени для миграции разных приложений.

1. Lift and shift

Это то, что Gartner и AWS называют rehosting. Это самый быстрый и простой путь к облаку, подразумевающий массовую репликацию инфраструктуры на платформу as-a-service framework.

Правда Lift и shift не в состоянии раскрыть все возможности, которые предлагаются в рамках современных высокофункциональных гипермасштабируемых облачных платформ. Более того, пока вы не проведете оптимизацию, общие затраты почти наверняка будут высокие. Поэтому некоторые люди категорически против подхода lift and shift. Их позиция «не откладывай на завтра то, что ты можешь сделать сегодня» имеет право на жизнь. Но факт в том, что иногда это единственный жизнеспособный вариант. Определенно, бывают моменты, когда легче модернизировать приложения после миграции, а не во время.

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

2. Evolve

Это промежуточное звено между Lift и shift и полной перестройкой. Такой быстрый путь к частичной модернизации, Gartner и AWS называют эти подходы «рефакторингом». Методы, основанные на инфраструктуре, не предполагают изменений в архитектуре или пользовательских функциях, но часто требуют активного участия разработчика, чтобы все работало как надо.

Приложения могут быть контейнеризированы с помощью Docker или Kubernetes, или может понадобится переход на PaaS, такие как Azure Web Apps или AWS Elastic Beanstalk. Подход «всё как код» пригодится для повторного развертывания приложений в недавно определенных неизменяемых инфраструктурах виртуальных машин с наборами масштабирования и расширенными возможностями восстановления.

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

повторно использоваться в более эффективной облачной среде, и при этом вам не нужно резко переквалифицировать команды разработчиков, внедрить новые языки или фреймворки. Однако первоначальные расходы выше, чем при Lift и shift. Более того, есть риск отсутствия функций в PaaS и потенциальной привязки к поставщику при использовании расширенных функций.

Маршрут Evolve охватывает значительный спектр вариантов, но тут стоит быть осторожным — не превращать проект в незапланированную перепланировку.

3. Go native

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

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

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

Если вы сомневаетесь в собственных силах и хотите довериться профессионалам, то приходите к нам за помощью — мы создаём высокопроизводительные системы, повышаем стабильность существующего программного обеспечения, отслеживаем бизнес-метрики и улучшаем системы мониторинга, а также обеспечиваем техническую поддержку в режиме 24/7