WebAssembly (Wasm) dávno opustil prohlížeč. V roce 2026 je to plnohodnotný runtime pro serverové aplikace — od edge functions přes plugin systémy až po bezpečnostně kritické finanční služby. Kompletní průvodce: architektura, WASI 0.2, komponentový model, performance benchmarky a reálné nasazení v českých firmách.
Proč WebAssembly na serveru — a proč právě teď¶
Solomon Hykes, spoluzakladatel Dockeru, v roce 2019 prohlásil: „Kdyby Wasm + WASI existovaly v roce 2008, Docker bychom nepotřebovali.” O sedm let později se jeho predikce naplňuje — ne jako náhrada kontejnerů, ale jako komplementární vrstva tam, kde kontejnery selhávají.
Tři konvergující faktory dělají rok 2026 přelomovým:
- WASI 0.2 Preview stabilizován — konečně standardizované rozhraní pro filesystem, síť, hodiny a kryptografii. Každý Wasm modul může komunikovat se systémem přes definované capability-based API, bez přístupu k čemukoli navíc.
- Component Model 1.0 — umožňuje skládat Wasm moduly z různých jazyků (Rust + Python + Go) do jedné aplikace. Každý komponent má přesně definované rozhraní (WIT — WebAssembly Interface Types) a nemůže přistupovat k paměti ostatních.
- Produkční runtime dospěly — Wasmtime 20+, WasmEdge 0.14, Spin 3.x a Fermyon Cloud nabízejí sub-milisekundový cold start, produkční stabilitu a enterprise support.
Architektura Wasm backendu¶
Na rozdíl od klasických kontejnerových architektur, kde každý service běží ve vlastním Docker kontejneru s celým OS layerem, Wasm backend používá sandboxovaný modul — binárku o velikosti stovek kilobajtů až jednotek megabajtů, která startuje za mikrosekundy.
Vrstvy Wasm backend stacku¶
- Wasm Runtime (Wasmtime, WasmEdge, Wasmer) — JIT/AOT kompilátor, memory management, sandboxing
- WASI layer — standardizované systémové volání (soubory, síť, env vars, random, hodiny)
- Component Model — inter-module komunikace, type-safe interface přes WIT
- Application Framework (Spin, wasi-http, Leptos) — HTTP routing, middleware, state management
- Orchestrace (SpinKube, Kubernetes + runwasi, Fermyon Cloud) — scheduling, scaling, deployment
Porovnání: kontejner vs. Wasm modul¶
| Vlastnost | Docker kontejner | Wasm modul |
|---|---|---|
| Cold start | 100 ms – 5 s | 0.5 – 5 ms |
| Velikost image | 50 MB – 1 GB | 0.1 – 10 MB |
| Izolace | Linux namespaces + cgroups | Sandboxed linear memory |
| Portabilita | Linux (+ emulace) | Jakýkoli OS/arch s runtime |
| Bezpečnostní model | Root by default, capability drop | Zero access by default, explicit grants |
| Multi-tenancy | Složité (K8s namespaces) | Nativní (modul = tenant) |
| Jazyková podpora | Jakýkoli jazyk | Rust, Go, C/C++, Python, JS, C#, Zig |
WASI 0.2 — systémové rozhraní, které mění pravidla¶
WASI (WebAssembly System Interface) je to, co dělá z Wasm více než jen formát pro binárky. Je to capability-based security model — Wasm modul nemá přístup k ničemu, dokud mu host explicitně nepředá capability.
Prakticky to znamená:
- Modul nemůže číst filesystem, pokud nedostane handle na konkrétní adresář
- Modul nemůže otevřít síťové spojení, pokud nedostane socket capability
- Modul nemůže přistoupit k env proměnným, pokud nejsou explicitně předány
- Žádný modul nemůže „uniknout” ze svého sandboxu — ani exploitem v runtime
Pro enterprise bezpečnost je tohle zásadní skok. Místo modelu „kontejner má přístup ke všemu a my omezujeme” máme model „modul nemá přístup k ničemu a my povolujeme”. Defense in depth v praxi.
WASI 0.2 klíčová rozhraní¶
- wasi:http — HTTP klient a server, streaming bodies, trailers
- wasi:filesystem — sandboxovaný přístup k souborům a adresářům
- wasi:sockets — TCP/UDP, DNS lookup
- wasi:clocks — monotónní a wall-clock čas
- wasi:random — kryptograficky bezpečný RNG
- wasi:cli — stdin/stdout/stderr, env vars, exit codes
- wasi:keyvalue (proposal) — key-value store abstrakce pro state
- wasi:messaging (proposal) — pub/sub, message queues
Component Model — polyglot bez kompromisů¶
Component Model je architektonický průlom, který řeší jeden z nejstarších problémů softwarového inženýrství: jak bezpečně kombinovat kód z různých jazyků.
V tradičním světě máte FFI (Foreign Function Interface) — nebezpečné, křehké, náchylné k memory corruption. Nebo máte microservices — bezpečné, ale se síťovou latencí a serializačním overheadem.
Component Model nabízí třetí cestu:
// WIT definice rozhraní (WebAssembly Interface Types)
package core:analytics@1.0.0;
interface scoring {
record customer {
id: string,
transactions: list
risk-profile: risk-level,
}
enum risk-level {
low,
medium,
high,
critical,
}
record transaction {
amount: float64,
timestamp: u64,
merchant-category: string,
}
// Implementováno v Rustu pro performance
score: func(customer: customer) -> float64;
// Implementováno v Pythonu pro ML model
predict-churn: func(customer: customer) -> float64;
}
Rust komponent implementuje score (výpočetně náročná operace), Python komponent implementuje predict-churn (ML inference). Oba běží ve stejném procesu, komunikují přes shared-nothing interface, a ani jeden nemůže přistoupit k paměti druhého.
Performance benchmarky — čísla z praxe¶
Benchmarky jsou vždy kontextově závislé, ale naše měření na typických enterprise workloadech ukazují konzistentní vzorce:
HTTP API (JSON CRUD, 1KB payload)¶
| Runtime | RPS (single core) | P99 latence | Paměť/instance |
|---|---|---|---|
| Node.js 22 (Docker) | 12 400 | 8.2 ms | 85 MB |
| Go 1.23 (Docker) | 38 200 | 2.1 ms | 22 MB |
| Rust/Spin (Wasm) | 34 800 | 1.4 ms | 3.2 MB |
| Rust/Axum (Docker) | 41 500 | 1.1 ms | 12 MB |
Wasm verze Rustu ztrácí ~16 % RPS oproti nativnímu Rustu kvůli sandbox overheadu — ale spotřebuje 4× méně paměti. Při multi-tenant scénáři (stovky instancí) Wasm výrazně vyhrává v TCO.
Cold start (od nuly po první response)¶
| Platforma | Cold start |
|---|---|
| AWS Lambda (Node.js) | 180 – 800 ms |
| AWS Lambda (Java) | 2 – 8 s |
| Kubernetes pod (Go) | 500 ms – 3 s |
| Spin (Wasm) | 0.5 – 3 ms |
| Fermyon Cloud (Wasm) | 1 – 5 ms |
Sub-milisekundový cold start mění hru pro serverless. Žádné warm-up strategie, žádné provisioned concurrency, žádné cold start penalty. Každý request je de facto „warm”.
Reálné use cases v enterprise¶
Kde Wasm backend skutečně vyniká — ne jako náhrada všeho, ale jako přesný nástroj pro specifické problémy:
1. Plugin systémy a rozšiřitelnost¶
Shopify, Figma, Envoy Proxy a desítky dalších produktů používají Wasm jako plugin runtime. Důvod: zákazník může nahrát vlastní kód, který běží v sandboxu — bez rizika, že poškodí host aplikaci nebo přistoupí k datům jiných zákazníků.
V českém kontextu vidíme adopci v:
- ERP systémy — zákaznické kalkulace, validace, workflow hooky jako Wasm moduly místo embedded skriptů
- API gateway — custom auth, rate limiting, request transformation jako Wasm filtry (Envoy + proxy-wasm)
- SaaS platformy — tenant-specific business logic izolovaná v Wasm modulech
2. Edge computing a IoT¶
Wasm modul o velikosti 500 KB běží stejně na cloud serveru, edge node i embedded zařízení. Pro IoT a průmyslovou automatizaci to znamená:
- Jeden codebase pro cloud i edge — kompilace do Wasm eliminuje arch-specific buildy
- OTA updaty v řádu KB místo MB — push nový Wasm modul, ne celý container image
- Izolace na edge — více tenantů na jednom zařízení bez virtualizace
3. Finanční služby a regulované prostředí¶
Banky a pojišťovny oceňují Wasm kvůli auditovatelnosti a deterministickému chování:
- Wasm modul je hermeticky uzavřený — nemá side effects mimo explicitně povolené capability
- Reprodukovatelné buildy — stejný source → stejná binárka, auditovatelné end-to-end
- Formální verifikace — Wasm bytecode má jednodušší sémantiku než nativní kód, snáz se verifikuje
- Sandboxing bez VM overheadu — důležité pro low-latency trading a risk kalkulace
4. Serverless funkce nové generace¶
Fermyon Cloud, Cloudflare Workers a Fastly Compute@Edge ukazují budoucnost serverless: Wasm jako compute primitive místo kontejnerů. Výhody:
- Žádný cold start problém (sub-ms start)
- Hustější packing — 10× více instancí na stejný hardware
- Nižší cena — méně RAM, méně CPU idle time
- Lepší izolace — každý request v izolovaném Wasm instance
Spin Framework — praktická ukázka¶
Spin od Fermyonu je nejpopulárnější framework pro Wasm backend v roce 2026. Pojďme si ukázat, jak vypadá typická enterprise aplikace:
spin.toml — konfigurace aplikace¶
spin_manifest_version = 2
[application]
name = “core-analytics-api”
version = “1.2.0”
[[trigger.http]]
route = “/api/v1/score”
component = “scoring-engine”
[component.scoring-engine]
source = “target/wasm32-wasip2/release/scoring.wasm”
allowed_outbound_hosts = [“https://db.internal:5432”]
key_value_stores = [“default”]
[[trigger.http]]
route = “/api/v1/predict/…”
component = “ml-inference”
[component.ml-inference]
source = “components/ml_inference.wasm”
allowed_outbound_hosts = [“https://model-registry.internal”]
ai_models = [“llama-3”]
Klíčový detail: allowed_outbound_hosts — Wasm komponent může komunikovat pouze s explicitně povolenými hosty. Žádný modul nemůže „zavolat domů” nebo exfiltrovat data na neznámý endpoint.
SpinKube — Wasm v Kubernetes¶
Pro týmy, které už mají Kubernetes, SpinKube integruje Wasm workloady přímo do K8s ekosystému:
apiVersion: core.spinoperator.dev/v1alpha1
kind: SpinApp
metadata:
name: core-analytics
spec:
image: “ghcr.io/core-systems/analytics:1.2.0”
executor: containerd-shim-spin
replicas: 3
resources:
limits:
memory: “64Mi”
cpu: “500m”
Wasm workloady schedulované jako běžné K8s pody, ale s 10× nižšími resource limity. Stávající monitoring, networking a CI/CD pipeline fungují beze změny.
Bezpečnostní analýza — kde Wasm vyniká a kde ne¶
Wasm sandbox je silnější než většina alternativ, ale není stříbrná kulka:
Silné stránky¶
- Linear memory isolation: Každý modul má vlastní lineární paměť, nemůže přistoupit k paměti hostu ani jiných modulů
- No ambient authority: Žádné implicitní oprávnění — filesystem, síť, env vars vyžadují explicitní grant
- Kontrolovaný control flow: Wasm nemůže provádět arbitrary jumpy — jen strukturované control flow (if/loop/block)
- Typová bezpečnost: Všechny funkce mají explicitní typ, žádné type confusion útoky
- No JIT spraying: Moderní Wasm runtime používají konstantní hardening, eliminující JIT spray vektory
Známá omezení¶
- Side-channel útoky: Spectre/timing attacks jsou stále možné — Wasm sandbox nechrání před mikroarchitekturálními side channels
- Runtime bugy: Bug ve Wasmtime/WasmEdge = potenciální sandbox escape. Mitigace: aktualizace, security audity (Wasmtime prošel formální verifikací klíčových komponent)
- Supply chain: Wasm modul může obsahovat malware — sandbox zabrání přístupu k systému, ale ne zneužití povolených capability (např. exfiltrace dat přes povolený HTTP endpoint)
Migrace existujících služeb — praktický playbook¶
Přechod na Wasm backend není big-bang migrace. Doporučujeme inkrementální přístup:
- Fáze 1 — Plugin sandbox (týden 1-4): Identifikujte místa, kde běží nedůvěryhodný kód (zákaznické skripty, custom validace). Zabalte je do Wasm sandboxu. Žádná změna architektury, jen lepší izolace.
- Fáze 2 — Edge functions (týden 4-8): Přesuňte stateless HTTP handlers (API gateway filtry, A/B testing logic, auth middleware) do Wasm. Nasaďte na edge přes Spin nebo Cloudflare Workers.
- Fáze 3 — Nové služby (měsíc 2-6): Nové microservices budujte v Spin/wasi-http. Běží vedle existujících kontejnerů v K8s přes SpinKube. Stejné networking a monitoring.
- Fáze 4 — Postupná migrace (měsíc 6+): Vytipujte existující služby s vysokým request volume a nízkým cold start tolerance. Přepište do Wasm. Měřte TCO a latenci.
Jazyková podpora — co funguje v praxi¶
Ne všechny jazyky mají stejnou úroveň Wasm podpory:
| Jazyk | WASI 0.2 | Component Model | Produkční připravenost |
|---|---|---|---|
| Rust | ✅ plná | ✅ plná | 🟢 Excelentní — first-class target |
| Go (TinyGo) | ✅ plná | ⚠️ částečná | 🟡 Dobrá — goroutine omezení |
| C/C++ | ✅ plná | ✅ plná | 🟢 Excelentní — Emscripten/wasi-sdk |
| Python | ⚠️ componentize-py | ✅ plná | 🟡 Dobrá — startup overhead |
| JavaScript | ⚠️ StarlingMonkey | ⚠️ experimentální | 🟡 Dobrá — specifické runtime |
| C#/.NET | ✅ NativeAOT-LLVM | ⚠️ experimentální | 🟡 Zlepšuje se rychle |
| Zig | ✅ plná | ✅ plná | 🟢 Excelentní — zero-overhead |
Doporučení pro enterprise: Rust jako primární jazyk pro performance-critical komponenty. Python přes componentize-py pro ML inference a data processing. Go (TinyGo) pro týmy s existujícím Go codebase.
Ekonomika Wasm backendu — TCO analýza¶
Pro 100 microservices s průměrně 500 RPS/service:
| Položka | Kubernetes (kontejnery) | SpinKube (Wasm) |
|---|---|---|
| Compute (nodes) | 12× m5.xlarge | 4× m5.xlarge |
| Měsíční cloud cost | ~$4 200 | ~$1 400 |
| Cold start mitigace | $800 (provisioned capacity) | $0 |
| Celkem/měsíc | ~$5 000 | ~$1 400 |
| Úspora | — | 72 % |
Hlavní úspora pochází z hustšího packingu (3-4× méně RAM per instance) a eliminace cold start workaroundů. Disclaimer: Reálné čísla závisí na workload profilu — CPU-bound workloady mají menší rozdíl než memory-bound.
Co Wasm backend (zatím) neřeší¶
Upřímný pohled na limitace:
- Stateful workloady: Wasm moduly jsou designované jako stateless. Pro stateful logiku (websockety, streaming, in-memory cache) potřebujete external state management.
- Ekosystém knihoven: Ne každá knihovna kompiluje do Wasm. Specificky: vše co závisí na OS-specific syscalls, FFI do C knihoven, nebo threading (Wasm threads jsou stále experimentální).
- Debugging: Source maps a step-through debugging v Wasm jsou zlepšují, ale stále za nativním vývojářským zážitkem.
- GPU přístup: Pro ML inference potřebujete workaround (host function call do nativního GPU runtime). WASI-nn to řeší, ale je stále ve fázi proposal.
- Velké binárky: Python/JS Wasm moduly mohou být 20+ MB kvůli embedded interpreteru. Pro edge to může být problém.
Budoucnost: kam Wasm backend míří¶
Tři trendy, které sledujeme:
- Wasm + AI inference: WASI-nn a wasi:machine-learning otevřou cestu k sandboxovanému ML inference na edge. Představte si: ML model běží v Wasm sandboxu, nemá přístup k síti, zpracovává data lokálně.
- Wasm jako universal plugin format: Více a více aplikací (databáze, message brokery, API gateway) bude podporovat Wasm pluginy. PostgreSQL s Wasm extensions už existuje (plv8 → pglite → Wasm extensions).
- Decentralizované compute: Wasm portabilita + sandbox umožňuje trustless compute — spuštění cizího kódu na cizím hardware bez rizika. Implikace pro decentralizované cloudy a compute marketplaces.
Wasm backend: ne revoluce, ale evoluce¶
WebAssembly na serveru není náhrada Dockeru ani Kubernetes. Je to nová vrstva v toolboxu — silná tam, kde potřebujete sub-ms cold start, maximální izolaci, polyglot composability nebo hustý multi-tenant packing.
Náš přístup v CORE SYSTEMS: začínáme s plugin systémy a edge functions (nízké riziko, vysoká hodnota), a postupně rozšiřujeme na nové microservices. Existující infrastruktura zůstává — Wasm ji doplňuje, ne nahrazuje.
Chcete prozkoumat Wasm pro váš backend? Domluvte si konzultaci — pomůžeme identifikovat workloady, kde Wasm přinese největší hodnotu.