По данным ResearchAndMarkets, объем мирового рынка услуг миграции в облако увеличится с $19,28 млрд в 2026 году до $143,7 млрд в 2035-м, то есть ежегодно будет расти на 22,24% в течение прогнозируемого периода. Это результат того, что бизнес все чаще осознает, насколько важна для него масштабируемость, гибкость и экономическая эффективность, которую как раз дает перенос ИТ-нагрузок в облако. И сегодня вопрос уже не в том, нужна ли миграция, какую архитектуру выбрать с учетом десятка важных факторов. Несмотря на массовость миграция инфраструктуры в облако все еще вызывает много вопросов. Дальше мы рассказываем о том, как к ней подготовиться, выбрать поставщика услуг и какие приложения лучше всего подходят для размещения в облаке.
- Публичные и частные облака для бизнеса
- Миграция бизнес-приложений в облако: основные аспекты
- Выбор корпоративных приложений для миграции в облако
- Миграция корпоративных приложений в публичное облако
- Публичное или частное облако?
- Критерии оценки приложений
- Профилирование приложений
- Планирование миграции
- Почему важно доверить реализацию проекта профессионалам
- Главное о переносе инфраструктуры в облако
- FAQ
Публичные и частные облака для бизнеса
Облако представляет собой модель услуг, при которой провайдер на своей площадке выделяет в пользование клиентов IT-ресурсы на базе собственного оборудования, а клиенты получают к этим ресурсам доступ по сети. Публичное облако (Public Cloud), под которым мы также понимаем IaaS или «инфраструктуру как сервис», позволяет использовать серверы, хранилища данных и сетевые услуги.
Особенности публичного облака для бизнеса:
- гибкая модель оплаты: только за выделенные провайдером ресурсы;
- эластичность: можно быстро получать дополнительные ресурсы по запросу;
- оптимизация начальных затрат: нулевые или минимальные вложения на развертывание IT-инфраструктуры в облаке;
- отказоустойчивость и высокая доступность данных: в любой момент сервисы доступны из любой точки мира при наличии стабильного интернет-подключения.
Компании, которые выдвигают повышенные требования к безопасности, желают монопольно распоряжаться выделенными провайдером IT-ресурсами или нуждаются в индивидуальной конфигурации этих ресурсов, предпочитают частное облако — Private Cloud. В этом случае они получают доступ не только к виртуальным серверам и хранилищу, но также к аппаратной части и гипервизору. В частном облаке вы можете самостоятельно заниматься администрированием и получить больше инструментов для контроля и управления, чем в Public Cloud.
Независимо от выбора модели облачных услуг вам необходимо решить, какие именно бизнес-приложения вы перенесете в облако и как реализуете это на практике. Выбранная стратегия и перечень сервисов, подлежащих миграции, повлияют не только на сложность реализации проекта и конечный результат, но на удовлетворенность пользователей — ваших клиентов.
Предлагаем рассмотреть организационные и технические аспекты миграции бизнес-приложений в облако.
Миграция бизнес-приложений в облако: основные аспекты
Некоторые корпоративные сервисы сталкиваются со сложностью масштабирования или недостаточно высокой отказоустойчивостью. Хотя облако само по себе не позволяет преодолеть внутренние ограничения на расширение или повысить доступность приложений, миграция инфраструктуры в облако может принести вашей компании ощутимые финансовые выгоды, особенно если ранее IT-инфраструктура была развернута на локальном устаревшем оборудовании.
Миграция бизнес-сервисов представляет собой процесс их повторного развертывания на новой платформе. При этом если миграция выполняется между совместимыми платформами, вторичная компиляция приложений не потребуется.
В контексте облачных вычислений новая платформа будет представлять собой площадку — дата-центр, который построили и обслуживают профессионалы, — полностью подготовленную для размещения клиентских приложений. Ваша задача заключается в том, чтобы выбрать надежного провайдера: такого, который предлагает разместить IT-инфраструктуру в сертифицированном дата-центре, имеет большую IT-экспертизу, хорошую репутацию и может оказать профессиональную помощь с миграцией и последующим администрированием.
Откуда можно мигрировать бизнес-приложения:
- отдельно стоящий сервер (малый и средний бизнес);
- построенный клиентом дата-центр (крупный бизнес);
- арендованный клиентом сервер (локально или в дата-центре);
- сервер, размещенный в локально развернутом облаке;
- SaaS-сервис (импорт или перенос данных). Куда именно в облако можно мигрировать бизнес-приложения:
- в общедоступное облако;
- в частное облако;
- в гибридную среду: комбинация частного и общедоступного облака.
Возможные частные случаи переноса данных. Например, миграция вида P2V (Physical–to–Virtual), когда физический сервер полностью переносится в виртуальную среду, включая операционную систему, приложения и их данные. Существуют специальные программные решения (конвертеры), позволяющие автоматизировать процесс такой миграции и сократить количество ошибок, которые могут возникнуть при этом. Если приложение размещалось на виртуальном сервере, его достаточно смигрировать/конвертировать.
Выбор корпоративных приложений для миграции в облако
Часто отправной точкой для переезда становится необходимость обновить локальную IT-инфраструктуру. Цикл замены физического оборудования влечет за собой заморозку капиталов (CapEx), длительные согласования бюджетов и месяцы ожидания поставок.
Облачные модели исключают эти капитальные затраты, переводя IT-бюджет в формат гибких операционных расходов (OpEx). Вместо недель ожидания новых серверов вы получаете масштабируемые ресурсы мгновенно. Кроме того, перенос в облако позволяет:
- Справиться со скачкообразным спросом: ресурсы выделяются по клику или автоматически, а вы платите только за фактическое потребление (Pay-as-you-go).
- Повысить отказоустойчивость: встроенные балансировщики нагрузки и кластеризация распределяют трафик, защищая сервисы от падений.
- Делегировать управление: провайдер забирает на себя обслуживание физического оборудования и базовую маршрутизацию.
Однако не все сервисы получают равную выгоду от переезда. Оценивать приложения для миграции следует на основе их архитектуры и характера нагрузки. Чтобы структурировать этот процесс, используйте базовую матрицу распределения рабочих нагрузок:
| Профиль приложения | Характер нагрузки | Оптимальная среда развертывания | Главная бизнес-выгода от миграции |
|---|---|---|---|
| E-commerce, веб-порталы, клиентские сервисы | Динамичная, скачкообразная (сезонность, акции) | Public Cloud | Мгновенное масштабирование в пиковые часы и снижение затрат во время спада. |
| Среды разработки и тестирования (Dev/Test) | Временная, непредсказуемая | Public Cloud | Ускорение Time-to-Market: быстрое развертывание сред и их удаление за ненадобностью. |
| ERP, CRM, тяжелые базы данных | Стабильная ресурсоемкая нагрузка | Private Cloud / Bare Metal | Изолированная среда, гарантированное количество IOPS и прогнозируемый ежемесячный бюджет. |
| Legacy-системы и узкоспециализированное ПО | Статичная | On-premise / Гибрид | Минимизация рисков: приложения со сложными аппаратными зависимостями безопаснее оставить на локальном железе. |
Миграция корпоративных приложений в публичное облако
После определения списка приложений-кандидатов на перенос в облако необходимо детально изучить технические и организационные аспекты миграции. Сделаем это на примере Public Cloud, которое поставщики услуг предлагают в виде продукта с названием IaaS (Infrastructure as a Service).
Первое, что необходимо сделать — это оценить возможность переноса выбранных приложений с учетом их требований к техническим параметрам оборудования и перечня поддерживаемых ОС. Если в новой конфигурации вычислительных ресурсов используется несовместимое с вашим сервисом оборудование, может потребоваться перекомпиляция приложения.
Рассказываем, что следует предусмотреть и изучить до миграции IT-инфраструктуры в публичное облако.
Договор и SLA
Необходимо понять, какой уровень доступности гарантирует поставщик услуг и какую финансовую ответственность несет в случае невыполнения обязательств. Здесь важно различать доступность IT-инфраструктуры (серверы, системы хранения данных) от доступности сетевой инфраструктуры и доступности сервисов самого дата-центра, которая обязательно подтверждается сертификатами. Если для ЦОД, расположенных в США, оценить надежность можно по уровню Tier (классификация Uptime Institute), то качество работы и надежность европейских дата-центров обычно подтверждают сразу несколько сертификатов: ISO/IEC 27001:2005, ISAE3402 / SSAE16, ISO 9001: 2008, ISO/IEC 27001:2005 и другие.
На что еще необходимо обратить внимание в договоре и SLA:
- какие услуги администрирования можно запросить у провайдера;
- на каких условиях оказывается поддержка аппаратного обеспечения, администрирование виртуальных машин, ОС и отдельных приложений;
- какие уровни обслуживания действуют для конкретных продуктов и от чего они зависят (варианты: от локации дата-центра, типа дисков и виртуальных машин);
- на какие случаи не распространяется гарантия поставщика услуг;
- процедура выплаты компенсации и ее размеры в случае нарушения SLA.
Работа БД на новой платформе
При миграции данных в Public Cloud приложения могут использовать серверы базы данных, также развернутые в облаке. Тогда провайдер должен предоставить возможность репликации или переноса хранилища того типа, который необходим для работы сервера баз данных.
Долгосрочные затраты
В большинстве случаев развертывание приложений в публичном облаке позволяет бизнесу оптимизировать затраты на IT-инфраструктуру. Это возможно за счет перехода от модели фактического владения IT-инфраструктуры (капитальные затраты, CapEx) к оплате необходимых ресурсов по подписке (операционные затраты, OpEx). Однако для приложений, которые должны быть доступны постоянно и требуют больших объемов вычислительных ресурсов, долгосрочная стоимость владения в публичном облаке может оказаться выше, чем стоимость развертывания и дальнейшей поддержки частного облака.
Управление безопасностью и надежностью хранения
При развертывании IT-инфраструктуры в Public Cloud виртуальные машины, находящиеся в аренде у разных клиентов, могут размещаться на единой физической инфраструктуре. Это обязывает вас тщательно подходить к оценке того, насколько ответственно провайдер решает задачу полной изоляции виртуальных машин друг от друга. Для этого важно, чтобы поставщик услуг работал открыто и, соответственно, разрешал проводить аудит политик безопасности на соответствие требованиям, а также выкладывал результаты аудита в общий доступ.
Некоторые провайдеры предлагают дополнительные услуги для повышения надежности и отказоустойчивости клиентской IT-инфраструктуры. Примерами таких услуг могут быть BaaS и DRaaS.
| BaaS («бэкап как сервис») | DRaaS («аварийное восстановление как сервис») |
| Позволяет комплексно управлять созданием, хранением и восстановлением данных из резервных копий. Провайдер предоставляет подходящее по объему хранилище на базе своего дата-центра, а также специализированное ПО, которое позволяет в значительной степени автоматизировать работу с бэкапами и дополнительно обезопасить данные от случайного или преднамеренного удаления. Это может произойти в результате поломки или изъятия оборудования, кибератак, пожаров и других стихийных бедствий на площадке клиента, а также человеческого фактора. | Позволяет в сжатые сроки и максимально эффективно восстанавливать IT-инфраструктуру после серьезного сбоя из копии, которая хранится в облачном репозитории на стороне провайдера. Вы получаете ПО для синхронизации данных, а также помощь в подготовке и реализации плана аварийного восстановления. |
Принцип работы сервиса BaaS:
Масштабируемость
Комфортнее всего в облаке бизнес-сервисам, поддерживающим горизонтальное масштабирование. Динамическое выделение вычислительных ресурсов идеально подходит для многоуровневых приложений с функцией балансировки нагрузки. Вам необходимо ознакомиться с положениями провайдера, в которых он описывает порядок такого масштабирования и предотвращения конфликтных ситуаций при превышении допустимого лимита ресурсов.
Публичное или частное облако?
После оценки потребности в ресурсах, совместимости платформ, возможности масштабирования и других аспектов миграции в публичное облако может возникнуть вопрос о целесообразности использования более сложного решения корпоративного уровня — частного облака. Оно позволяет задействовать больше инструментов безопасности, соответствовать специфическим требованиям к аппаратной платформе и в ряде случаев оказывается более экономически выгодным в долгосрочной перспективе.
Выбирая между публичным и частным облаком, следует детально изучить требования к защите данных, физической архитектуре, объемы трафика и все то, что также может влиять на производительность и работоспособность бизнес-приложений.
Возможности кастомизации
Под индивидуальные требования клиента и его бизнес-приложений можно построить только частное облако. В публичном вы получаете пул необходимых ресурсов с конкретными характеристиками, которые нельзя кастомизировать под конкретные задачи. В частном облаке, наоборот, можно выбрать желаемое количество процессоров с определенными параметрами (частота, поколение, производитель), объем и другие характеристики оперативной памяти, размеры хранилища и получить остальные компоненты свои задачи — например, конкретные модели видеокарт.
Объемы потребляемых ресурсов
В большинстве случаев нерационально переносить в публичное облако нагрузки, которые генерируют интенсивный сетевой трафик из-за возможного влияния на них «соседей». Аналогичная ситуация с другими вычислительными ресурсами — процессорной мощностью и дисковыми накопителями. Таким образом, высоконагруженные, требовательные к качеству сервиса виртуальные машины рекомендуется размещать в частном облаке.
Управление данными
Отдельные бизнес-приложения регулярно обмениваются данными с локальным хранилищем на стороне клиента или со сторонними ресурсами. При оценке возможности миграции все подобные взаимосвязи должны быть проанализированы и сохранены либо же архитектура приложения должна быть перестроена с учетом новых требований облачной IT-инфраструктуры.
Интеграция с устаревшими приложениями
Некоторые современные бизнес-приложения до сих пор работают с устаревшим ПО, что может вызвать проблемы в процессе миграции в облако. Если эти зависимости нельзя адаптировать для работы в облачной IT-инфраструктуре, стоит рассмотреть возможность миграции таких приложений в Private Cloud.
Масштабирование
Публичное облако масштабируется практически мгновенно — с момента отправки запроса до фактического выделения дополнительных ресурсов может пройти меньше часа. Частное облако в этом отношении менее гибкое: на заказ, поставку и введение в эксплуатацию дополнительных аппаратных ресурсов может потребоваться 2-3 недели. Но можно сработать на опережение: спланировать масштабирование и заблаговременно запросить дополнительные ресурсы у провайдера.
Стоимость владения
В модели IaaS до определенной конфигурации размеры регулярных платежей при сопоставимых объемах ресурсов будут ниже, чем у Private Cloud. С небольшим количеством используемых ресурсов у последнего будет выше совокупная стоимость владения за счет появления инсталляционного платежа. Если IT-инфраструктура достигла таких размеров, что ее целесообразно выносить в частное облако, размер ежемесячного платежа в большинстве случаев будет ниже, чем при оплате аналогичного объема ресурсов в публичном облаке.
Соответствие специфическим требованиям
В IaaS вы можете устанавливать ОС и приложения, в то время как в Private Cloud у вас будет прямой доступ к аппаратной части IT-инфраструктуры и гипервизору. Это важно, если вы планируете получить больше инструментов для контроля и управления, а также самостоятельно заниматься администрированием, чтобы оптимизировать инфраструктуру под конкретные бизнес-задачи.
Критерии оценки приложений
После выбора облачной модели и сервисов необходимо убедиться в отсутствии технических ограничений на миграцию и начать подготовку к переносу бизнес-приложений.
Архитектура
От архитектуры напрямую зависит то, подходит ли приложение для переноса в облако и каким образом будет осуществляться миграция. Разбираем, как разные типы архитектуры влияют на миграцию приложений в облако.
Приложения с многоуровневой архитектурой
Многие бизнес-приложения создаются с использованием нескольких уровней, что позволяет отделить основные модули от дополнительных функций. Так выглядит архитектура в трехуровневом приложении:
- уровень управления данными, который включает реляционные и другие компоненты баз данных;
- уровень бизнес-логики, который использует платформу приложений или контейнеры (Java EE/Microsoft.NET);
- уровень представления, отвечающий за взаимодействие с пользовательскими интерфейсами или другими внешними системами.
Приложения с многоуровневой архитектурой можно переносить целиком или помодульно внутри каждого уровня. В любом случае, каждый из них, как и компоненты внутри уровней, необходимо оценивать отдельно, когда речь идет о переносе в облако. Также разные уровни приложений могут выдвигать различные требования к безопасности.
Вертикально- и горизонтально-масштабируемые приложения
Вертикально-масштабируемую (scaling up) архитектуру имеют приложения, которые могут извлекать пользу из выделения дополнительных ресурсов (преимущественно процессорной мощности и памяти) на одном сервере или узле.
Горизонтально-масштабируемую (scaling out) архитектуру имеют приложения, которые могут извлекать пользу при увеличении количества серверов или узлов. Соответственно, когда нагрузка увеличится, то нужно развернуть дополнительные узлы, а когда потребность в ресурсах снизится, неиспользованные серверы/узлы можно будет отключить. Такие приложения появились позже вертикально-масштабируемых, а период их активного распространения связан с массовым переходом на архитектуру х86.
Географическая доступность
География пользователей бизнес-сервисов бывает довольно широкой или, наоборот, к приложению могут обращаться только из одного региона. Это также необходимо учесть до миграции в облако. Чтобы быть ближе к своим пользователям, крупный бизнес может разместить приложения в нескольких дата-центрах, расположенных в регионах с наибольшей интенсивностью запросов. Возможен и другой вариант, когда отдельные приложения нужно будет целенаправленно сделать недоступными в некоторых локациях по соображениям безопасности или другим причинам. Таким образом, при выборе облака важно убедиться, что вы можете контролировать, оптимизировать и отслеживать их локацию и удаленность от конечных пользователей.
Профилирование приложений
Процедура профилирования позволяет получить реальную статистику об использовании приложения до миграции и оценить реальные масштабы развертывания. Данные необходимо собирать в течение 10-15 дней подряд, чтобы зафиксировать все ежедневные и еженедельные отклонения от обычной нагрузки.
Вам предстоит собрать данные об использовании мощности процессора, памяти, хранилища, пропускной способности, количестве запросов и пользователей сервиса. На уровне узла эти данные можно использовать для анализа количества и конфигурации виртуальных машин, которые понадобятся в облаке.
Дополнительно к сбору статистику важно выполнить профилирование действий пользователей: оценить количество одновременно подключенных клиентов, скорость выполнения запросов и транзакций, длительность задержек. Эта информация пригодится для тестирования работы приложения в облаке и выбора оптимальной конфигурации облачных ресурсов на основе результатов теста, а также прогнозирования затрат на облачную IT-инфраструктуру.
Планирование миграции
Последним этапом будет разработка рабочего плана и непосредственно сама миграция данных в облако. Сложность его реализации напрямую зависит от типа приложений и требований к непрерывности их выполнения. Если даже минимальное время простоя критично для бизнеса, желательно разбить процесс миграции на несколько этапов — так, чтобы на любом из них приложения оставались доступными. Перенос в облако первой части сервисов будет тестовым. Используя заранее подготовленный план тестирования и автоматические тесты, можно смоделировать действия различных типов пользователей и нагрузок на приложение. По результатам станет понятно, сколько облачных ресурсов вам необходимо запросить у провайдера.
Почему важно доверить реализацию проекта профессионалам
Анализ, выбор оптимальной модели облака, разработка плана миграции и поэтапный перенос приложений в облако могут оказаться сложной задачи для компании, в которой IT не является профильным направлением. Тогда реализацию данного проекта следует доверить профессионалам, которые накопили большую экспертизу и опыт в задачах подобной вашей, а также понимают, как именно приложения взаимодействуют друг с другом, внешними ресурсами и базовой IT-инфраструктурой.
Chief Operating Officer Colobridge, Андрей Михайленко:
С 2010 года команда сертифицированных специалистов Colobridge накопила большой практический опыт в вопросах миграции в облако и не останавливается на достигнутом: сотрудники регулярно повышают компетенции и актуализируют знания. Они выполнят комплекс работ по переносу IT-инфраструктуры и данных в публичное или частное облако, а также обеспечат круглосуточную поддержку на нескольких языках, включая украинский и русский.
Главное о переносе инфраструктуры в облако
- Переезд в облако избавляет компанию от крупных капитальных затрат на покупку и обновление серверов.
- Публичное облако дает мгновенное масштабирование, а частное — полный аппаратный контроль и изоляцию.
- Перед миграцией обязательно проверяется техническая совместимость приложений с оборудованием провайдера.
- Гарантии доступности инфраструктуры и финансовая ответственность провайдера жестко фиксируются в договоре и SLA.
- Надежная защита данных обеспечивается подключением дополнительных сервисов: облачных бэкапов (BaaS) и аварийного восстановления (DRaaS).
- Максимальную эффективность в облаке демонстрируют приложения, поддерживающие горизонтальное масштабирование.
- Для точного расчета необходимых ресурсов статистика нагрузок (профилирование) собирается непрерывно в течение 10–15 дней.
- Поэтапный перенос сервисов командой провайдера сводит к нулю риск критических простоев для бизнеса.
Не рискуйте работоспособностью сервисов при переезде. Доверьте миграцию инфраструктуры в облако сертифицированным инженерам Colobridge — мы проанализируем архитектуру, подберем оптимальную облачную модель и перенесем ваши данные без остановки бизнес-процессов.
FAQ
Сначала необходимо провести аудит текущей ИТ-среды и профилирование нагрузок в течение 10–15 дней для оценки требуемых ресурсов. После этого разрабатывается план переноса сервисов, выбирается провайдер и осуществляется поэтапный перенос инфраструктуры в облако с обязательным промежуточным тестированием.
Главным образом бюджет зависит от объема данных, выбранной модели (публичное или частное облако) и архитектуры приложений, которым может потребоваться перекомпиляция. Однако в долгосрочной перспективе стоимость миграции в облако окупается: вы избавляетесь от капитальных затрат на покупку серверов и переходите на гибкую модель операционных платежей.
Надежный провайдер гарантирует, что безопасность облачных решений поддерживается на уровне физической и сетевой защиты сертифицированных дата-центров (например, ISO 27001), а также обеспечивает строгую изоляцию виртуальных машин. Дополнительная защита данных в облаке реализуется с помощью сервисов регулярного резервного копирования (BaaS) и аварийного восстановления (DRaaS).
Самые частые ошибки миграции в облако — это перенос сервисов без предварительного сбора статистики нагрузок и отсутствие плана отката (Rollback) на случай сбоев. Чтобы избежать критических простоев бизнеса, лучше запросить профессиональную помощь с миграцией в облако у сертифицированных инженеров провайдера, которые возьмут на себя весь процесс переноса.
