ทำไมเกิด#

ปัญหาของ AWS ในปี 2017 คือ — Lambda รันบน container (Docker) แต่ container แบ่ง kernel ใช้กับเพื่อนบ้าน. ถ้าใครเจอช่องโหว่ของ kernel = หลุดออกจาก container ตัวเองไปอ่าน memory ของคนอื่นได้

ใน AWS Lambda workload ของลูกค้าหลายเจ้าวิ่งอยู่บน physical server เครื่องเดียวกัน. ถ้า isolation พังครั้งเดียว = ข้อมูลลูกค้าทุกเจ้าหลุดหมด — นี่เป็น risk ที่ AWS รับไม่ได้

ทางเลือกตอนนั้นมี 2 ทาง — (1) ใช้ VM ปกติ (boot เป็นนาที + กิน RAM 1 GB+) = ช้าเกินสำหรับ serverless. (2) อยู่กับ container ต่อ = security risk

AWS เลยสร้างทางที่ 3 ขึ้นมาเอง — MicroVM — เอา KVM (hypervisor ของ Linux) มาตัด feature ที่ไม่จำเป็นออกหมด เหลือแค่ที่ Lambda ต้องการจริงๆ. ผลที่ได้คือ VM ที่บูตใน 125 มิลลิวินาที กิน RAM overhead แค่ ~5 MB

Firecracker ทำงานยังไง#

Firecracker เป็น Virtual Machine Monitor (VMM) เขียนด้วย Rust รันบน Linux ใช้ KVM อยู่ใต้ฝา. ทุก Lambda function ของคุณ = 1 MicroVM ที่บูตเฉพาะตอนที่มี request เข้ามา

• เริ่มจาก minimal Linux kernel (~5 MB)
• ไม่มี driver ที่ไม่จำเป็น (เช่น USB, GPU, audio — ไม่ใช้ใน serverless)
• ไม่มี shell, ไม่มี package manager
• มี API endpoint เดียวที่ Firecracker control ได้

ใครใช้#

• AWS Lambda — ตั้งแต่ปี 2018 ทุก function รันอยู่บน Firecracker
• AWS Fargate — container แบบ “managed” — รันอยู่บน Firecracker ใต้ฝา
• Fly.io — startup ที่สร้าง platform ทั้งหมดอยู่บน Firecracker (deploy app ไปทุก region ของโลกได้ด้วย 1 คำสั่ง)
• Kata Containers — project ของ OpenInfra Foundation ที่ใช้ MicroVM (รวมถึง Firecracker) มาห่อ container ให้ปลอดภัยขึ้น

Trade-off#

ข้อดี:

• มี hardware isolation ของ VM (kernel แยกขาดเต็มตัว — ปลอดภัยกว่า container เยอะ)
• บูตเร็วใกล้เคียง container (~125 ms)
• กิน RAM น้อยกว่า VM แบบเดิม 100 เท่า

ข้อเสีย:

• ยังหนักกว่า container อยู่ดี (cold start ระดับ 1 ms ทำไม่ได้)
• Ecosystem แคบกว่า Docker (tool ที่มีให้ใช้น้อยกว่า)
• ตั้ง setup ซับซ้อนกว่า — ไม่เหมาะให้ dev เอามารันบน laptop ของตัวเอง

ที่ผู้บริหารควรจำ: Firecracker คือเหตุผลที่ AWS Lambda ปลอดภัยกว่า self-hosted FaaS เจ้าอื่นที่ยังรันบน Docker เพราะ AWS แก้ปัญหา multi-tenant isolation ที่ระดับ hardware-level VM ไม่ใช่แค่ kernel-level container

ทำไมเกิด#

ปี 2015 — Mozilla / Google / Microsoft / Apple จับมือกันสร้าง standard ใหม่ที่ทำให้ browser รันโค้ดของภาษาอื่น (ไม่ใช่แค่ JavaScript) ได้เร็วใกล้เคียง native

ปี 2017 — Wasm 1.0 ออก browser ทุกตัวรองรับ

ปี 2019 — Mozilla ออก WASI (WebAssembly System Interface) — มาตรฐานที่ทำให้ Wasm รันนอก browser ได้ ทั้งบน server, บน edge, บน IoT device

ตั้งแต่นั้นมา Wasm ก็กลายเป็น portable runtime ที่เร็วที่สุด ของยุคนี้ — เขียน Rust / Go / C++ / AssemblyScript ครั้งเดียว compile เป็น .wasm รันได้ทุกที่ที่มี Wasm runtime

Wasm ทำงานยังไง#

Wasm = stack-based virtual machine ที่มี bytecode ของตัวเอง คอมไพล์ภาษาระดับสูง (Rust, Go, C++) ออกมาเป็น .wasm file → Wasm runtime อ่าน bytecode → execute ใน sandbox ที่แยกขาดจาก host

ที่ต่างจาก container/VM:

• ไม่มี OS — ไม่ต้องบูต Linux, ไม่มี kernel, ไม่มี file system (เว้นแต่ host จะ inject เข้ามาให้)
• ไม่มี process — มีแค่ function ที่ execute
• Cold start อยู่ที่ ~5 ms (เทียบกับ Lambda 200-2000 ms)
• กิน RAM ~1 MB (เทียบกับ container 50-500 MB)

ใครใช้#

ที่ edge (พระเอกหลัก):

• Cloudflare Workers — V8 isolate + Wasm รันอยู่ใน 200+ city ทั่วโลก
• Fastly Compute@Edge — Wasm runtime ของ Fastly เอง
• Vercel Edge Functions — V8 isolate, ใช้งานกับ Wasm ได้
• Deno Deploy — แพทเทิร์นเดียวกับ Cloudflare Workers

ที่เป็น plugin system:

• Figma plugins — เขียน plugin เป็น Wasm = ปลอดภัยกว่า native JS plugin
• Shopify Functions — ให้ merchant ปรับแต่ง checkout logic ผ่าน Wasm
• Envoy proxy filters — extension ของ service mesh

ที่ database:

• Cloudflare D1 — SQLite รันอยู่ใน Wasm
• TursoDB — libSQL อยู่บน Wasm
• DuckDB-WASM — analytics database ที่รันใน browser

ที่ AI:

• WasmEdge — runtime สำหรับ AI inference ที่ edge
• ONNX Runtime Web — รัน ML model ใน browser ผ่าน Wasm

Trade-off#

ข้อดี:

• เบามาก เร็วมาก (cold start ~5 ms = “ใกล้ 0” ในแง่ user experience)
• Portable — เขียนครั้งเดียวรันได้ทุก runtime
• Secure by default — sandbox ที่ปฏิเสธทุก system call (host ต้องอนุญาตอะไรต้อง explicit)
• ไม่มี cold start แบบ Lambda — เพราะไม่ต้องบูตอะไรเลย

ข้อเสีย:

• WASI ยังเด็ก — feature ที่ Linux มี Wasm อาจยังไม่มี (เช่น native threading)
• Filesystem access จำกัด (ขึ้นอยู่กับ host implementation)
• Ecosystem ของ library ยังเล็กกว่าฝั่ง Node.js/Python อยู่มาก
• Tool สำหรับ debug ยังไม่ค่อยพร้อม

ที่ผู้บริหารควรจำ: ถ้าคุณใช้ Cloudflare หรือ Vercel อยู่ — workload ของคุณก็รันอยู่บน Wasm อยู่แล้ว แม้คุณจะเขียน JavaScript ก็ตาม (V8 isolate คอมไพล์ JS เป็น bytecode คล้าย Wasm) Cold start ที่เกือบ 0 ms = ปลดล็อก UX ที่ทำไม่ได้บน Lambda

ทำไมเกิด#

ปัญหาของ OS แบบเดิม (Linux) — มี driver + service + tool เป็นพันตัว ส่วนใหญ่ app ไม่ได้ใช้ แต่ติดมาด้วย attack surface = ใหญ่กว่าที่ควรเป็นเยอะ

Unikernel ตั้งคำถามว่า — ทำไมต้องมีของที่ไม่ได้ใช้ ถ้า app ของคุณคือ web server — จะมี driver ของ USB ทำไม print ทำไม sound ทำไม package manager ทำไม shell ทำไม

ตัด ตัด ตัด — เหลือแค่ kernel ที่ใช้จริง + app = single binary ที่บูตในระดับมิลลิวินาทีบน hypervisor

ตัวอย่างที่จริงมี#

• MirageOS — เขียนด้วย OCaml (จาก University of Cambridge + Docker)
• IncludeOS — เขียนด้วย C++
• Nanos — unikernel ยุคใหม่ ทำงานเข้ากับ AWS/GCP ได้ดี
• OSv — unikernel ที่เข้ากันได้กับ Linux ของ Cloudius Systems

ใครใช้จริง#

ความจริงที่ต้องบอกตรงๆ คือ — ยังไม่มี mainstream adoption. Unikernel เป็น “concept ที่ดูดีในตำรา” แต่ในทางปฏิบัติเจอปัญหา 3 อย่าง:

1. Debug ยาก — เกิด bug ใน production แล้ว ssh เข้าไปดูไม่ได้ (ไม่มี shell)
2. Update ยาก — เปลี่ยน config = ต้องคอมไพล์ใหม่ทั้งระบบ
3. Tool ecosystem เล็กมาก — ไม่มี Datadog agent, ไม่มี Splunk forwarder ที่พอร์ตมาให้

มี niche ที่ unikernel เหมาะอยู่บ้าง:

• Embedded / IoT — ที่ทรัพยากรจำกัดสุดๆ และไม่ค่อย update
• Security-critical workload — ที่ต้องการ attack surface เล็กที่สุด
• High-frequency trading — ที่ต้องการ boot < 1 ms

แต่สำหรับ enterprise web app ทั่วไป — unikernel ไม่ใช่คำตอบ. ความซับซ้อนของการดูแลแพงกว่าประโยชน์ที่ได้

Trade-off#

ข้อดี:

• Attack surface เล็กที่สุดในวงการ
• บูตเร็วที่สุด (microsecond)
• Memory footprint เล็กที่สุด

ข้อเสีย:

• Debug = ฝันร้าย
• Update = ต้องคอมไพล์ใหม่ทั้งระบบ
• Tool ecosystem แทบไม่มี
• ต้องการ expertise ที่หาคนทำได้ยาก

ที่ผู้บริหารควรจำ: Unikernel = ของสำหรับเคสพิเศษมากๆ ถ้าคุณไม่ใช่ defense contractor ไม่ใช่ HFT firm ไม่ใช่ IoT manufacturer — ไม่ต้องสนใจ เอาเวลาที่จะอ่านเรื่อง unikernel ไปอ่าน Wasm ดีกว่า

Trend 1 — Vendor ขยับไปทาง Wasm#

• Cloudflare ผลักหนักให้มอง workload ทั้งหมดเป็น Wasm — D1 (database), Workers (compute), R2 (storage with Workers triggers)
• AWS เริ่มทดลอง Wasm ใน CloudFront Functions
• Fastly ทำ Compute@Edge ที่เป็น Wasm-first
• Vercel ขยับจาก Lambda ไป Edge Functions (V8 isolate)

ถ้า workload ของบริษัทคุณอยู่บน Cloudflare หรือ Vercel — คุณก็ใช้ Wasm อยู่แล้ว แค่ไม่รู้ตัว

Trend 2 — Edge computing โต = Wasm โตตาม#

Edge computing โตขึ้นเรื่อยๆ เพราะ:

• ลูกค้าไทยเข้าเว็บที่ host อยู่ใน US = latency 200+ ms
• Edge function ที่รันใน Singapore/Bangkok = 5-20 ms
• AI inference ที่ edge = ตอบเร็วกว่า + ไม่ต้องส่งข้อมูลขึ้น central cloud (PDPA-friendly)

Edge ใช้ Wasm เกือบ 100% เพราะ container/VM ไม่สามารถ scale ระดับ 200+ city ได้

Trend 3 — Cost model เปลี่ยน#

• Lambda — cold start 200-2000 ms = ลูกค้ารอ = UX แย่
• Lambda — billing = ปัดขึ้นไปที่ 1 ms ใกล้สุด = ต้องจ่ายค่า cold start ด้วย
• Workers — cold start ~5 ms = “ใกล้ 0” จริงๆ
• Workers — billing = คิดตาม compute time จริง = ถูกกว่า Lambda 5-10 เท่าสำหรับ workload เดียวกัน

ถ้า workload ของคุณ traffic ไม่สม่ำเสมอ (เช่น API ที่ peak ตอน 9 โมงเช้า) — Workers/Edge Functions จะถูกกว่า Lambda เยอะมาก