Модуль 3.9: WebAssembly та Cloud Native

Складність: [MEDIUM] - Концептуальна обізнаність

Час на виконання: 25-30 хвилин

Передумови: Модуль 3.1 (Хмарні нативні принципи), Модуль 3.3 (Хмарні нативні патерни)

Що ви зможете робити

Після завершення цього модуля ви зможете:

Пояснити що таке WebAssembly та як WASI розширює його для серверного використання
Порівняти навантаження Wasm з контейнерами за часом запуску, розміром та ізоляцією безпеки
Визначити де Wasm вписується в cloud native ландшафт поряд з контейнерами
Оцінити варіанти використання, де Wasm має переваги над традиційними середовищами виконання контейнерів

Чому цей модуль важливий

WebAssembly (Wasm) — найзначніша нова технологія середовища виконання з часів контейнерів. Спочатку створена для браузерів, тепер вона проникає у серверну сторону та хмарні нативні обчислення. Wasm навантаження запускаються за мілісекунди, важать кілобайти та працюють у безпечній пісочниці. KCNA очікує, що ви розумієте, де Wasm знаходиться у хмарному нативному ландшафті та як він повʼязаний з контейнерами.

“Якби WASM+WASI існували у 2008 році, нам не потрібно було б створювати Docker.” — Соломон Хайкс, співзасновник Docker (2019)

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

Що таке WebAssembly?

┌─────────────────────────────────────────────────────────────┐
│              WEBASSEMBLY (WASM)                              │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Портативний, компактний формат БАЙТ-КОДУ                  │
│                                                             │
│  Спочатку: Запуск наближеного до нативного коду у          │
│            веббраузерах                                     │
│  Тепер:    Запуск будь-де — сервери, edge, IoT, хмара     │
│                                                             │
│  Ключові властивості:                                       │
│  ─────────────────────────────────────────────────────────  │
│                                                             │
│  ПОРТАТИВНИЙ  Скомпілюйте раз, запускайте на будь-якому    │
│               Wasm runtime (як Java байт-код, але легший)   │
│                                                             │
│  ШВИДКИЙ      Швидкість виконання наближена до нативної    │
│               Холодний запуск за мілісекунди (не секунди)   │
│                                                             │
│  БЕЗПЕЧНИЙ    За замовчуванням у пісочниці — немає доступу  │
│               до файлів/мережі без явного дозволу           │
│                                                             │
│  КОМПАКТНИЙ   Бінарні файли вимірюються в КБ, не МБ чи ГБ │
│                                                             │
│  ПОЛІГЛОТНИЙ  Компіляція з Rust, Go, C/C++, Python,        │
│               JavaScript та інших                           │
│                                                             │
└─────────────────────────────────────────────────────────────┘

WASI: Системний інтерфейс

Wasm у браузері може взаємодіяти з DOM. Але на сервері йому потрібен доступ до файлів, мережі, годинників та змінних середовища. Саме це надає WASI (WebAssembly System Interface).

Думайте про WASI як “POSIX для Wasm” — стандартний інтерфейс між Wasm модулями та операційною системою хоста, але з моделлю безпеки на основі можливостей, де кожен дозвіл надається явно.

┌─────────────────────────────────────────────────────────────┐
│  Ваш код (Rust, Go тощо)                                   │
│       │                                                     │
│       ▼  компіляція                                         │
│  Wasm бінарний файл (.wasm)                                 │
│       │                                                     │
│       ▼  запускається на                                    │
│  Wasm Runtime (WasmEdge, Wasmtime тощо)                     │
│       │                                                     │
│       ▼  звертається до ОС через                            │
│  WASI (доступ до файлів, мережа, змінні середовища)         │
│       │                                                     │
│       ▼                                                     │
│  Операційна система хоста                                   │
└─────────────────────────────────────────────────────────────┘

Wasm vs контейнери

Це порівняння, яке KCNA найімовірніше перевірятиме. Знайте компроміси.

Аспект	Контейнери (OCI)	WebAssembly
Час запуску	Секунди	Мілісекунди
Розмір бінарного файлу	МБ — ГБ	КБ — невеликі МБ
Модель безпеки	Ділить ядро хоста, потребує шарів ізоляції	Пісочниця за замовчуванням, на основі можливостей
Портативність	Працює на тій самій ОС/архітектурі (або мульти-arch збірки)	Справжнє “скомпілюй раз, запускай будь-де”
Зрілість екосистеми	Дуже зріла — величезна бібліотека образів	Ранній етап — швидко зростає
Підтримка мов	Будь-яка мова (повна ОС у контейнері)	Зростає, але не всі мови добре підтримані
Доступ до системи	Повний (якщо не обмежений)	Явно наданий через WASI
Випадки використання	Застосунки загального призначення	Функції, edge, плагіни, легковагові сервіси
Оркестрація	Kubernetes, Docker Swarm	На стадії розвитку (SpinKube, runwasi)

┌─────────────────────────────────────────────────────────────┐
│              ПОРІВНЯННЯ ЧАСУ ЗАПУСКУ                         │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Контейнер: ████████████████████████████████  ~1-5 секунд  │
│  Wasm:      ██                                ~1-5 мс     │
│                                                             │
│  ПОРІВНЯННЯ РОЗМІРУ ОБРАЗУ                                  │
│  ─────────────────────────────────────────────────────────  │
│  Контейнер: ████████████████████████████████  50-500 МБ    │
│  Wasm:      █                                 0.1-5 МБ    │
│                                                             │
│  Це важливо для:                                            │
│  • Serverless (штраф холодного запуску)                     │
│  • Edge обчислень (обмежене сховище/пропускна здатність)   │
│  • Масштабування до нуля (вартість перезапуску має          │
│    бути низькою)                                            │
│                                                             │
└─────────────────────────────────────────────────────────────┘

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

Wasm runtime

Wasm runtime виконує .wasm бінарні файли, подібно до того, як container runtime (containerd, CRI-O) запускає образи контейнерів.

Runtime	Ключові характеристики
Wasmtime	Референсна реалізація від Bytecode Alliance; продакшен-рівень, зосереджений на стандартах
WasmEdge	Проєкт CNCF Sandbox; оптимізований для edge та cloud native; підтримує мережеві та AI розширення
Spin	Фреймворк розробника від Fermyon; легке створення та запуск serverless Wasm застосунків
wasmCloud	Проєкт CNCF Sandbox; розподілена платформа для побудови Wasm застосунків з компонентною моделлю

Для KCNA: Знайте, що WasmEdge та wasmCloud є проєктами CNCF. Вам не потрібно знати внутрішню будову runtime.

Wasm на Kubernetes

Запуск Wasm навантажень на Kubernetes можливий вже сьогодні через containerd shims — той самий інтерфейс, що використовують контейнери.

┌─────────────────────────────────────────────────────────────┐
│              WASM НА KUBERNETES                              │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Як контейнери працюють на K8s:                             │
│  ─────────────────────────────────────────────────────────  │
│  kubelet → containerd → runc → Linux контейнер              │
│                                                             │
│  Як Wasm працює на K8s:                                     │
│  ─────────────────────────────────────────────────────────  │
│  kubelet → containerd → runwasi → Wasm runtime              │
│                                                             │
│  Той самий kubelet, той самий containerd, інший shim!       │
│                                                             │
│  Ключові проєкти:                                           │
│  ─────────────────────────────────────────────────────────  │
│                                                             │
│  runwasi     containerd shim що запускає Wasm замість       │
│              Linux контейнерів. Пряма заміна runc           │
│                                                             │
│  SpinKube    Запуск Spin (Wasm) застосунків на Kubernetes   │
│              через custom resources. Управляє Wasm          │
│              застосунками як K8s управляє контейнерами      │
│                                                             │
│  Обидва використовують RuntimeClass щоб повідомити K8s     │
│  "цей Pod запускає Wasm"                                    │
│                                                             │
└─────────────────────────────────────────────────────────────┘

RuntimeClass: Міст

Kubernetes використовує RuntimeClass для вибору, який runtime обробляє Pod. Кластер може запускати контейнерні Podʼи та Wasm Podʼи поруч:

┌──────────────────────────────────────────┐
│           Кластер Kubernetes              │
│                                          │
│  ┌──────────────┐  ┌──────────────┐      │
│  │ Container Pod │  │   Wasm Pod   │      │
│  │ runtimeClass: │  │ runtimeClass:│      │
│  │   (default)   │  │   wasmtime   │      │
│  │               │  │              │      │
│  │  containerd   │  │  containerd  │      │
│  │  → runc       │  │  → runwasi   │      │
│  │  → Linux      │  │  → Wasmtime  │      │
│  └──────────────┘  └──────────────┘      │
│                                          │
└──────────────────────────────────────────┘

Коли використовувати Wasm

Добре підходить

Випадок використання	Чому Wasm переважає
Serverless функції	Холодний запуск за мілісекунди робить масштабування до нуля практичним
Edge обчислення	Крихітні бінарні файли, низькі вимоги до ресурсів, працює на обмежених пристроях
Системи плагінів	Безпечна пісочниця — плагіни не можуть отримати доступ до хоста без дозволу
Короткоживучі обробники запитів	Без штрафу запуску, мінімальні накладні витрати
Мультитенантна ізоляція	Кожен Wasm модуль ізольований без потреби повної контейнерної ізоляції

Не найкращий вибір (поки що)

Випадок використання	Чому контейнери кращі
Складні застосунки	Повні бібліотеки ОС, зрілі інструменти налагодження, широка підтримка мов
Сервери баз даних	Потрібен прямий доступ до обладнання, складні системні виклики
Застосунки що потребують зрілої екосистеми	Образи контейнерів існують майже для всього; екосистема Wasm ще зростає
Важкі I/O навантаження	WASI I/O ще розвивається порівняно з нативним Linux I/O
Застарілі застосунки	Перекомпіляція у Wasm нетривіальна для великих кодових баз

Компонентна модель

Wasm Component Model — стандарт, що формується, який дозволяє Wasm модулям компонуватися разом, незалежно від мови написання:

┌─────────────────────────────────────────────────────────────┐
│  Rust компонент ──┐                                         │
│                   ├──→ Скомпонований застосунок             │
│  Go компонент ────┤    (зʼєднаний на рівні Wasm,           │
│                   │     не на рівні ОС/контейнера)          │
│  JS компонент ────┘                                         │
└─────────────────────────────────────────────────────────────┘

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

Чи знали ви?

Усі основні браузери постачають Wasm runtime — Chrome, Firefox, Safari та Edge запускають Wasm нативно. Це четверта офіційна вебмова поряд з HTML, CSS та JavaScript. Ця браузерна спадщина пояснює портативність та безпеку Wasm — він був спроектований для безпечного запуску ненадійного коду.
Wasm бінарні файли є архітектурно нейтральними — На відміну від образів контейнерів, що потребують окремих збірок для amd64 та arm64, один .wasm файл працює на будь-якій архітектурі. Без мульти-arch збірок, без платформо-специфічних образів. Це особливо цінно для edge обчислень, де можна розгортати на x86 серверах, ARM пристроях та RISC-V платах.
Fermyon запустив 5,000 Wasm застосунків на одному вузлі — У бенчмарках один вузол Kubernetes запустив тисячі Wasm мікросервісів одночасно, порівняно з десятками контейнерів. Крихітний обсяг та швидкий запуск роблять щільність суттєво вищою.

Поширені помилки

Помилка	Чому це шкодить	Правильне розуміння
”Wasm замінює контейнери”	Веде до хибних архітектурних рішень	Wasm доповнює контейнери — використовуйте кожний де він найкращий
”Wasm лише для браузерів”	Пропускаєте серверну революцію	WASI дозволяє Wasm працювати будь-де: сервери, edge, хмара, IoT
Думати що будь-який застосунок можна скомпілювати у Wasm	Не всі мови/бібліотеки добре підтримують Wasm	Rust та Go мають добру підтримку; складні C++ застосунки з багатьма системними викликами складніші
Ігнорувати прогалину екосистеми	Побудова на незрілому інструментарії спричиняє біль	Екосистема контейнерів (образи, реєстри, налагодження) значно зріліша сьогодні
Плутати Wasm runtime з container runtime	Вони вирішують різні проблеми	Wasm runtime (Wasmtime, WasmEdge) виконують .wasm байт-код; container runtime (runc, crun) управляють Linux namespaces/cgroups

Тест

1. Для чого WebAssembly був спочатку спроектований?

A) Заміна контейнерів Docker B) Запуск наближеного до нативного коду у веббраузерах C) GPU обчислення D) Оптимізація запитів до бази даних

Відповідь

B) Запуск наближеного до нативного коду у веббраузерах. Wasm був створений для запуску чутливого до продуктивності коду (як ігри та відеоредагування) у браузерах з наближеною до нативної швидкістю. Його використання у серверних та хмарних нативних обчисленнях зʼявилось пізніше.

2. Що таке WASI?

A) Формат образу контейнера на основі Wasm B) Вебфреймворк для побудови Wasm застосунків C) Системний інтерфейс, що дозволяє Wasm модулям отримувати доступ до ресурсів хоста як файли та мережа D) Контролер Kubernetes для Wasm навантажень

Відповідь

C) Системний інтерфейс, що дозволяє Wasm модулям отримувати доступ до ресурсів хоста як файли та мережа. WASI (WebAssembly System Interface) — стандартний API між Wasm модулями та операційною системою, що використовує модель безпеки на основі можливостей.

3. Як Kubernetes запускає Wasm навантаження поруч з контейнерами?

A) Потрібен окремий кластер Wasm B) Через runwasi як containerd shim, обраний через RuntimeClass C) Wasm Podʼи замінюють усі контейнерні Podʼи на вузлі D) Шляхом конвертації Wasm в образи контейнерів

Відповідь

B) Через runwasi як containerd shim, обраний через RuntimeClass. runwasi підключається до containerd так само, як runc для контейнерів. RuntimeClass повідомляє Kubernetes, який runtime використовувати для кожного Pod, тому контейнери та Wasm працюють поруч на тому ж кластері.

4. Який з наступних є проєктом CNCF у сфері WebAssembly?

A) Wasmtime B) Spin C) WasmEdge D) Docker

Відповідь

C) WasmEdge. WasmEdge є проєктом CNCF Sandbox, оптимізованим для edge та cloud native випадків використання. Wasmtime — проєкт Bytecode Alliance. Spin — від Fermyon. wasmCloud також є проєктом CNCF Sandbox.

5. Яка найбільша перевага Wasm над контейнерами для serverless функцій?

A) Краща підтримка мов B) Холодний запуск за мілісекунди замість секунд для контейнерів C) Зріліша екосистема D) Вбудована підтримка баз даних

Відповідь

B) Холодний запуск за мілісекунди замість секунд для контейнерів. Serverless функції що масштабуються до нуля повинні швидко запускатися при надходженні запиту. Wasm модулі запускаються за 1-5 мілісекунд порівняно з 1-5 секундами для контейнерів, усуваючи штраф холодного запуску.

6. Яке твердження найкраще описує звʼязок між Wasm та контейнерами?

A) Wasm замінить контейнери протягом 5 років B) Контейнери завжди кращі за Wasm C) Вони доповнюють одне одного — кожний переважає у різних випадках використання D) Wasm — це просто формат образу контейнера

Відповідь

C) Вони доповнюють одне одного — кожний переважає у різних випадках використання. Контейнери зрілі та працюють майже для всього. Wasm переважає там, де важливі швидкий запуск, малий розмір та сильна пісочниця (serverless, edge, плагіни). Більшість організацій використовуватимуть обидва.

Підсумок

WebAssembly — портативний формат байт-коду — спочатку для браузерів, тепер розширюється на серверну сторону та cloud native
WASI надає системний доступ (файли, мережа) з безпекою на основі можливостей
Wasm vs контейнери: швидший запуск (мс vs с), менший (КБ vs МБ), пісочниця за замовчуванням — але менш зріла екосистема
Wasm runtime: Wasmtime, WasmEdge (CNCF), Spin, wasmCloud (CNCF)
Wasm на K8s: runwasi shim + RuntimeClass дозволяє Wasm та контейнерам співіснувати
Найкраще для: serverless, edge, плагіни, мультитенантна ізоляція
Не готовий для: складних застосунків, важкого I/O, міграції застарілих систем
Wasm доповнює контейнери — він їх не замінює

Наступний модуль

Модуль 3.10: Зелені обчислення та сталий розвиток - Як хмарні нативні практики перетинаються з екологічною сталістю та вуглецево-обізнаними обчисленнями.