«Наша експертиза на ринку є нашою головною перевагою». Інтерв’ю з латвійським провайдером хмарних рішень Tet, який допомагає українцям

— Ще до початку великої війни в нас в Україні була стратегія Cloud First. Вона була спрямована на те, що всі власники даних поступово переходитимуть у хмару. Отже, компанії й державні структури почали такий перехід. З’явилося більше локальних провайдерів, які могли запропонувати хмару. 

Але після початку широкомасштабки бізнеси, банки, державні структури перенесли велику частину даних за кордон — у хмари гіперскейлерів, таких як AWS або ж Microsoft Azure, за умови величезних знижок чи взагалі безоплатно. Зараз, у 2024, ці пільгові умови поступово починають зникати. І власники даних вирішують: чи повертатися в Україну, чи залишатися десь у Європі. Цікаво було б дізнатися, як ви спостерігаєте цей процес переїздів українських клієнтів зі свого боку?

Так, це правда, що деякі гіперскейлери дійсно закінчують свої пільгові умови, принаймі частково.

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

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

Тому дійсно складно зрозуміти, який шлях вибрати: залишатися в Україні та брати в розрахунок ризики або приймати збільшені витрати й переносити інфраструктуру за кордон. 

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

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

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

Вони щодня працюють над забезпеченням роботи своїх центрів обробки даних. І це справді варте захоплення, навіть якщо технічно вони є нашими конкурентами. Не всі з них, звичайно, але деякі мають ці дизельні машини, і вони теж можуть забезпечувати себе електрикою 24/7.

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

Чи бачите ви подальший процес цього руху до Європи з України? Або він зупинився? 

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

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

— Якщо дані будуть розміщені від України, то що відбувається із затримкою сигналу через відстань між серверами? Чи це не проблема для бізнесу, з технічного погляду? 

Ну, я б сказав, що ми вже досить давно надаємо хмарні послуги українським клієнтам. І, чесно кажучи, затримка сигналу (latency) ніколи не була великою проблемою.

По-перше, це через те, що оптична мережа, яка покриває Європу, настільки розвинена, що, наприклад, від Києва до Риги сигнал іде приблизно 30 мілісекунд. І, чесно кажучи, дуже важко знайти програми, на які може суттєво вплинути така затримка. 

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

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

До чого я веду: ми знаємо, що у зберігання даних є три стадії еволюції. Спочатку був фізичний сервер (із прикладу ми бачимо, що деякі компанії досі на цій стадії), потім з’явилися віртуальні машини (більш економічний і надійний спосіб зберігання) й нарешті з’явилися контейнери й окремі сервіси, що допомагають керувати контейнерами. Чи можете ви простою мовою розповісти про різницю між цими способами зберігання даних?

20–30 років тому все жило на фізичних серверах. Тож у вас був фізичний сервер, ви встановлювали операційну систему поверх нього. І якщо ви хотіли, щоб усе працювало безпечно, ви встановлювали лише одну програму на нього. Але в більшості випадків ви встановили купу програм. Потім, коли вам потрібно пофіскити сервер, усе вийшло з ладу й усі програми зникли. 

Цю історію важко було масштабувати. А більшість цих серверів використовувалися неефективно.

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

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

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

Так з’явилося набагато краще використання ресурсів. Так, це безпечніше, ефективніше, але однаково завжди є куди розвиватися. Завжди трапляються випадки, коли віртуальні сервери не такі гнучкі, як хотілося б. 

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

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

Тому з’явився наступний крок еволюції — контейнери. Якщо все спростити, то це більш тонке використання ресурсів. Крім того, основна відмінність полягає в тому, що якщо віртуальний сервер покладається на гіпервізор, на рівень віртуалізації, то контейнер живе в операційній системі, повністью ізольовано в ній. 

Контейнер надзвичайно малий, надзвичайно швидкий, ви можете відкрити контейнери, можете помножити їх, і ви можете масштабувати їх за лічені секунди.

— І щоб керувати цима контейнерами, вам потрібна спеціальна система, і вона називається Kubernetes, чи не так? 

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

— Я чув про це, з грецької мови Kubernetes — це Stearman. 

Так, це правда. До речі, про цю технологію є ще один цікавий факт, який технічно не має значення. Насправді Kubernetes виник як внутрішній проєкт Google. Це те, що Google використовував для себе, вони назвали цю систему Borg.

Так от, я нещодавно почав дивитися Star Trek. Це науково-фантастичний серіал 80-х. 

Borg у всесвіті Стар Треку — це такий різновид іншопланетян, які тісно співпрацюють один з одним. Вони завжди взаємопов’язані. Немає нічого індивідуального. Вони всі разом працюють як один величезний організм.

І Google також назвав цю інфраструктуру Borg, тому що ідея з керуванням контейнерів дуже схожа. 

Це як одна велика структура, і якщо один контейнер впаде, це не має значення. Система одразу викличе ще один. 

— Якщо ми говоримо про Kubernetes і ми говоримо про завдання, які він може допомогти вирішити, як ви можете намалювати його типового клієнта? Хто в Україні може бути замовником такого рішення, як CaaS (Container-as-a-service), наприклад? 

Що ж, якщо ми говоримо про CaaS або KaaS, тобто про контейнери як послугу, або ж Kubernetes як послугу, у будь-якому випадку ми створюємо сервіси на базі наявної інфраструктури, тому що створити власне середовище Kubernetes нелегко.

Наприклад, із власного досвіду Tet, на розгортання Kubernetes нам знадобилося до двох років: від початку до кінцевої остаточної версії конфігурації. Саме на цьому рішенні ми будували власний інтернет-магазин і всі супутні сервіси.

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

Отже, замість того, щоб довго будувати все по частинах, коли ви берете кожен маленький блок і потім намагаєтеся співставити його з іншими, щоб побудувати ваш ідеальний контейнерний кластер, ви можете просто отримати це як послугу й запустити свій кластер Kubernetes, наприклад, у Tet Cloud, або в Azure, чи де завгодно. 

І це суттєво спрощує завдання.

— А щодо профілю компанії? 

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

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

Це дійсно допомагає як у масштабованості програми, так і в гнучкості інфраструктури. Рішення також дуже допомагає в розробці, тому що Kubernetes легко інтегрується в процеси CI/CD. Тут є дивовижна особливість: програміст, який пише код, може дуже легко публікувати його, може вносити зміни до коду й автоматично надавати його для тестування чи використання. І йому більше не потрібно чекати, поки спеціалісти з інфраструктури запустять нові віртуальні сервери. Усе підтягується й відбувається автоматично. 

— Тож це може бути стартап чи, можливо, навіть велика корпорація, яка запускає свої нові сервери?

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

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

— Чи дешевше використовувати контейнери як послугу для запуску проєктів? 

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

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

— Які ваші рекомендації компаніям, стартапам, які зараз обирають хмарне рішення та Kubernetes як послугу? На які моменти їм необхідно звернути увагу? 

Ми завжди намагаємося привернути увагу, наприклад, нового стартапу, коли вони запускають свою програму, до того, що вони спочатку повинні вирішити, де саме вони будуть її створювати. Дуже часто ми бачимо, що стартапи просто бачать свій вибір між трьома гіперскейлерами, тобто Microsoft, Amazon або Google. І вони повністю ігнорують усі інші варіанти на ринку, що, на мою думку, є втраченою можливістю.

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

Я б сказав, що не варто ігнорувати регіональні можливості, які є. Тому що контейнер як послуга — це не те, що можуть надати лише гіпермасштабувальники. 

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

Тож переконайтеся, що ви також поговорили зі своїми регіональними операторами — от що я б порекомендував.  

— А яка ваша найсильніша сторона? 

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

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

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

Читайте головні IT-новини країни в нашому Telegram

По темi

Читайте головні IT-новини країни в нашому Telegram