Яку роль сьогодні в Україні відіграє гібридна й мультихмарна стратегія та в чому різниця між цими поняттями?
Сьогодні мультихмарна стратегія — світовий тренд. Forbes прогнозує, що і гібридна, і мультихмарна моделі залишатимуться в центрі уваги та стануть новою реальністю. Це пов’язано з високим попитом на аналітику даних, інтеграцію хмарних рішень у виробництво, а також розвиток технологій штучного інтелекту й машинного навчання.
OnPrem інфраструктура рідко може надати такі широкі можливості, як хмара, адже там бізнес отримує не лише масштабованість, а й інструменти для інновацій: від low-code платформ до аналітики «з коробки». Але якщо ви працюєте з рішеннями, які не потребують постійних змін, вигідніше залишати їх на власних потужностях.
Сьогодні мультихмарна стратегія — світовий тренд. Forbes прогнозує, що і гібридна, і мультихмарна моделі залишатимуться в центрі уваги та стануть новою реальністю. Це пов’язано з високим попитом на аналітику даних, інтеграцію хмарних рішень у виробництво, а також розвиток технологій штучного інтелекту й машинного навчання.
OnPrem інфраструктура рідко може надати такі широкі можливості, як хмара, адже там бізнес отримує не лише масштабованість, а й інструменти для інновацій: від low-code платформ до аналітики «з коробки». Але якщо ви працюєте з рішеннями, які не потребують постійних змін, вигідніше залишати їх на власних потужностях.
Далі — пряма мова Дениса Гарькавого, Head of Infrastructure Modus X.
Дослідження консалтингових компаній показують три ключові чинники, які впливатимуть на застосування хмарних технологій для розвитку бізнесу: омолодження інфраструктури й забезпечення ключових операційних процесів і надійності, і тут значну роль може відігравати OnPrem інфраструктура, заощаджуючи на стабілізованих навантаженнях, підвищення продуктивності за рахунок нових способів застосування хмарних технологій у бізнесі і їхньої гнучкості й піонерстві — впровадження абсолютно нових продуктів, що змінюють індустрії, спираючись на технології доступні в більшості у хмарі.
Саме тому ДТЕК, один із наших великих клієнтів, ще у 2020 році визначив для себе стратегію побудови гібридної мультихмарної архітектури. Причина проста: OnPrem не забезпечує достатньої швидкості й гнучкості. Щоб додати новий сервіс, потрібен час на закупівлю, впровадження, підготовку команди. Гібридна хмара ж дає змогу розгортати рішення швидко, забезпечуючи апетити бізнесу в доступі до сучасних хмарних технологій. Надійність IT інфраструктури компанії критично важлива з точки зору репутації компанії в очах бізнес-партнерів й інвесторів. Мультихмара надає можливості реалізувати ефективні сценарії неперервності й Disaster Recovery забезпечуючи цю можливість при розумних витратах. Разом із тим DTEK може використовувати найбільш цінні технології лідерів хмарних технологій для підвищення власної продуктивності.
Водночас мультихмарна стратегія — це не лише про технології, а й про довгострокове бачення та стратегію. В Україні з цим складніше, але саме наявність стратегічного бачення й готовність довгостроково дотримуватися стратегії дозволяє європейцям системно розбудовуватися. Я вважаю, що плануючи й виконуючи таку IT-стратегію, ми наблизились до європейців.
Як виглядає алгоритм для клієнта, який прийшов до вас за мультихмарою?
У мене ще не було сценарію, коли хтось приходив і казав: «Хочу мультихмару». Це завжди відповідь на конкретні виклики. Наприклад, коли ми розглядали міграцію певних сервісів, то аналізували, у якій хмарі це буде ефективніше. Достатньо порахувати вартість у горизонті кількох років, і рішення стає очевидним. Якщо мультихмари немає, ви обмежені одним провайдером і його правилами гри.
Є й інший аспект: клієнт може мати потребу працювати в конкретному регіоні через технічні чи регуляторні вимоги. Якщо провайдер цього не пропонує, доводиться або будувати власне рішення у ЦОД, або шукати альтернативну хмару. Що більше таких альтернатив з’являється, то більше стимулів обирати найкраще з кількох варіантів або використовувати переваги декількох.
Але щоб дійти до цього рівня, потрібно мати стратегічний погляд. Якщо компанія дивиться лише на одного провайдера, вона може жити й так, це теж не помилка.
Питання лише в тому, чи готовий цей провайдер дати вам усі інструменти, ціни та сервіси, які ваc влаштують довгостроково. Такі ситуації змушують шукати альтернативи, і саме компанії, які активно шукають кращі рішення, найчастіше приходять до мультихмарної стратегії.
Які є упередження щодо мультихмари?
Перше — «це колосально дорого». Друге — «це надмірне навантаження на команду: багато ручної роботи, складна інтеграція, високі вимоги до кваліфікації, ще й треба поєднати все з On-Prem». Частково це правда, адже на старті справді є накладні витрати: навчання, пілоти, адаптація, інтеграційні роботи. Але з часом, коли команда входить у стабільний режим, усе виглядає значно простіше: з’являються спеціалізації, люди швидко «перемикаються» між проєктами, порівнюють підходи, зростає експертиза. Це, до речі, утримує інтерес інженерів і допомагає довше лишатися в компанії — бо працюють із різними стек-технологіями, а не монотонно в одному.
Ще одна теза — «це важко інтегрувати». Частково так: рішення, що мають працювати в різних хмарах і в OnPrem, потребують додаткового проєктування, тестів і перевірок. Але коли ти все це відпрацював і знаєш інструменти, далі воно працює на тебе: отримуєш стабільну інфраструктуру великого масштабу без потреби «армії» людей для підтримки.
Найбільша пастка — коли ти обираєш технологію, яку неможливо адаптувати або має жорсткий vendor lock-in, і лишаєшся «їсти кактус», сподіваючись на оновлення від вендора. Ми намагаємося такого уникати: будуючи гібридну мультихмару, віддаємо перевагу рішенням, що добре працюють у кількох хмарах і не змушують йти на компроміси під одну платформу, але при цьому надаємо вибір замовнику зайти і у vendor lock-in, якщо це має сенс. Ми маємо і такі ситуації, коли, наприклад, розробник цінного для замовника рішення не підтримує розгортання в іншій хмарі, а воно вам конче потрібне.
Про що має думати бізнес, коли йдеться про інфраструктуру — лише про CapEx та OpEx, чи ще й швидкість виходу продукту на ринок, гнучкість та масштабування?
Скажу так: у «довгій» перспективі хмара зазвичай дорожча. За нашими розрахунками, десь в півтора раза. Водночас хмара — це ідеальний спосіб старту без великих CapEx: зробити proof of concept, стабілізувати систему, протестувати архітектуру, вийти у продакшн. А далі, коли платформа стабілізована й така стратегія передбачена, — спустити на землю у власний дата-центр і вже там економити в довгостроковому горизонті.
Тобто у всіх непередбачуваних сценаріях хмара — це варіант. Вища ціна, але вища і гнучкість?
Для непередбачуваних навантажень OpEx-модель хмари ідеальна: можна взяти ресурс і так само легко від нього відмовитися. Якщо бізнес бачить стабільне споживання, можна брати комітменти та отримувати суттєві знижки: річні орієнтовно 15–25%, трирічні — ще більше. Важливо стратегічно розкласти сервіси по провайдерах: одні речі краще працюють в одному хмарному середовищі, інші в іншому. Це питання архітектури та бачення стека та переваг провайдерів.
У Європі все гостріше постає питання цифрового суверенітету, зокрема побоювання щодо американських сервісів. Як ви збалансовуєте локальних провайдерів та гіперскейлерів?
Суверенітет — чутлива тема. ЄС недаремно рухається до суверенного хмарного класу й посилює регуляції, щоб зменшити залежність від США. Чи можливі політичні «вимкнення» хмар? Технічно — так, але для провайдера це репутаційне самогубство, тож імовірність на мою думку низька. Однак суверена хмари на порядку денному в EU. Оскільки ми рухаємось до інтеграції з ЄС, то це питання буде стосуватися й України у найближчому майбутньому. На практиці для уникнення цього ризику ми дотримуємося правила виконання резервних трьох копій даних: перша — бекап у «рідній» локації/хмарі, друга — бекап у крос-хмарі для відновлення в альтернативного провайдера, та третя — фізична копія у власному ЦОД.
Це дає можливість відновлюватися там, де це найзручніше. Так, існують сценарії vendor lock-in, і не кожен бізнес готовий від нього відмовлятися. Але тоді потрібно свідомо приймати ризики, забезпечувати надійні бекапи та або Cloud Vendor ready стратегію. Ми так само радимо клієнтам: планувати near-zero RTO там, де це критично, і мати реальний шлях відновлення навіть у разі відмов цілих дата-центрів або регіонів.
Як керувати витратами у мультихмарі без втрати продуктивності сервісів? Де економити, а де краще інвестувати?
Відповідь дає FinOps, усталений підхід до управління хмарними витратами. Ключові принципи — це прозорість витрат для всіх залучених до формування вартості хмари в компанії (це можуть бути інженери, архітектори, FINOPS практики, фінансисти, CEO, закупники тощо), а також керування знижками в обмін на прогнозоване споживання. Це працює, коли ви розумієте свій профіль навантажень — наприклад, вам потрібен SAP на $1 млн/рік із плановим зростанням. Частину навантаження резервуєте на 1–3 роки, і отримуєте суттєві дисконти.
Також важливо налаштувати своє споживання розумно: dev/test вимикати на ніч та у вихідні, міняти «не утилізовані» ресурси дешевші класи там в разі відповідності вимогам потужності.
Але у хмари є і зворотний бік хмари, і це неконтрольоване зростання витрат. Неправильно налаштований автоскейл без лімітів легко «рознесе» рахунок, тому потрібні ліміти, алерти, регулярні cost post-mortem, участь інженерів, архітекторів і менеджерів. У хмарі варто системно моніторити аномалії споживання, щоб не дивуватися рахунку наприкінці місяця, бо хмара настільки гнучка, що не прощає помилок у автоматичному масштабуванні ваших сервісів.
Коли базові дисципліни FINOPS відпрацьовані = операційні процеси, наступний рівень — архітектурна оптимізація: зміна сервісів і платформ на більш економні.
DevOps та автоматизація в гібридних середовищах — що працює найкраще?
Дуже залежить від технологічного стека компанії та того, чи є власна розробка. Якщо просто приймаєте код від зовнішніх команд, вплив менший. Якщо ж будуєте свої CI/CD-процеси та практики DevOps/SRE на рівні enterprise, тут багато нюансів: безпека, відповідність, інтеграції між хмарами та OnPrem.
Наш підхід — уніфікувати практики й зафіксувати їх у «живій» документації (внутрішня wiki, DevOps Cookbook).
Ми витратили майже рік, щоб описати, що саме означає DevOps у нашому контексті, і постійно це оновлюємо. Це пришвидшує онбординг, знімає розрив «з вуст в уста» й робить процес відтворюваним. Критично важливо залучати інженерів до формування й адаптації DEVOPS: принцип «зроби для інших так, як хотів би, щоб вони зробили для тебе» тут найкращий.
Перейдемо від автоматизації до штучного інтелекту в інфраструктурі. Де він уже дав відчутний приріст можливостей — так, як раніше важко було уявити? А де, на вашу думку, AI поки не потрібен?
Якщо чесно, навколо AI є певна бульбашка. Але є й винятки, де він справді працює.
У чистому OnPrem — середовищі впроваджувати «штучний інтелект» як окрему систему складно й дорого. Натомість машинне навчання під конкретні задачі — цілком практична річ: моделі під вузькі кейси дають результат.
У масовому виробництві це, наприклад, візуальний контроль дефектів чи виявлення порушень техніки безпеки автоматично й у реальному часі. В інфраструктурі ж частіше йдеться не про «власний AI», а про вбудовані ML-інструменти у продуктах вендорів, плюс платформи хмарних провайдерів, на яких можна розгорнути специфічні рішення під свої процеси. Суть — знайти саме те застосування, яке підвищить продуктивність тут і зараз: інколи це може бути навіть генерація коду або описів автоматизації. Ми це пілотували й продовжуємо перевіряти гіпотезу про реальну користь у розробці.
Результати поки неоднорідні. Є дослідження, які показують приріст продуктивності розробників і DevOps завдяки AI-інструментам; є й більш стримані висновки: використання зростає, а ефект не завжди лінійний. Тому ми орієнтуємося на прикладну цінність, а не на хайп.
З операційної точки зору AI корисний там, де людина фізично не встигає. Це виявлення неефективного споживання ресурсів, ранні сигнали про зростання помилок, сплески затримок у базах даних та і загалом підказки, де «болить» і на що звернути увагу першочергово.Це речі, які важко зловити тригерним моніторингом, проте платформа, що обробляє мільярди подій, бачить їх одразу.
Ми тестували окремі AI рішення з генеративним ШІ, і наразі не дуже задоволені ефектами. Чекаємо на вужчі агенти (орієнтовані на спеціалізовані функції) від вендорів і паралельно підбираємо ті, що реально підвищують продуктивність інженерів. Також тестуємо платформи й розробляємо агентів для роботи з нашими базами знань для підтримки клієнтів і автоматизації рутинних процесів, які людям виконувати довго й неефективно, а агент знаходить і вирішує за хвилину.
Як організувати перехід і трафік між хмарою й OnPrem без класичного периметра?
Сьогодні підхід змінюється під тиском Zero Trust. Класична модель «відкрив VPN — і пішов» відходить. Zero Trust диктує інший технологічний стек доступу до хмар. Вендори активно просувають SASE/ZTNA-рішення, які знімають з компанії більшість турбот щодо периметра: фаєрволи, шлюзи, маршрутизатори, проксі. Це добре працює як у сценарії хмара-хмара, так і у хмара-он-прем, але має і нюанси на які варто зважувати: зав’язка на стек інформ-безпеки одного виробника може бути «слабкою ланкою» в ланцюзі. То ж треба багато за та проти.
Коли власний OnPrem суттєвий, периметр усе одно потрібен, але ми будуємо його так, щоб керувати мережею з однієї консолі: однакові політики доступу для будь-якого сегмента й провайдера, NGFW із повним набором засобів безпеки (IPS/IDS, анти-malware, URL-фільтрація, доступ за ролями). Тоді, не маючи прав, ти навіть на мережевому рівні не дістанешся сервісу і не зможеш розвинути кібератаку.
Практично ми використовуємо рішення лідеру ринку — Check Point. Вони дають гомогенну політику для різних хмар і OnPrem, плюс покривають комплаєнс-аудити, posture management, вразливості, моніторинг. З досвідом мультихмара керується централізовано й стабільно.
Чи мультихмара «зеленіша», ніж OnPrem? Чи допомагає скорочувати викиди CO₂?
Залежить від локації обладнання та регуляторних вимог країни. В Україні вимоги до «зеленості» дата-центрів не завжди жорсткі. У ЄС навпаки: часто доведеться звітувати про енергоспоживання та відповідність «зеленим» стандартам.
У хмарі провайдер зазвичай сам декларує частку «зеленої» енергії, тож можна свідомо обирати більш «зелені» регіони — якщо це частина стратегії компанії. У FinOps-практиках вже є метрики для карбон-футпринту, тож вплив можна вимірювати і в хмарі, і в OnPrem. Тож мульти/гібрид дає гнучкість вибору більш екологічних майданчиків, але «зеленість» не автоматична — це питання конкретних виборів.
Яку найгіршу помилку може зробити C-level під час переходу у хмару?
Коли ІТ-стратегія не узгоджена з бізнес-стратегією. Якщо мульти- або монохмара дає бізнесу потрібну цінність — це правильно. Якщо ні, це помилка, незалежно від моди. Те саме стосується й безпеки: можна мати vendor lock-in і прогалини в захисті, а можна свідомо будувати мультивендорний ландшафт. Головне — бізнес цінність, відповідність бізнес-вимогам і комплаєнсу.
І наостанок — трохи в майбутнє. Які скіли інженерів будуть критично важливими найближчими роками?
Залежить від ролі та домену, але тренд такий: мультихмара нікуди не дінеться. Тож інженерам доведеться працювати і в хмарі, і OnPrem. Але якщо коротко, то інженер майбутнього — це той, хто створює платформи й надає самообслуговування, розуміє мультихмару й бізнес-метрики, а не лише «залізо» чи інфраструктуру одного провайдера.
