Во время пандемии многие компании ринулись в облако, потому что этого требовали обстоятельства. Дэвид Линтикум, директор по стратегии облачных вычислений Deloitte Consulting, дает на портале eWeek советы, как правильно осуществить миграцию в облако.

По данным Fortune Business Insights, мировой рынок облачных вычислений достиг 250,04 млрд. долл. в 2021 г. и с прогнозируемым среднегодовым темпом роста 17,9% достигнет к 2028 г. 791,48 млрд. долл. Статистика разнится, но большинство предприятий перевели от 20 до 40% своих систем в облако или создали новые системы в облаке для обработки 20-40% рабочих нагрузок.

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

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

Проблемы c надежностью, которые возникают при миграции в облако

Допустим, вы владеете привлекательным, хорошо спроектированным спортивным автомобилем, но его двигатель настолько ненадежен, что вы никогда не знаете, когда и где он может сломаться и сколько будет стоить ремонт. Именно такая потребительская неуверенность возникла в 1970-х, когда производитель шаров для боулинга стал владельцем компании Harley-Davidson.

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

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

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

Как добиться успеха в CloudOps

Как говорится в отчете Aptum «Bridging the Cloud Transformation Gap», 62% респондентов называют сложность и обилие выбора препятствием при планировании облачной трансформации. Во многом это связано с растущим использованием мультиоблаков. Принимая решение о выборе той или иной платформы, пользователи всегда хотят, чтобы она была «лучшей в своем роде». Это приводит к появлению огромного количества вариантов облачных услуг. Выбор включает в себя различные системы безопасности и/или управления, БД, машинное обучение, аналитику и другие приложения/услуги, которые легко предоставляются поставщиками публичных облаков.

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

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

Облачная и необлачная гетерогенность: оцените компромисс. Вы должны понимать стоимость, риск и ROI при развертывании 5 различных систем безопасности, 20 платформ разработки и 30 БД на трех разных платформах публичных облаков. Те, кто выбирает лучшие в своем классе облачные продукты или услуги, редко задумываются об очевидной стоимости дополнительной сложности или о дополнительных рисках и затратах, связанных с этой сложностью. Ключом к успеху является внедрение общих сервисов, охватывающих все облака и платформы. Нужно понимать, что безопасность, управление, MDM, управление операциями, тестирование и другие услуги, которые предлагаются разными платформами, могут быть не самыми лучшими. Однако текущая ROI обычно оправдывает преимущества использования одной и той же технологии для приложений, данных и платформ.

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

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

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

Нужно уметь (и развивать соответствующие навыки и умения у сотрудников) рассматривать проекты по миграции в облако задолго до их начала. Каковы требования к эксплуатации и обслуживанию затронутых данных и приложений через 6 месяцев после завершения проекта миграции? Если у вас в разработке находится проект миграции и вы впервые задаете себе этот вопрос, вам необходимо пересмотреть сроки реализации проекта.