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

Миграция в облако — больше, чем реплатформинг

Оглавление

В недавнем опросе Forbes 53% респондентов выразили уверенность, что 95% рабочей нагрузки предприятия будет в облаке через пять лет или раньше.

Если и ваша миграция в облако не за горами, важно подумать о том, как её правильно осуществить. Это не просто техническое переоснащение, ведь нужно учесть много вещей:

  • бизнес-цели и бюджет;
  • внутреннюю культуру и политику;
  • IT-инфраструктуру и возможности команды.

Всё это влияет на темп, в котором вы должны двигаться, и методы, которые вы должны использовать.

4 основных этапа внедрения облачных технологий

Цель миграции — заложить основы для постоянной модернизации: как технической, так и организационной.

1. Opportunistic

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

Команды не упускают возможности и, как правило, стараются использовать современные способы работы. Например, внедряют инфраструктуру в виде кода.

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

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

2. Cloud-first

Как только у вас появится несколько сервисов, работающих в облаке, доверие к нему и ожидания от него возрастут. Вы можете решить, что настало время разворачивать все проекты в облаке как нечто само собой разумеющееся. Это заявление знаменует начало этапа Cloud-first.

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

Создание Cloud Center of Excellence (CCoE) для управления внедрением облачных технологий — лучшее решение, хоть и между лидерами отрасли до сих пор существуют разногласия по поводу того, должна ли это быть чисто архитектурная функция или что-то более практическое или междисциплинарное (с участием владельцев бизнеса, финансов, соблюдения требований и т.д.). Как бы то ни было, данные свидетельствуют о том, что любая структура лучше, чем отсутствие CCoE. Оцените, какие её варианты наиболее эффективны в вашем бизнесе.

Модель CCoE требует совместной работы специалистов в следующих областях:

  • Внедрение облака (архитекторы решений)
  • Облачная стратегия (руководители программ и проектов)
  • Система управления облаком
  • Облачная платформа
  • Автоматизация работы с облаком

Помимо внедрения модели не забывайте инвестировать и в обучение своих людей. Заменить всех сотрудников нереально. Это работа в долгую, ведь ваша стратегия Cloud-first должна быть увязана с четкими планами развития навыков и управления изменениями. А изменений будет много. И чем больше вы готовы инвестировать в карьеру людей, тем больше доверия от команды. Оно вам пригодится.

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

3. All-in

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

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

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

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

4. Cloud-native

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

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

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

Как только ваши первые системы будут размещены в облаке, внимательно изучите потребности бизнеса, чтобы понять, где полностью облачные сервисы могут обеспечить лучшие показатели затрат и производительности. Здесь в игру вступают некоторые из более сложных процессов, таких как непрерывная интеграция и непрерывная доставка (CI/CD), а также микросервисы.

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

Гигантская задача массовой миграции

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

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

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

Сведите к минимуму миграционный пузырь

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

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

Планы ничего не стоят, но планирование необходимо

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

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

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

С чего начать миграцию?

Многие организации с трудом решают этот вопрос, но совет здесь относительно прост. Начните с чего-то значительного, чтобы получить выгоду, но достаточно простого, чтобы сделать это быстро.

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

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

Не все приложения подходят для миграции

Сложно понять разумность переноса устаревшего пакета CRM, когда вы могли бы воспользоваться Salesforce, Dynamics или другим аналогичным SaaS. Некоторые старые мэйнфреймы просто невозможно перенести, а перестройка на данном этапе может оказаться нежизнеспособной. Другие сервисы и вовсе придётся оставить локальными (по крайней мере, в начале).

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