Як спланувати міграцію бізнес-застосунків у хмару

За даними ResearchAndMarkets, обсяг світового ринку послуг міграції в хмару збільшиться з $19,28 млрд 2026 року до $143,7 млрд 2035-го, тобто щороку зростатиме на 22,24% протягом прогнозованого періоду. Це результат того, що бізнес все частіше усвідомлює, наскільки важлива для нього масштабованість, гнучкість та економічна ефективність, яку якраз дає перенесення ІТ-навантажень у хмару. І сьогодні питання вже не в тому, чи потрібна міграція, яку архітектуру вибрати з урахуванням десятка важливих факторів.

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

• Публічні та приватні хмари для бізнесу
• Міграція бізнес-застосунків у хмару: основні аспекти
• Вибір корпоративних програм для міграції в хмару
• Міграція корпоративних застосунків до публічної хмари
  • Договір та SLA
  • Робота БД на новій платформі
  • Довгострокові витрати
  • Безпека хмарних рішень на надійність зберігання
  • Масштабованість
• Публічна чи приватна хмара?
  • Можливості кастомізації
  • Обсяги споживаних ресурсів
  • Керування даними
  • Інтеграція із застарілими застосунками
  • Масштабування
  • Вартість володіння
  • Відповідність специфічним вимогам
• Критерії оцінки застосунків
  • Архітектура
  • Застосунки з багаторівневою архітектурою
  • Вертикально- і горизонтально-масштабовані застосунки
  • Географічна доступність
• Профілювання застосунків
• Планування міграції
• Чому важливо довірити реалізацію проєкту професіоналам
• Головне про міграцію інфраструктури у хмару
• FAQ

Публічні та приватні хмари для бізнесу

Хмара являє собою модель послуг, в якій провайдер на своєму майданчику виділяє у користування клієнтів IT-ресурси на базі власного обладнання, а клієнти отримують до цих ресурсів доступ через мережу. Публічна хмара (Public Cloud), під якою ми також розуміємо IaaS або «інфраструктуру як сервіс», дозволяє використовувати сервери, сховища даних та мережеві послуги.

Особливості публічної хмари для бізнесу:

• гнучка модель оплати: лише за виділені провайдером ресурси;
• еластичність: можна швидко отримувати додаткові ресурси за запитом;
• оптимізація початкових витрат: нульові або мінімальні вкладення у розгортання IT-інфраструктури у хмарі;
• відмовостійкість та висока доступність даних: у будь-який момент сервіси доступні з будь-якої точки світу за наявності стабільного інтернет-підключення.

Компанії, які висувають підвищені вимоги до безпеки, бажають монопольно розпоряджатися виділеними провайдером IT-ресурсами або потребують індивідуальної конфігурації цих ресурсів, віддають перевагу приватній хмарі — Private Cloud. У цьому випадку вони отримують доступ не тільки до віртуальних серверів та сховища, але також до апаратної частини та гіпервізору. У приватній хмарі ви можете самостійно займатися адмініструванням та отримати більше інструментів для контролю та керування, ніж у Public Cloud.

Основні відмінності між публічною та приватною хмарою, які необхідно врахувати до перенесення інфраструктури у хмару.

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

Пропонуємо розглянути організаційні та технічні аспекти міграції бізнес-застосунків у хмару.

Міграція бізнес-застосунків у хмару: основні аспекти

Деякі корпоративні сервіси стикаються зі складністю масштабування або недостатньо високою відмовостійкістю. Хоча хмара сама по собі не дозволяє подолати внутрішні обмеження на розширення або підвищити доступність додатків, міграція інфраструктури в хмару може принести вашій компанії відчутні фінансові вигоди, особливо якщо IT-інфраструктура була розгорнута на локальному застарілому устаткуванні.

Міграція бізнес-сервісів є процесом їх повторного розгортання на новій платформі. При цьому, якщо міграція виконується між сумісними платформами, вторинна компіляція застосунку не буде потрібна.

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

Звідки можна мігрувати бізнес-застосунки:

1. окремий сервер (малий і середній бізнес);
2. побудований клієнтом дата-центр (великий бізнес);
3. орендований клієнтом сервер (локально чи у дата-центрі);
4. сервер, розміщений у локально розгорнутій хмарі;
5. SaaS-сервіс (імпорт або перенесення даних). Куди саме у хмару можна мігрувати бізнес-застосунки:
6. у загальнодоступну хмару;
7. у приватну хмару;
8. у гібридне середовище: комбінація приватної та загальнодоступної хмари.

Можливі окремі випадки перенесення даних. Наприклад, міграція типу P2V (Physical-to-Virtual), коли фізичний сервер повністю переноситься у віртуальне середовище включно з операційною системою, застосунками та їхніми даними. Існують спеціальні програмні рішення (конвертери), що дозволяють автоматизувати процес такої міграції та скоротити кількість помилок, які можуть виникнути при цьому. Якщо додаток був розміщений на віртуальному сервері, його достатньо змігрувати/конвертувати.

Частка великих компаній, які обрали собі міграцію інфраструктури в хмару, становить 60%. З іншого боку, кількісно середні та малі компанії швидше зростають – на 17,65% на рік.

Вибір корпоративних програм для міграції в хмару

Часто відправною точкою для переїзду стає необхідність оновити локальну IT-інфраструктуру. Цикл заміни фізичного обладнання тягне за собою заморожування капіталу (CapEx), тривалі погодження бюджетів та місяці очікування постачання.

Хмарні моделі виключають ці капітальні витрати, переводячи IT-бюджет у формат гнучких операційних витрат (OpEx). Замість тижнів очікування нових серверів ви отримуєте масштабовані ресурси миттєво. Крім того, перенесення у хмару дозволяє:

• Впоратися зі стрибкоподібним попитом: ресурси виділяються за кліком або автоматично, а ви платите лише за фактичне споживання (Pay-as-you-go).
• Підвищити відмовостійкість (High Availability): вбудовані балансувальники навантаження та кластеризація розподіляють трафік, захищаючи сервіси від падінь.
• Делегувати управління: провайдер бере на себе обслуговування фізичного обладнання та базову маршрутизацію.

Однак не всі сервіси отримують однакову вигоду від переїзду. Оцінювати застосунки для міграції слід на основі їхньої архітектури та характеру навантаження. Щоб структурувати цей процес, використовуйте базову матрицю розподілу робочих навантажень:

Профіль застосунку	Характер навантаження	Оптимальне середовище розгортання	Головна бізнес-вигода від міграції
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, ISO/IEC 27001:2005 та інші.

На що ще необхідно звернути увагу у договорі та SLA:

• які послуги адміністрування можна запросити у провайдера;
• на яких умовах надається підтримка апаратного забезпечення, адміністрування віртуальних машин, ОС та окремих застосунків;
• які рівні обслуговування діють для конкретних продуктів і чого вони залежать (варіанти: від локації дата-центру, типу дисків і віртуальних машин);
• на які випадки не поширюється гарантія постачальника послуг;
• процедура виплати компенсації та її розміри у разі порушення SLA.

Робота БД на новій платформі

В процесі міграції даних у Public Cloud застосунки можуть використовувати сервери бази даних, також розгорнуті у хмарі. Тоді провайдер повинен надати можливість реплікації чи перенесення сховища того типу, що є необхідним для роботи сервера баз даних.

Довгострокові витрати

У більшості випадків розгортання застосунків у публічній хмарі дозволяє бізнесу оптимізувати витрати на ІТ-інфраструктуру. Це можливо завдяки переходу від моделі фактичного володіння IT-інфраструктури (капітальні витрати, CapEx) до оплати необхідних ресурсів за підпискою (операційні витрати, OpEx). Однак для застосунків, які повинні бути доступні постійно і вимагають великих обсягів обчислювальних ресурсів, довгострокова вартість володіння в публічній хмарі може виявитися вищою, ніж вартість розгортання та подальшої підтримки приватної хмари.

Безпека хмарних рішень на надійність зберігання

При розгортанні IT-інфраструктури в Public Cloud віртуальні машини, що знаходяться в оренді у різних клієнтів, можуть розміщуватись на єдиній фізичній інфраструктурі. Це зобов’язує ретельно підходити до оцінки того, наскільки відповідально провайдер вирішує завдання повної ізоляції віртуальних машин одну від одної. Для цього важливо, щоб постачальник послуг працював відкрито і, відповідно, дозволяв проводити аудит безпекових політик на відповідність вимогам, а також викладав результати аудиту в загальний доступ.

Деякі провайдери пропонують додаткові послуги для підвищення надійності та відмовостійкості клієнтської IT-інфраструктури. Прикладами таких послуг можуть бути BaaS та DRaaS.

BaaS («бекап як сервіс»)

DRaaS («аварійне відновлення як сервіс»)

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

Дозволяє в стислі терміни та максимально ефективно відновлювати IT-інфраструктуру після серйозного збою з копії, що зберігається у хмарному репозиторії на боці провайдера. Ви отримуєте ПЗ для синхронізації даних, а також допомогу в підготовці та реалізації плану аварійного відновлення.

Принцип роботи сервісу BaaS:

Джерело: veeam.com

Масштабованість

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

Публічна чи приватна хмара?

Після оцінки потреби в ресурсах, сумісності платформ, можливості масштабування та інших аспектів міграції в публічну хмару може виникнути питання доцільності використання складнішого рішення корпоративного рівня — приватної хмари. Вона дозволяє залучити більше інструментів безпеки, відповідати специфічним вимогам до апаратної платформи та при певних обставинах виявляється економічно вигіднішою у довгостроковій перспективі.

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

Можливості кастомізації

Під індивідуальні вимоги клієнта та його бізнес-застосунків можна побудувати лише приватну хмару. У публічній ви отримуєте пул необхідних ресурсів із конкретними характеристиками, які не можна кастомізувати під конкретні завдання. У приватній хмарі, навпаки, можна обрати бажану кількість процесорів з певними параметрами (частота, покоління, виробник), об’єм та інші характеристики оперативної пам’яті, розміри сховища та отримати інші компоненти для своїх задач — наприклад, конкретні моделі відеокарт.

Обсяги споживаних ресурсів

У більшості випадків нераціонально переносити в публічну хмару навантаження, які генерують інтенсивний мережевий трафік через можливий вплив на них «сусідів». Аналогічна ситуація з іншими обчислювальними ресурсами — процесорною потужністю та дисковими накопичувачами. Таким чином, високонавантажені, вимогливі до якості сервісу віртуальні машини рекомендується розміщувати у приватній хмарі.

Керування даними

Окремі бізнес-застосунки регулярно обмінюються даними з локальним сховищем на стороні клієнта або зі сторонніми ресурсами. Під час оцінювання можливості міграції всі подібні взаємозв’язки мають бути проаналізовані та збережені або ж архітектура застосунку має бути перебудована з урахуванням нових вимог хмарної ІТ-інфраструктури.

Інтеграція із застарілими застосунками

Деякі сучасні бізнес-застосунки досі працюють із застарілим ПЗ, що може викликати проблеми в процесі міграції в хмару. Якщо ці залежності не можна адаптувати для роботи в хмарній 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