WASM कंटेनरों की जगह ले लेगा

"WebAssembly वास्तव में Write-Once-Run-Anywhere है" "2030 तक किसी को Kubernetes याद नहीं रहेगा"

पोर्टेबिलिटी (Portability)

• कंटेनरों ने सॉफ्टवेयर डेवलपमेंट की कई समस्याएँ हल कीं और VM की तुलना में अधिक उपयोगी साबित हुए
• लेकिन आज कंटेनरों को जटिल टूल्स और program-container-Linux के मजबूत coupling की वजह से संभालना झंझटभरा हो गया है
• डेवलपर्स कोड लिखने और फीचर्स डिप्लॉय करने पर ध्यान देना चाहते हैं, और Docker सीखना एक रुकावट बन जाता है
• WebAssembly(WASM) पहले से ही कुछ क्षेत्रों में कंटेनरों की जगह ले रहा है और "एक बार लिखो, कहीं भी चलाओ" जैसा अनुभव देता है
• कई भाषाओं को WASM में compile किया जा सकता है, और system interface की कमी व्यापक adoption को रोक रही है, लेकिन यह जल्द हल हो जाएगी
• अभी WASM की सबसे बड़ी सीमा file access, networking जैसी system interfaces की कमी है, लेकिन समय के साथ यह समस्या भी हल हो जाएगी

JVM से तुलना

• WASM, JVM की तरह "एक बार लिखो, कहीं भी चलाओ" की अवधारणा देता है, लेकिन JVM web browser में नहीं चलता
• web browser applications deploy करने का एक महत्वपूर्ण target है, और इसी वजह से कई डेवलपर्स JVM से बचते हैं
• हाल में GraalVM, Kotlin Native, Scala Native जैसे static binary compilers, JVM के विकल्प के रूप में उभर रहे हैं

माइक्रोसर्विसेस (Microservices)

• माइक्रोसर्विस आर्किटेक्चर में services को HTTP, RPC या message broker के जरिए जोड़ा जाता है
• network communication की लागत और reliability से जुड़ी समस्याएँ बड़ी कमियाँ हैं, लेकिन ज़्यादातर कंपनियाँ मानती हैं कि इसके फायदे अधिक हैं
• AWS Lambda जैसे serverless platforms के आने से माइक्रोसर्विसेस को individual function unit के रूप में deploy करना संभव हुआ
• Cloudflare Workers, V8 sandbox के भीतर चलते हैं, और network request के बिना उसी runtime में function call करना संभव बनाते हैं
• इससे माइक्रोसर्विसेस के development फायदे और monolithic architecture की runtime performance, दोनों एक साथ मिलती हैं
• Wasmer जैसी अन्य कंपनियाँ भी WASM-आधारित solutions विकसित कर रही हैं

WASM का अपनाया जाना (Adoption)

• WASM अभी शुरुआती चरण की तकनीक है, लेकिन यह तेज़ी से विकसित हो रही है और इसका समर्थन भी बढ़ रहा है
• फिलहाल यह हर environment में पूरी तरह काम नहीं करता, लेकिन Cloudflare जैसे platforms के जरिए इसके भविष्य की झलक अभी से देखी जा सकती है
• अगर आप Python, Ruby, PHP जैसी dynamic languages का उपयोग करते हैं, तो WASM के और विकसित होने का इंतज़ार करते हुए Go या Rust जैसी compiled languages भी सीखना फायदेमंद होगा

[bus710]

K8s कंटेनरों को orchestrate करने का एक टूल है, लेकिन क्या wasm की वजह से इसकी प्रभावशीलता कम हो जाएगी? Docker के मामले में तो कुछ हद तक असर पड़ेगा, लेकिन....

[colus001]

WASM एक नए 3D प्रिंटर जैसा लगता है। कहते हैं, "एक नई दुनिया आ रही है", लेकिन वास्तव में इसे इस्तेमाल करने वाले लोग ज़्यादा नहीं हैं...

[halfenif]

https://madewithwebassembly.com/

यहाँ implementation examples का एक संग्रह है।

(व्यक्तिगत रूप से) मुझे लगता है कि मुख्य रूप से CAD या image processing जैसे क्षेत्र सबसे ज़्यादा उपयुक्त लगते हैं।

इससे मुझे पहले की एक solution development team याद आ जाती है, जो web पर high-resolution medical images को implement करने को लेकर सोच-विचार कर रही थी।

[halfenif]

उदाहरण के साथ WASM सीखें
https://hi.news.hada.io/topic?id=11891

देखकर साथ में करके देखता हूँ।

[jujumilk3]

लगता है 2030 में भी k8s मज़बूती से बना रहेगा

[yangeok]

आख़िरकार क्या हमें docker और wasm दोनों सीखने पड़ेंगे? haha फिर भी, जैसे-जैसे docker तकनीक के रूप में परिपक्व हुआ, उसे अपनाना आसान हो गया, इसलिए मुझे लगता है कि wasm भी शायद उसी तरह आसान पहुँच वाली दिशा में जाएगा।

[clickin]

आख़िरकार यह wasm runtime performance पर निर्भर दिखता है, तो क्या V8, JVM के समान स्तर की परत नहीं बन जाएगा?
मुझे चिंता है कि V8 version के अनुसार WASM का व्यवहार बदलता रहेगा, और फिर उसका debugging करने वाला भविष्य हमारा इंतज़ार कर रहा होगा।

[GN⁺]

Hacker News राय

• सिस्टम इंटरफ़ेस की कमी व्यापक अपनाने में रुकावट डालने वाला प्रमुख कारण है। फ़ाइल access, networking आदि समय के साथ एकीकृत हो जाएंगे
  • लेकिन फ़ाइल access, networking आदि जोड़ने से security vulnerabilities पैदा हो सकती हैं। यही वह कारण था जिसने Java के 'write once, run anywhere' वादे को कमज़ोर कर दिया
  • WASM कंटेनरों से अलग समस्या हल करता है। WASM sandboxed code execution के लिए कुशल है
  • WASM के Functions-as-a-Service implementations आदि में standard बनने की संभावना अधिक है
  • कंटेनर उस समस्या को हल नहीं करते। वे security boundary के रूप में उपयुक्त नहीं हैं, और WASM binaries की तुलना में भारी हैं तथा उनका startup cost अधिक है
  • कंटेनर कई processes, threads चलाने और OS की मूल सुविधाओं का उपयोग करने के लिए उपयुक्त हैं
• WebAssembly सच्चा 'write once, run anywhere' अनुभव प्रदान करता है
  • लेकिन बाहरी दुनिया के साथ interact करते ही स्थिति बदल जाती है। हर V8 runtime का interface थोड़ा अलग होता है
  • Docker की सफलता इसलिए थी क्योंकि POSIX पहले से स्थापित standard था
• PlatformOps (पहले का DevOps, SRE, Ops) का वादा जटिल tools और program-container-Linux के कड़े coupling की वजह से कमज़ोर हो गया है
  • डेवलपर code लिखना और features deploy करना चाहते हैं
  • PlatformOps इन समस्याओं को हल करने के लिए संघर्ष करता है
• WASM कंटेनरों को replace करने वाला solution नहीं है। कंटेनर PHP के अलग-अलग versions को बिना conflict के चलाने की समस्या हल करते हैं
  • WASM उस समस्या को हल नहीं करता
• WASM का भविष्य कब आएगा? 8 साल बीत गए, लेकिन stable और उपयोग में आसान toolchain नहीं है
  • Rust 2012 में जारी हुआ था और 8 साल बाद stable था
• WASM वास्तविक hardware पर नहीं चलता। इसे virtual machine माना जा सकता है
  • कंटेनर उन applications को package करते हैं जो सीधे वास्तविक hardware पर चलती हैं
  • WASM को runtime की ज़रूरत होती है। यह application के भीतर चलता है
  • WASM JVM और .NET द्वारा हल की जाने वाली 'portability' समस्या को हल करता है
  • कंटेनर application और dependencies को bundle में बांधते हैं
  • ये तकनीकें एक-दूसरे की पूरक हो सकती हैं
• Docker इस्तेमाल करना सीखना कोई बाधा नहीं है
  • सिर्फ Dockerfile होना काफ़ी है
  • WASM apps को अब भी Kubernetes की ज़रूरत होती है
  • WebAssembly अगले 5 साल में बहुत अधिक नहीं बढ़ेगा
• WASM एक और abstraction layer है। यह सब कुछ replace करेगा या नहीं, यह दूसरे solutions के साथ होने वाले trade-offs पर निर्भर करता है