Миграция в облако требует от компаний стратегического мышления. Прежде чем приступать к миграции, компаниям следует разработать ключевые показатели эффективности (KPI), оценить потенциальные расходы. Эти и другие советы дает на портале InformationWeek руководитель отдела разработки продуктов Orum.io Мадхури Сеша Сарма.

По данным Hosting Tribunal, 94% компаний присутствуют в облаках, но только 20% прошли облачную трансформацию. Отчасти это объясняется тем, что она является дорогостоящей инициативой, в результате которой тратятся миллионы долларов и тысячи человеко-часов. Однако без некоторых из этих затрат можно обойтись, особенно если избежать трех распространенных ошибок: простого переноса локальных приложений в облако без реконфигурации и оптимизации (lift and shift), недооценки необходимости управления облаком и убеждения, что переход в облако — это инициатива по снижению затрат.

Простой перенос

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

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

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

Обслуживание облака

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

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

Считайтесь с потенциальными расходами

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

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

Что предпринять для успеха миграции

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