WASM จะเข้ามาแทนที่คอนเทนเนอร์
(creston.blog)"WebAssembly คือ Write-Once-Run-Anywhere ที่แท้จริง" "พอถึงปี 2030 จะไม่มีใครจำ Kubernetes ได้อีกต่อไป"
การพกพา (Portability)
- คอนเทนเนอร์ได้แก้ปัญหามากมายในการพัฒนาซอฟต์แวร์ และใช้งานสะดวกกว่า VM
- แต่ในปัจจุบัน คอนเทนเนอร์กลับจัดการได้ยุ่งยากขึ้นจากเครื่องมือที่ซับซ้อนและการผูกติดกันอย่างแน่นแฟ้นระหว่างโปรแกรม-คอนเทนเนอร์-Linux
- นักพัฒนาต้องการโฟกัสกับการเขียนโค้ดและการดีพลอยฟีเจอร์ และการต้องเรียนรู้ Docker กลายเป็นสิ่งรบกวน
- WebAssembly (WASM) กำลังเข้ามาแทนที่คอนเทนเนอร์ในบางส่วนแล้ว และมอบประสบการณ์แบบ "เขียนครั้งเดียว รันได้ทุกที่"
- หลายภาษาสามารถคอมไพล์เป็น WASM ได้ และแม้การขาด system interface จะยังขัดขวางการยอมรับในวงกว้างอยู่ แต่ปัญหานี้น่าจะได้รับการแก้ไขในไม่ช้า
- ข้อจำกัดหลักของ WASM ในตอนนี้คือการขาด system interface เช่น การเข้าถึงไฟล์และระบบเครือข่าย แต่เป็นปัญหาที่จะถูกแก้ไขได้เมื่อเวลาผ่านไป
การเปรียบเทียบกับ JVM
- WASM มอบแนวคิด "เขียนครั้งเดียว รันได้ทุกที่" คล้ายกับ JVM แต่ JVM ไม่สามารถรันในเว็บเบราว์เซอร์ได้
- เว็บเบราว์เซอร์เป็นเป้าหมายสำคัญของการดีพลอยแอปพลิเคชัน และด้วยเหตุนี้นักพัฒนาจำนวนมากจึงหลีกเลี่ยง JVM
- ช่วงหลังมานี้ static binary compiler อย่าง GraalVM, Kotlin Native และ Scala Native กำลังกลายเป็นทางเลือกแทน JVM มากขึ้น
ไมโครเซอร์วิส (Microservices)
- ในสถาปัตยกรรมไมโครเซอร์วิส จะเชื่อมต่อบริการต่าง ๆ ผ่าน HTTP, RPC หรือ message broker
- ต้นทุนและปัญหาความน่าเชื่อถือของการสื่อสารผ่านเครือข่ายเป็นข้อเสียสำคัญ แต่บริษัทส่วนใหญ่มองว่าข้อดีมีมากกว่า
- เมื่อแพลตฟอร์ม serverless อย่าง AWS Lambda ถือกำเนิดขึ้น ไมโครเซอร์วิสก็สามารถดีพลอยในระดับฟังก์ชันเดี่ยวได้
- Cloudflare Workers ทำงานอยู่ภายใน V8 sandbox และสามารถเรียกใช้ฟังก์ชันในรันไทม์เดียวกันได้โดยไม่ต้องมี network request
- สิ่งนี้ทำให้ได้ทั้งข้อดีด้านการพัฒนาของไมโครเซอร์วิส และประสิทธิภาพรันไทม์แบบสถาปัตยกรรมโมโนลิธิกไปพร้อมกัน
- ผู้ให้บริการรายอื่นอย่าง Wasmer ก็เช่นกัน กำลังพัฒนาโซลูชันที่อิงกับ WASM อยู่
การยอมรับ WASM (Adoption)
- WASM ยังเป็นเทคโนโลยีระยะเริ่มต้น แต่กำลังพัฒนาอย่างรวดเร็ว และแนวโน้มการรองรับก็เพิ่มขึ้นเรื่อย ๆ
- ตอนนี้มันยังทำงานได้ไม่สมบูรณ์แบบในทุกสภาพแวดล้อม แต่สามารถสัมผัสภาพอนาคตได้ล่วงหน้าผ่านแพลตฟอร์มอย่าง Cloudflare
- หากคุณเป็นผู้ใช้ภาษาสคริปต์แบบไดนามิกอย่าง Python, Ruby หรือ PHP การเรียนรู้ภาษาแบบคอมไพล์อย่าง Go หรือ Rust เพิ่มเติมระหว่างรอให้ WASM พัฒนาเต็มที่ก็จะเป็นประโยชน์
8 ความคิดเห็น
K8s เป็นเครื่องมือสำหรับ orchestration ของคอนเทนเนอร์ แล้วเพราะ wasm มันจะทำให้ประสิทธิผลลดลงหรือเปล่า? ถ้าเป็น Docker ก็น่าจะถูกแย่งพื้นที่ไปได้พอสมควร แต่....
WASM ก็เหมือนเครื่องพิมพ์ 3 มิติแบบใหม่ มีแต่คนบอกว่า "โลกใหม่กำลังมา" แต่เอาเข้าจริงกลับแทบไม่มีใครใช้...
ที่นี่มีการรวบรวมกรณีการนำไปใช้งานอยู่
(ส่วนตัวแล้ว) ผมคิดว่าสาขาอย่าง CAD หรือการประมวลผลภาพดูเข้าท่าที่สุด
มันทำให้นึกถึงทีมพัฒนาโซลูชันที่เคยกังวลเรื่องการทำภาพการแพทย์ความละเอียดสูงบนเว็บขึ้นมาเลย
ลองทำตามดูครับ
แม้จะถึงปี 2030 ก็ดูเหมือนว่า k8s จะยังคงแข็งแกร่งอยู่
สรุปแล้วเราจำเป็นต้องรู้ทั้ง Docker และ WASM เลยใช่ไหมครับ 555 แต่พอเทคโนโลยีของ Docker ค่อย ๆ สุกงอมขึ้น การเข้าถึงก็ง่ายขึ้นด้วย เลยคิดว่า WASM ก็น่าจะไปในทิศทางที่เข้าถึงได้ง่ายขึ้นคล้าย ๆ กัน
ท้ายที่สุดแล้วมันก็ดูเหมือนจะอาศัยประสิทธิภาพของรันไทม์ wasm อยู่ดี แบบนี้ V8 จะกลายเป็นชั้นเดียวกับ JVM หรือเปล่าครับ
ผมกังวลว่าในอนาคตเราอาจต้องเจอกับสถานการณ์ที่การทำงานของ WASM เปลี่ยนไปตามเวอร์ชันของ V8 และต้องคอยดีบักสิ่งนั้น
ความคิดเห็นจาก Hacker News