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

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

Как показывают результаты недавнего исследования, проведенного IHS Markit по заказу Fortinet, большинство компаний «откатились» вследствие того, что облачные приложения не показали ожидаемой доходности. 74% из 350 опрошенных CIO заявили, что осуществили обратную миграцию приложений, вернув их в собственную инфраструктуру. «Когда компании репатриируют рабочие нагрузки, это часто свидетельствует о том, что что-то пошло не так», — сказал вице-президент по ИТ консалтинговой компании Everest Group Югал Джоши. Облако далеко от идеала. По мнению экспертов, перемещение рабочих нагрузок в него может оказаться дорогостоящим и привести к деструктивным последствиям.

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

Облачная миграция приводит к проблемам

Высокий процент неудачных миграций не вызвал удивления у старшего вице-президента и ИТ-директора SilkRoad Technology Асифа Малика. Он сказал, что на прежнем месте работы уже сталкивался с подобной ситуацией. Так, его команда перенесла из ЦОДа компании на хостинг Microsoft Azure приложение для анализа данных. Расчет строился на том, что по мере необходимости его можно будет легко масштабировать и при этом уменьшить эксплуатационные расходы. «Мы думали, что противопоставляем капитальные затраты операционными, надеялись сэкономить много денег и избавиться от управления инфраструктурой, — рассказал Малик. — Но мы ошиблись».

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

Почему облачные миграции закачиваются неудачей

По словам Джоши, компании принимают решения о возврате софта в локальные среды постфактум, когда обнаруживают, что переход в облако привел к проблемам с латентностью, безопасностью и вызывает сложности с соблюдением требований регуляторов. Его наблюдения совпадают с результатами опроса IHS Markit: 52% вернули свои рабочие нагрузки в ЦОДы из-за проблем с производительностью или безопасностью, 21% в качестве основной преграды для работы в облаке указали регуляторные проблемы.

«То, что вынуждало предприятия переходить в облако, а затем возвращаться онпремис, как правило, было комбинацией из нескольких факторов», — сказал управляющий директор и директор по исследованиям в области новых технологий Deloitte Consulting Скот Бухгольц. Некоторые компании при работе с облачными службами сталкиваются с превышением затрат, тогда как другие разочарованы временем безотказной работы. В то же время третьи сталкиваются со сложностями, которые приводят к замедлению их систем. «Существуют крупномасштабные системы с особыми техническими требованиями, которые плохо работают в облаке (например, транзакционные базы данных), и есть приложения, которые обладают повышенными возможностями подключения или для их работы в облаке требуется применение большего, чем ранее предполагалось, числа корпоративных политик. Таким образом, когда вы пройдете через все хитросплетения и обеспечите безопасность, ваше приложение в облаке будет намного медленнее, чем вы думали», — добавил Бухгольц.

Как предотвратить проблемы с миграцией в облако

По словам Малика, совершенные им ошибки позволили ему лучше понять, какие методы лучше всего подходят для миграции. В частности, «облаку подходят не все приложения». Пример — приложение для анализа данных, которое показало свою неработоспособность в облаке. «Решение переместить приложение в облачное хранилище по методу „перетащить и сбросить“ было ошибочным: оно не было мультитенантным, гибким и оно не очень хорошо работало в виртуализированной среде», — пояснил он. Он также добавил, что приложение полагалось на данные, которые находились в ЦОДе, поэтому его облачная производительность оставляла желать лучшего.

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

Оценка приложения имеет решающее значение

Директор по инновациям Pitney Bowes Джеймс Фэйрвезер сказал, что его компания приступила к реализации цифровых инициатив около пяти лет назад. Было решено перенести в облако часть рабочих нагрузок, отдельных возможностей и сервисов.

Чтобы сгладить переход, компания провела тщательную оценку приложений, выявив, какие из них при переносе в облако не потеряют работоспособность, а какие придется модернизировать. «Миграцию рабочих нагрузок нужно тщательно планировать, что мы и сделали», — сказал он, добавив, что для этого нужно проверить их работу в целевой среде на предмет безопасности, провести тестирование кода и обеспечить ряд других мер. Чтобы обеспечить успешную миграцию, Pitney Bowes также закупила инструменты автоматизации и ПО для управления API производства Apigee.