О миграции корпоративных данных и инфраструктуры в публичное облако

Вот три простых причины, по которым предприятия начинают переход в облака:

Причина 1: Скорость и экономия затрат

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

Причина 2: Новые возможности, такие как восстановление после сбоев

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

Причина 3: Постоянно обновляемые новые технологии и услуги

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

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

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

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

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

• Потребности в конфиденциальности данных и соблюдении нормативных требований: нужно ли соблюдать конфиденциальность согласно требованиям государственных органов или медицинских организаций?
• Зависимость от поставщика: хотите «положить все яйца в одну корзину»?
• Стоимость: время/деньги. Сколько на самом деле потребуется времени, чтобы мигрировать данные с учетом потребности в изменении навыков и культуры вашей компании?

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

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

Номер 1: Перемещение

Перемещение (Rehosting) — это процесс миграции существующих физических и виртуальных серверов в публичное облако (Infrastructure as a Service (IaaS)) как есть (as is). Основное преимущество такого подхода заключается в том, что системы можно быстро перемещать без изменения их архитектуры. По этому пути часто идут компании идут в самом начале работы с облачными технологиями. При перемещении вы по сути относитесь к облаку как к еще одному ЦОДу, а это означает, что вы не получаете максимальную отдачу от доступных облачных услуг.

Рассмотрим веб-приложение в качестве простого примера. Представьте, что у вас есть ASP.NET приложение, работающее под Windows, и вы хотите перевести его в облако. Вы можете создать Windows VM, отвечающую требованиям к размеру, и развернуть приложение. После изменения DNS-записей вы практически готовы к работе. Такой перенос является простым способом перехода в облако. Однако это решение не является высокодоступным или масштабируемым и требует от вас настройки апдейтов ОС.

Номер 2: Смена платформы

Это процесс запуска приложений на управляемом наборе сервисов от вашего поставщика облачных услуг, также называемый платформа как услуга (PaaS). Использование PaaS означает, что разработчики могут повторно использовать фреймворки, языки и контейнеры.

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

Примером рефакторинга с использованием PaaS может быть взятие существующего приложения Ruby on Rails и его развертывание в Heroku или взятие существующего приложения Drupal и его модификация для запуска на Acquia Cloud или Pantheon. Опции PaaS позволят вам сконцентрироваться на приложении без необходимости иметь дело с операционной системой, лежащей в основе.

Номер 3: Ревизия

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

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

Номер 4: Пересборка

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

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

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

Номер 5: Замена

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

Это может быть отличным вариантом для минимизации количества сервисов и приложений, которыми необходимо управлять. Примером может быть замена локальной базы данных на управляемую опцию, такую как Cloud Datastore, Cosmos DB или Dynamo. Это может быть одним из самых простых способов поднять уровень SLA. Все эти сервисы известны своей масштабируемостью и доступностью. В отличие от этого, запуск базы данных самостоятельно и работа с репликацией данных и восстановлением может быть очень трудоемкой.

Промежуточный итог

Миграционные проекты любого масштаба требуют тщательного планирования.

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

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

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

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

• Приложение требует больше трафика, и становится трудно масштабировать ресурсы на лету для удовлетворения растущего спроса
• Нужно снизить эксплуатационные расходы при одновременном повышении эффективности ИТ-процессов
• Компании нуждаются в быстром внедрении и развертывании приложений; хотят больше сосредоточиться на развитии при одновременном снижении накладных расходов на инфраструктуру
• Компании хотят расширить свой бизнес географически, создание многорегиональной инфраструктуры со связанным с этим обслуживанием, затратами времени, человеческих ресурсов и усилий по контролю ошибок будет сложной задачей
• Поспевать за растущими потребностями в хранении данных становится все труднее и дороже
• Есть потребность в создании широко распределенной команды разработчиков. Облачные вычислительные среды позволяют удаленным сотрудникам получать доступ к приложениям и работать через Интернет
• Необходимо создать систему аварийного восстановления, но ее настройка для всего центра обработки данных может удвоить стоимость. Также потребуется сложный план аварийного восстановления. Облачные системы аварийного восстановления могут быть внедрены гораздо быстрее, они также позволяют лучше контролировать ресурсы
• Отслеживание и обновление основного серверного программного обеспечения — это трудоемкий, но важный процесс, требующий периодических, а иногда и немедленных обновлений. Облачный провайдер готов позаботиться об этом. С помощью облака аналогично решаются многие другие административные задачи, такие как резервное копирование баз данных, обновление программного обеспечения и периодическое обслуживание
• СapEx и OpEx: облачные вычисления переносят расходы на ИТ на модель оплаты по факту, что является привлекательным преимуществом, особенно для стартапов.

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

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

Если существующая инфраструктура удовлетворяет вашим потребностям, не требует большого объема обслуживания, масштабирования и доступности, и все ваши клиенты довольны, зачем связываться с облаками?

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

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

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

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

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

Время простоя. Это случается с каждым, но вам может не понравиться, что ваша доступность контролируется кем-то другим.

Теперь, когда вы решили попробовать облако, вам нужно выбрать нужную модель потребления ресурсов.

Самые распространенные модели:

• IaaS: Инфраструктура как услуга
• PaaS: Платформа как сервис
• SaaS: Программное обеспечение как услуга (например, Google G Suite, Office 365, Salesforce, NetSuite).

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

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

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

Вы выбрали модель потребления ресурсов, теперь пришло время определиться с типом облака.

Есть три основных варианта:

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

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

Как именно гибрид может работать?

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

Компания RightScale сообщила, что предприятия все чаще прибегают к стратегии использования нескольких облаков (84%), а 58% планируют использовать гибридные облака.

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

Сложность проектирования приложений

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

Сложность интеграции

Каждое приложение имеет свои точки интеграции, такие как платежные шлюзы, SMTP-серверы, веб-сервисы, внешние хранилища и компоненты от сторонних вендоров. Очень важно проанализировать, какое на них влияние окажет миграция в облако. Иногда вы будете испытывать неожиданные проблемы с подключением или аутентификацией, которые необходимо идентифицировать и решить заранее. Самой важной (и утомительной) задачей является определение всех этих точек интеграции. Поскольку старые приложения могут быть плохо задокументированы, а разработчики, знакомые со сквозными функциональными и нефункциональными деталями, могут оказаться недоступными, вам, возможно, придется просматривать каждый модуль вручную. Задача усложняется, если вы рассматриваете возможность миграции сотен приложений, работающих в настоящее время в вашем дата-центре.

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

Некоторые из более известных инструментов обнаружения активов включают BMC Atrium и HP DDMA. Cloudamize предоставляет инструмент, который может автоматически ищет приложения и машины, а также отображает зависимости приложений.

Операционная система хоста

Когда вы решили перейти в облако, важно знать, сможете ли вы разворачивать свои приложения на одной и той же ОС. Ваши приложения могут работать только на определенной ОС (или версии ОС). Если она несовместима с вашим поставщиком услуг облачных услуг, то вам нужно найти работающую замену ОС, другого поставщика или просто отказаться от всего проекта. Например, большинство провайдеров не предоставляют 32-разрядные варианты ОС, а у других могут возникнуть неожиданные требования к подписке. Лучше всего проводить свои исследования заранее.

База данных приложений

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

Большинство облачных провайдеров предлагают помощь в проведении миграции. Поэтому очень важно оценить эти предложения, прежде чем нажать кнопку «старт». Также существует множество сторонних производителей, предоставляющих услуги по миграции данных: Attunity CloudBeam, ATADATA ATAmotion, CloudEndure Live Migration и Racemi DynaCenter.

Сеть

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

Многие поставщики облачных услуг имеют калькуляторы цен, которые помогут вам оценить реальные расходы при переходе на облако в сравнении с вашими текущими расходами. Калькулятор позволяет вам сопоставить TCO (Total Cost of Ownership), чтобы вы могли решить, какой вариант лучше всего подойдет на основе профилей текущей рабочей нагрузки приложения.

Всегда отличная идея - создать небольшой proof of concept (POC) до того, как вы на самом деле переведете свою рабочую нагрузку в облако. Такие модели не решают всех возможных проблем, но дадут вам больше ясности и понимания трудностей, с которыми вы можете столкнуться. 

Некоторые из вещей, которые следует искать во время POC, включают в себя:

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

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