Хмарна еволюція
- Головна
- Блог
- Авторська колонка
- Хмарна еволюція
Мене звати Володимир Мельник, і я технічний директор Tucha. Хочу поділитися деякими спостереженнями та висновками, які я зробив впродовж цього року, а також розповісти про перспективи подальшого розвитку індустрії хмарних обчислень в Україні.
Йтиметься про справжню хмару — середовище розподілених обчислень і масштабованих сховищ, призначене для забезпечення роботи додатків та зберігання їх даних. Це не зовсім те ж саме, що й віртуальні машини, які за своїм функціоналом нічим не відрізняються від фізичних серверів, а багато в чому і перевершують їх, адже вони більш надійні та водночас прості в обслуговуванні. Цією повнофункціональністю ми, оператори, звикли, скоріше, пишатися, але чи завжди це саме те, що потрібно для вирішення задачі замовника?
Компанія Tucha надає сервіси хмарних обчислень з 2012 року. Але, згадуючи цей факт, я мушу сказати, що в тому далекому році у нас тільки з'явилися перші клієнти. А розуміння того, що ця область має певні перспективи на ринку України, прийшло до нас ще раніше, у 2011 році. Це і стало причиною активної роботи зі створення перших продуктів та їх просування на ринок.
Досить чітко пам'ятаю, як 8 років тому ми виходили на контакт з першими потенційними клієнтами, які ніяк не могли зрозуміти, про які такі хмари йдеться і для чого вони їм потрібні. Один з ІТ-менеджерів агрохолдингу навіть не одразу зрозумів, що мова зовсім не про хмари, які висять над землею та поливають дощем безкраї поля кукурудзи. :-)
Це було дуже давно, хмарні обчислення ще не тільки «не стали мейнстрімом»: дуже мало людей в Україні взагалі уявляли собі, що це таке і для чого це потрібно. ІТ-інфраструктура більшості підприємств, як правило, складалася з фізичних серверів, встановлених в гермозоні ЦОД або серверних кімнатах в офісах підприємства. Особливо хуткі хлопці такі сервери тримали в орендованих квартирах, де час від часу виникали перебої з електроживленням або з’являвся ще якийсь полтергейст у вигляді духу покійного прапрадіда, котрий виводить з ладу пари в RAID-масивах. Проте хмарні обчислення їм тоді не були цікаві: «Що це ще за хмари? У нас, мовляв, і так все добре».
І, знаєте, зараз теж у всіх все добре. Нібито.
А коли у всіх все добре і попиту на якісь нові сервіси, начебто, немає, операторам залишається тільки хвалитися кількістю сертифікатів, петабайтами місткостей та частками ринку. Нові сервіси не з'являються, оскільки постачальники послуг не бачать на них попиту.
Одразу зазначу: я вважаю, що віртуальні машини, а особливо машини, що працюють у надійній хмарі, — це прекрасний інструмент. Наша компанія для вирішення різних задач використовує їх вже понад 10 років, і цілком можу заявити, що я — фанат віртуальних машин. Говорити про їх переваги у 2019 році, на щастя, вже не потрібно, тож поговорімо про деякі... якщо не недоліки, то, висловлюючись коректно, особливості.
Уявімо, що ми зібралися кудись поїхати, наприклад, у відрядження або відпустку. Пакуємо валізи. У валізи можна покласти дуже багато всього (у моїй родині, наприклад, є справжні професіонали цього «тетрісу»). Але, якщо ми кожен предмет будемо складати в окрему коробку, у наші валізи поміститься набагато менше предметів, чи не так?
Іноді використання віртуальних машин — це приблизно те ж саме, що й упаковування речей в різні коробочки, оскільки кожна віртуальна машина є маленьким повноцінним сервером (ми все ж пишаємося цією повноцінністю, пам'ятаєте?). Тож у сервера є виділені йому процесори, своя оперативна пам'ять, своє дискове сховище. Ресурси виділяються з деяким надлишком, адже, якщо навантаження різко зросте, ресурси доведеться додавати, а це часто супроводжується перезапуском віртуальної машини. І ці ресурси, як правило, або просто не використовуються (хоча місце у валізі вони таки займають), або витрачаються марно (не забуваємо і про те, що кожна віртуальна машина несе в собі власну операційну систему з купою компонентів), навіть попри те, що ці системи у різних віртуальних машин однакові.
Звичайно, оператор цьому дуже радий. Особливо, коли технології віртуалізації, що використовуються, дозволяють здійснювати дедуплікацію даних у сховищах та в оперативній пам'яті.
І ось ми прибули до пункту призначення. Так вийшло, що одну з валіз ми примудрилися втратити. Можливо, нам вдасться її знайти. Та це все одно означає, що навіть у цьому разі якийсь час те, що було в цій валізі, буде нам недоступно. Щось доведеться докупити, а без чогось будемо змушені і зовсім обійтися. І ось, залишившись в малознайомому місті без трусів, ми, відкладаючи менш важливі, хоч і більш цікаві справи, поспішаємо придбати нові.
Я навіть не говорю про аварії на стороні ЦОД, які призводять до перебоїв в роботі тих чи інших віртуальних машин. Віртуальний сервер, на якій працює єдиний екземпляр того чи іншого сервісу, може збоїти і без впливу будь-яких чинників з боку середовища, в якому він працює. А кількість способів самому вистрілити собі в ногу (хоч на віртуальному сервері, хоч на фізичному) теоретично не має обмежень.
А ось якби у нас взагалі не було ніяких валіз, а все, що нам потрібно, — готель, який нас приймає, забезпечує у повній відповідності з нашими специфікаціями? Тоді ми веземо з собою (або навіть відправляємо заздалегідь) лише чіткі інструкції щодо того, які труси та якого кольору ми хочемо знаходити в шафі кожного дня, яким повинен бути наш чай, який костюм нам знадобиться в понеділок та які саме шорти — у вівторок. При цьому ми хочемо в будь-який момент змінювати будь-які параметри: «Мені сьогодні потрібно у 3 рази більше кави, ніж зазвичай», «Завтра хочу надіти шкарпетки в горошок, а післязавтра — у смужку», «Вранці хочу, щоб в номері вікна виходили на схід, а ввечері — на захід».
При цьому можна складати такі специфікації самому, можна завантажувати з мережі щось готове і, якщо потрібно, правити їх на свій смак. І, що б не трапилося, поки у нас є наші специфікації, ми можемо моментально відтворити те, що нам потрібно, у необхідній кількості. Заблювали свій гарний костюм? Немає потреби нести його в хімчистку: нам він не потрібен, як, втім, і готелю, тож готель його просто знищує та видає нам новий.
Таким чином, нам не потрібно возити з собою ніякі валізи. У нас є набір маніфестів, якими описується вся архітектура. На підставі цих маніфестів система оркестрації створює потрібні нам сутності тоді, коли вони нам потрібні, та видаляє їх, коли необхідність в них відпадає.
Це і є IaaC — infrastructure-as-a-code.
Це і є справжня хмара.
Що ще характерно для такої хмари? У справжній хмарі компоненти, що забезпечують роботу сервісу, одночасно працюють на декількох незалежних один від одного вузлах.
Саме така парадигма наразі стає все більш популярною: ми більше не запускаємо монолітний додаток в одному екземплярі. Людська цивілізація нарешті прийшла до того, щоб розбивати додаток на безліч мікросервісів і запускати ці мікросервіси у хмарі в тій кількості, яка необхідна, зважаючи на поточне навантаження на кожен з них.
Онлайн-сервіс не припинить роботу, якщо один з безлічі вузлів раптово вийде з ладу, адже на всіх вузлах працюють однакові репліки одного і того ж контейнера, а система миттєво виключає вузол, що впав, зі списку одержувачів запитів.
Тобто ціла ферма замість однієї улюбленої корови.
Ті, хто вже в темі, добре знають, чим ще характерна ця хмара.
Можливість запускати необхідну кількість примірників одного і того ж мікросервісу — це можливість легко переживати різкі стрибки навантаження без необхідності терміново додавати процесорні ядра та оперативну пам'ять на сервері (а найчастіше — з перезавантаженням системи).
Я вже не говорю про моніторинг метрик, аналіз журналів реєстрації подій, автоматичне горизонтальне масштабування та інші дива техніки.
І як тут не згадати про ті компанії, які самі розробляють ті чи інші програмні продукти та надають онлайн-сервіси, доступні мільйонам користувачів.
Ще минулого року ми зіткнулися з тим, що всі вони різною мірою зацікавлені в автоматизації процесів CI/CD. Якщо усереднити, наші замовники забажали бачити це у вигляді такого ланцюжка:
- програміст робить черговий комміт;
- платформа розробки робить аналіз змін;
- відбувається компіляція коду з урахуванням цих змін,
- запускаються юніт-тести, що перевіряють, чи нічого не зламалося;
- нова версія додатка потрапляє спершу на стейдж, де її тестують QA-інженери;
- нова версія додатка обережно потрапляє в продакшн, при цьому система спершу запускає нові контейнери, переконується в тому, що вони відчувають себе добре, і тільки після цього перемикає трафік на них.
А найважливіше у цьому ось що: все це відбувалося автоматично. Тобто цілком без участі людей, яким і так є, чим зайнятися.
Зазвичай саме для забезпечення всіх цих процесів компанія, що надає власні онлайн-сервіси, і винаймає фахівців в області DevOps або ж віддає ці задачі на аутсорс. А є й такі, хто вже звик завжди звертатися до фахівців зі служби підтримки свого оператора хмарних обчислень.
А нас, я маю чесно в цьому зізнатися, дуже легко спровокувати, підкинувши нам задачу, рішення якої не є для нас чимось тривіальним. Ми — компанія, яка вже понад 13 років надає послуги, пов'язані з хостингом веб-додатків, і першими в Україні запустили IaaS. Та до сих пір дуже боїмося здатися недостатньо кмітливими, клієнтоорієнтованими та динамічними, щоб освоїти щось нове. І довелося розбиратися, як же автоматизувати CI/CD. Звичайно, дуже швидко прийшли до використання Docker-контейнерів. Спершу намагалися автоматизувати роботу з ними якимись своїми милицями, але вчасно відкрили для себе Kubernetes, а разом з ним — і цілу величезну kloud-екосистему.
Тож ось, гарненько розібравшись, ми вирішили систематизувати накопичений досвід і витягти з нього додаткову користь. Так і з'явилася нова платформа — TuchaKube.
Це не тільки хостинг контейнерів в Kubernetes-кластерах. Це середовище, в якому вже налаштовано моніторинг, масштабування, випуск сертифікатів, персістентність даних, кластери СУБД та інші служби. Це сервіс автоматизації CI/CD. Це приватні репозиторії для коду, для артефактів, для контейнерів. Це те, чого в Україні ще не було.
Як то кажуть, краще один раз побачити. Тож пропонуємо вам подивитися деякі відеодемонстрації основних функцій платформи TuchaKube:
Ми плануємо випуск ще кількох серій, присвячених забезпеченню персістентності даних, захисту веб-додатків від атак зловмисників та іншим не менш цікавим темам. Щоб не пропустити новини, радимо підписатися на наш YouTube-канал та сторінку у Facebook І, звичайно ж, закликаю всіх звертатися до нас із задачами, у вирішенні яких сервіс TuchaKube може бути корисним. Раді вам 24/7!
