WebAssembly এখন ব্রাউজারের চেয়ে সার্ভার এবং এজ নোডগুলোতে (edge nodes) বেশি ব্যবহৃত হচ্ছে, এবং ৬৭% প্রতিষ্ঠান জানিয়েছে যে তারা এটি প্রোডাকশনে ব্যবহার করছে। দুই বছর আগে যা ছিল ৪৭%, সেই তুলনায় এই বৃদ্ধি Wasm-কে সার্ভারলেস ফাংশন এবং এজ-কম্পিউট ওয়ার্কলোডের জন্য মূলধারায় নিয়ে এসেছে।

এই পরিবর্তন কীভাবে ঘটল

যখন WebAssembly প্রথম আত্মপ্রকাশ করেছিল, তখন এর প্রতিশ্রুতি ছিল জাভাস্ক্রিপ্ট বাদে অন্যান্য ভাষায় লেখা কোড ব্রাউজারে দ্রুত ও নিরাপদে চালানোর একটি উপায় হিসেবে। শুরুর দিকের ব্যবহারকারীরা গেম এবং ভারী গ্রাফিক্স টুল তৈরি করেছিলেন, কিন্তু এর রানটাইম ব্রাউজার স্যান্ডবক্সের (sandbox) মধ্যেই সীমাবদ্ধ ছিল। গত কয়েক বছরে প্ল্যাটফর্মের বেশ কিছু উন্নতি—বিশেষ করে Component Model—বিভিন্ন ভাষার মধ্যে সমন্বয় করার পথ সহজ করে দিয়েছে, যা আগে Rust, Go বা অন্যান্য ভাষা একত্রে ব্যবহার করাকে অত্যন্ত জটিল করে তুলত।

একই সময়ে, ক্লাউড প্রোভাইডার এবং CDN-গুলো Wasm-ভিত্তিক এক্সিকিউশন এনভায়রনমেন্ট অফার করতে শুরু করে। ২০২৬ সালে, ব্রাউজারের তুলনায় সার্ভার এবং এজ-এ Wasm ওয়ার্কলোড বেশি চলছে।

এই সংখ্যাগুলোর তাৎপর্য কী

  • Cold-start time – একটি নতুন Wasm ইনস্ট্যান্স ১০ মিলিসেকেন্ডের কম সময়ে প্রস্তুত হতে পারে; যেখানে একটি সাধারণ Docker কন্টেইনার বুট হতে এখনও কয়েক সেকেন্ড সময় নেয়। রিকোয়েস্ট-চালিত API-এর ক্ষেত্রে এটি সরাসরি ব্যবহারকারীর অনুভূত ল্যাটেন্সিতে (latency) প্রভাব ফেলে।
  • Binary size – একটি Wasm মডিউল সাধারণত ২ MB থেকে ৫ MB-এর মধ্যে হয়। এর বিপরীতে একটি সমতুল্য Docker ইমেজ প্রায় ১০০ MB থেকে ২০০ MB পর্যন্ত হতে পারে, যা ব্যান্ডউইথ-সীমিত এজ লোকেশনগুলোর জন্য অত্যন্ত গুরুত্বপূর্ণ।
  • Safety – স্যান্ডবক্সড এক্সিকিউশন মডেলটি অনির্ভরযোগ্য কোডকে আলাদা রাখে, ফলে প্ল্যাটফর্মগুলো হোস্ট OS-কে ঝুঁকির মুখে না ফেলে মূল সার্ভিসের পাশাপাশি থার্ড-পার্টি প্লাগইন চালাতে পারে।
  • Portability – একটি মাত্র Wasm বাইনারি যেকোনো হোস্টের ওপর চলতে পারে যা এই স্পেসিফিকেশনটি অনুসরণ করে, তা সেটির অপারেটিং সিস্টেম বা ল্যাঙ্গুয়েজ ইকোসিস্টেম যাই হোক না কেন।

যেখানে Wasm অনন্য

Component Model একটি ভাষায় লেখা মডিউলকে একটি সুসংজ্ঞায়িত ইন্টারফেস প্রদান করতে সাহায্য করে যা অন্য কোনো ভাষা ইম্পোর্ট করতে পারে। এটি এমন প্লাগইন সিস্টেম তৈরি করাকে বাস্তবসম্মত করে তোলে যেখানে বিভিন্ন ভাষায় লেখা মডিউলগুলো কোনো কাস্টম গ্লু কোড (glue code) ছাড়াই একে অপরের সাথে কাজ করতে পারে।

বর্তমানে Wasm থেকে উপকৃত হয় এমন কিছু সাধারণ ক্ষেত্র হলো:

  • Edge functions যা HTTP রিকোয়েস্ট পরিবর্তন করে, অথেন্টিকেশন সম্পন্ন করে অথবা লাইটওয়েট AI ইনফারেন্স (inference) চালায়।
  • Plugin বা extension আর্কিটেকচার যেখানে থার্ড-পার্টি ডেভেলপাররা এমন বাইনারি জমা দেন যা অবশ্যই স্যান্ডবক্সড হতে হবে।
  • স্বল্পস্থায়ী, স্টেটলেস কম্পিউট (stateless compute) যেমন ইমেজ রিসাইজ করা, ডেটা ভ্যালিডেশন বা ফিচার-ফ্ল্যাগ মূল্যায়ন।

সীমাবদ্ধতা যা Docker-কে প্রাসঙ্গিক রাখে

Wasm কন্টেইনারের সর্বজনীন বিকল্প নয়। এর স্যান্ডবক্স সম্পূর্ণ অপারেটিং সিস্টেমকে উন্মুক্ত করে না, যার অর্থ হলো:

  • দীর্ঘস্থায়ী সার্ভিস যা মেমরি বা ডিস্কে স্টেট (state) সংরক্ষণ করে, সেগুলো এখনও কন্টেইনারকেই বেশি পছন্দ করে।
  • যেসব অ্যাপ্লিকেশনের সরাসরি GPU অ্যাক্সেস, বিশেষায়িত কার্নেল মডিউল বা গভীর সিস্টেম-লেভেল ইন্টিগ্রেশন প্রয়োজন, সেগুলো Docker বা অনুরূপ রানটাইমে সীমাবদ্ধ থাকে।

এই সীমাবদ্ধতার কারণে অনেক প্রতিষ্ঠান একটি হাইব্রিড স্ট্যাক ব্যবহার করে: দ্রুত ও সাশ্রয়ী এজ লেয়ারের জন্য Wasm এবং ভারী ব্যাক-এন্ড সার্ভিসের জন্য কন্টেইনার।

পরবর্তী দিকে যা লক্ষ্য রাখা প্রয়োজন

  • Tooling maturity – Wasm-এর জন্য ডিবাগিং, প্রোফাইলিং এবং অবজারভেবিলিটি (observability) টুলগুলো এখনও কয়েক দশকের পুরনো Docker ইকোসিস্টেমের সাথে তাল মেলাতে চেষ্টা করছে।

সারকথা

WebAssembly ব্রাউজারের একটি কৌতূহল থেকে আধুনিক সার্ভারলেস এবং এজ ইনফ্রাস্ট্রাকচারের একটি মূল উপাদানে পরিণত হয়েছে। এর গতি, ক্ষুদ্র আকার (tiny footprint) এবং বিল্ট-ইন আইসোলেশন একে এমন সব ওয়ার্কলোডের জন্য আদর্শ পছন্দ করে তোলে যা তাৎক্ষণিকভাবে শুরু হওয়া এবং এজ-এ সাশ্রয়ীভাবে চলার প্রয়োজন হয়। অন্য সব ক্ষেত্রে—যেমন স্টেটফুল সার্ভিস, GPU-নির্ভর কাজ বা গভীর OS ইন্টিগ্রেশন—কন্টেইনার এখনও সুবিধাজনক অবস্থানে রয়েছে।