Bạn có một cụm microservice nhỏ: mỗi service làm một việc, stateless, xử lý request trong vài chục millisecond. Nhưng hóa đơn cloud thì không nhỏ. Mỗi container chiếm vài trăm MB RAM dù chỉ để chạy một hàm validate hay transform JSON. Scale-to-zero thì dính cold start hàng giây. Bạn nhìn vào dashboard và tự hỏi: có cách nào đóng gói mấy service này nhẹ hơn không?
Năm 2026, câu trả lời nghiêm túc là: có, với WebAssembly. Nhưng chỉ cho một lớp workload cụ thể — và biết ranh giới đó nằm đâu quan trọng hơn là biết Wasm nhanh cỡ nào.
Điều gì đã thay đổi trong 12 tháng qua
Wasm server-side không mới. Cái mới là ba mảnh ghép cuối cùng đã vào chỗ:
WASI đạt độ chín. WASI (WebAssembly System Interface) là lớp chuẩn cho module Wasm nói chuyện với thế giới bên ngoài — filesystem, network, clock — mà không phá sandbox. Trước đây WASI là mớ preview chắp vá; giờ nó đủ ổn định để runtime như Wasmtime, WasmEdge chạy production mà không phải vá bằng API riêng.
Component Model cho phép ghép module đa ngôn ngữ. Đây là mảnh quan trọng nhất. Một component viết bằng Rust có thể gọi component viết bằng Go hoặc Python qua interface được định nghĩa bằng WIT (Wasm Interface Type), không cần serialize qua HTTP hay gRPC. Nghĩ như dependency injection, nhưng dependency có thể được compile từ ngôn ngữ khác và chạy trong sandbox riêng.
Cả ba cloud lớn đều có serverless nền Wasm. AWS, GCP, Azure đều đã đưa Wasm serverless function thành offering mainstream trong 2026. Đây là tín hiệu quan trọng với kiến trúc sư: bạn không còn phải tự vận hành runtime hay đặt cược vào một startup. Đường thoát (exit path) đã có.
Con số đáng để bạn dừng lại
Hai con số làm nên khác biệt thực tế:
| Tiêu chí | Container (Node.js) | Wasm module |
|---|---|---|
| Cold start | vài trăm ms đến vài giây | 1-5ms (~100x nhanh hơn) |
| Bộ nhớ mỗi instance | vài trăm MB | ~1/10 process Node.js |
| Isolation | namespace + cgroup | sandbox theo thiết kế |
| Kích thước artifact | hàng trăm MB image | vài MB module |
Cold start 1-5ms nghĩa là scale-to-zero trở thành mặc định chứ không phải trade-off. Bạn không cần giữ instance ấm, không cần provisioned concurrency, không cần mấy trò ping giữ warm.
Bộ nhớ 1/10 nghĩa là mật độ tenant cao hơn hẳn trên cùng một node. Chỗ mà một node chạy được 20 container Node.js, cùng node đó chạy được vài trăm Wasm instance. Với nền tảng multi-tenant hoặc SaaS có nhiều customer nhỏ, đây là khác biệt trực tiếp trên hóa đơn — nhất là khi CPU utilization trung bình toàn ngành đang rớt còn một chữ số và lãng phí cloud là chuyện ai cũng thấy nhưng ít ai xử được.
Ba use case đã chín — và những chỗ chưa nên đụng
Chín: edge function
Cold start millisecond là lý do Cloudflare Workers và các nền tảng edge chọn kiến trúc isolate/Wasm từ đầu. Nếu workload của bạn là HTTP API ngắn, auth check, A/B routing, transform response — edge + Wasm gần như là mặc định 2026.
Chín: plugin system an toàn
Bạn cần cho khách hàng hoặc bên thứ ba chạy code trong hệ thống của mình? Trước đây lựa chọn là: chạy container riêng (nặng), chạy VM (nặng hơn), hoặc eval trong process (cầu nguyện). Wasm sandbox giải đúng bài này: plugin chỉ thấy đúng interface bạn export, không có syscall, không có network trừ khi bạn cho. Đây là use case mà Wasm không có đối thủ thực sự.
// Interface WIT: host chỉ expose đúng những gì plugin được phép làm
// plugin.wit
interface transformer {
transform: func(input: string) -> result<string, string>;
}
// Plugin viết bằng Rust, Go hay Python đều compile về cùng interface này.
// Không filesystem, không network — trừ khi host cấp quyền tường minh.
Chín: microservice stateless nhẹ
Validate, transform, routing, tính toán thuần — những service mà logic gói gọn trong request/response, không giữ connection pool, không cần local state. Đóng gói thành Wasm component, deploy lên runtime Wasm, và tận hưởng mật độ.
Chưa nên: workload cần thread, GPU, hoặc syscall phức tạp
Threading trong Wasm vẫn chưa trơn. GPU access thì gần như chưa có gì dùng được production. Service cần filesystem phức tạp, raw socket, hoặc thư viện native (image processing bằng libvips, ML inference bằng CUDA) — cứ để yên trong container. Đây không phải hạn chế tạm thời kiểu "chờ bản sau"; nó đụng vào chính mô hình sandbox của Wasm.
Hệ sinh thái thư viện còn mỏng cũng là ma sát thật. Rust compile sang Wasm mượt nhất; Go và Python đã dùng được nhưng bạn sẽ gặp thư viện chưa hỗ trợ WASI thường xuyên hơn mong muốn. Đừng đánh giá thấp chi phí này khi ước lượng effort.
Wasm gặp micro-frontend
Một hướng ít người để ý: micro-frontend 2026 bắt đầu kết hợp edge + Wasm component. Ý tưởng là những module tính toán nặng phía client — analytics engine, chart rendering, xử lý dữ liệu lớn trong browser — được đóng gói thành Wasm component và tái sử dụng cả hai phía: chạy trong browser cho tương tác tức thì, chạy trên edge cho pre-computation. Cùng một artifact, hai môi trường. Với team đang đau đầu vì duplicate logic giữa client và server, đây là góc đáng theo dõi.
Lộ trình thí điểm: đo trước, cam kết sau
Đừng bắt đầu bằng việc "chuyển hết sang Wasm". Bắt đầu bằng một phép đo:
- Chọn một service stateless trong hệ thống hiện tại — ưu tiên service viết bằng ngôn ngữ compile tốt sang Wasm (Rust, Go), logic thuần, ít dependency native.
- Port sang Wasm component, deploy lên runtime (Wasmtime/WasmEdge tự vận hành, hoặc offering Wasm serverless của cloud bạn đang dùng).
- Đo ba thứ so với container hiện tại: cold start p50/p99, memory per instance dưới tải thật, và chi phí quy đổi trên cùng lượng traffic.
- Ghi lại ma sát: thư viện nào thiếu, debug tooling khác gì, CI/CD phải đổi những bước nào.
Nếu con số đẹp và ma sát chịu được, mở rộng dần sang các service cùng lớp. Nếu không — bạn mất vài tuần và thu về một data point rẻ, thay vì một quyết định kiến trúc đắt.
Wasm server-side 2026 không phải "Docker killer". Nó là công cụ đúng cho lớp workload mà container luôn quá nặng: nhỏ, stateless, cần isolation, cần mật độ. Kiến trúc sư giỏi năm nay không phải người chọn phe Wasm hay container — mà là người vẽ được ranh giới giữa hai bên bằng số đo của chính hệ thống mình.
