WebAssembly ಈಗ ಬ್ರೌಸರ್ಗಳಿಗಿಂತ ಹೆಚ್ಚು ಸರ್ವರ್ಗಳು ಮತ್ತು ಎಡ್ಜ್ ನೋಡ್ಗಳಲ್ಲಿ (edge nodes) ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ, ಮತ್ತು ಶೇಕಡಾ 67 ರಷ್ಟು ಸಂಸ್ಥೆಗಳು ಇದನ್ನು ಪ್ರೊಡಕ್ಷನ್ನಲ್ಲಿ ಬಳಸುತ್ತಿವೆ ಎಂದು ಹೇಳುತ್ತವೆ. ಎರಡು ವರ್ಷಗಳ ಹಿಂದೆ ಇದ್ದ ಶೇಕಡಾ 47 ರಷ್ಟು ಪ್ರಮಾಣದಿಂದ ಈಗಿನ ಏರಿಕೆಯು, ಸರ್ವರ್ಲೆಸ್ ಫಂಕ್ಷನ್ಗಳು (serverless functions) ಮತ್ತು ಎಡ್ಜ್-ಕಂಪ್ಯೂಟ್ ವರ್ಕ್ಲೋಡ್ಗಳಿಗಾಗಿ Wasm ಅನ್ನು ಮುಖ್ಯವಾಹಿನಿಗೆ ತಂದಿದೆ.
ಈ ಬದಲಾವಣೆ ಹೇಗೆ ಸಂಭವಿಸಿತು
WebAssembly ಮೊದಲು ಕಾಣಿಸಿಕೊಂಡಾಗ, ಅದರ ಭರವಸೆಯೆಂದರೆ JavaScript ಅಲ್ಲದ ಇತರ ಭಾಷೆಗಳಲ್ಲಿ ಬರೆಯಲಾದ ಕೋಡ್ ಅನ್ನು ಬ್ರೌಸರ್ಗಳಲ್ಲಿ ವೇಗವಾಗಿ ಮತ್ತು ಸುರಕ್ಷಿತವಾಗಿ ಚಲಾಯಿಸುವ ಮಾರ್ಗವನ್ನು ಒದಗಿಸುವುದು. ಆರಂಭಿಕ ಬಳಕೆದಾರರು ಗೇಮ್ಗಳು ಮತ್ತು ಭಾರೀ ಗ್ರಾಫಿಕ್ಸ್ ಪರಿಕರಗಳನ್ನು ನಿರ್ಮಿಸಿದರು, ಆದರೆ ರನ್ಟೈಮ್ (runtime) ಬ್ರೌಸರ್ ಸ್ಯಾಂಡ್ಬಾಕ್ನಲ್ಲೇ ಉಳಿಯಿತು. ಕಳೆದ ಕೆಲವು ವರ್ಷಗಳಲ್ಲಿ, ಪ್ಲಾಟ್ಫಾರ್ಮ್ ಸುಧಾರಣೆಗಳ ಸರಣಿ—ಮುಖ್ಯವಾಗಿ Component Model—Rust, Go ಅಥವಾ ಇತರ ಭಾಷೆಗಳನ್ನು ಬೆರೆಸುವುದು ಒಂದು ದುಸ್ತರ ಕೆಲಸವಾಗಿದ್ದ ಕಾಲದ ಅಡೆತಡೆಗಳಿಲ್ಲದೆ, ಭಾಷೆಗಳ ನಡುವಿನ ಏಕೀಕರಣಕ್ಕೆ (cross-language integration) ದಾರಿ ಮಾಡಿಕೊಟ್ಟಿದೆ.
ಅದೇ ಸಮಯದಲ್ಲಿ, ಕ್ಲೌಡ್ ಪ್ರೊವೈಡರ್ಗಳು ಮತ್ತು CDNಗಳು Wasm ಆಧಾರಿತ ಎಕ್ಸಿಕ್ಯೂಷನ್ ಎನ್ವಿರಾನ್ಮೆಂಟ್ಗಳನ್ನು (execution environments) ನೀಡಲು ಪ್ರಾರಂಭಿಸಿದವು. 2026 ರಲ್ಲಿ, ಬ್ರೌಸರ್ಗಳಿಗಿಂತ ಹೆಚ್ಚು Wasm ವರ್ಕ್ಲೋಡ್ಗಳು ಸರ್ವರ್ಗಳು ಮತ್ತು ಎಡ್ಜ್ನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿವೆ.
ಈ ಅಂಕಿಅಂಶಗಳ ಅರ್ಥವೇನು
- Cold-start time – ಹೊಸ Wasm ಇನ್ಸ್ಟೆನ್ಸ್ 10 msಗಿಂತ ಕಡಿಮೆ ಸಮಯದಲ್ಲಿ ಸಿದ್ಧವಾಗಬಹುದು; ಆದರೆ ಸಾಮಾನ್ಯ Docker ಕಂಟೇನರ್ ಬೂಟ್ ಆಗಲು ಇಂದಿಗೂ ಹಲವಾರು ಸೆಕೆಂಡುಗಳು ಬೇಕಾಗುತ್ತವೆ. ರಿಕ್ವೆಸ್ಟ್-ಡ್ರಿವನ್ APIಗಳಿಗೆ ಇದು ನೇರವಾಗಿ ಬಳಕೆದಾರರು ಅನುಭವಿಸುವ ವಿಳಂಬಕ್ಕೆ (latency) ಕಾರಣವಾಗುತ್ತದೆ.
- Binary size – ಒಂದು Wasm ಮಾಡ್ಯೂಲ್ ಸಾಮಾನ್ಯವಾಗಿ 2 MB ಮತ್ತು 5 MB ನಡುವೆ ಇರುತ್ತದೆ. ಇದಕ್ಕೆ ಹೋಲುವ Docker ಇಮೇಜ್ ಹೆಚ್ಚಾಗಿ 100 MB ನಿಂದ 200 MB ವರೆಗೆ ಇರುತ್ತದೆ, ಇದು ಬ್ಯಾಂಡ್ವಿಡ್ತ್ ಮಿತಿಯಿರುವ ಎಡ್ಜ್ ಸ್ಥಳಗಳಿಗೆ ಬಹಳ ಮುಖ್ಯವಾಗಿದೆ.
- Safety – ಸ್ಯಾಂಡ್ಬಾಕ್ಸ್ ಎಕ್ಸಿಕ್ಯೂಷನ್ ಮಾಡೆಲ್ ಅನಿಶ್ಚಿತ ಕೋಡ್ ಅನ್ನು ಪ್ರತ್ಯೇಕಿಸುತ್ತದೆ, ಇದು ಹೋಸ್ಟ್ OS ಅನ್ನು ಅಪಾಯಕ್ಕೆ ಒಡ್ಡದೆ, ಪ್ಲಾಟ್ಫಾರ್ಮ್ಗಳು ಕೋರ್ ಸೇವೆಗಳ ಜೊತೆಗೆ ಥರ್ಡ್-ಪಾರ್ಟಿ ಪ್ಲಗಿನ್ಗಳನ್ನು ಚಲಾಯಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ.
- Portability – ಅಡಿಯಲ್ಲಿರುವ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಅಥವಾ ಭಾಷೆಯ ಪರಿಸರ ವ್ಯವಸ್ಥೆ (ecosystem) ಏನೇ ಇರಲಿ, ಸ್ಪೆಕ್ (spec) ಅನ್ನು ಅನುಷ್ಠಾನಗೊಳಿಸುವ ಯಾವುದೇ ಹೋಸ್ಟ್ನಲ್ಲಿ ಒಂದೇ Wasm ಬೈನರಿ ಚಲಾಯಿಸಬಹುದು.
Wasm ಎಲ್ಲಿ ಮಿಂಚುತ್ತದೆ
Component Model ಒಂದು ಭಾಷೆಯಲ್ಲಿ ಬರೆಯಲಾದ ಮಾಡ್ಯೂಲ್ ಮತ್ತೊಂದು ಭಾಷೆಯು ಇಂಪೋರ್ಟ್ ಮಾಡಬಹುದಾದ ಸ್ಪಷ್ಟವಾದ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಪ್ರದರ್ಶಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ. ಇದು ವಿವಿಧ ಭಾಷೆಗಳಲ್ಲಿ ಬರೆಯಲಾದ ಮಾಡ್ಯೂಲ್ಗಳು ಯಾವುದೇ ಕಸ್ಟಮ್ ಗ್ಲೂ ಕೋಡ್ (glue code) ಇಲ್ಲದೆ ಪರಸ್ಪರ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಪ್ಲಗಿನ್ ಸಿಸ್ಟಮ್ಗಳನ್ನು ನಿರ್ಮಿಸಲು ಪ್ರಾಯೋಗಿಕವಾಗಿಸುತ್ತದೆ.
ಇಂದು Wasm ನಿಂದ ಪ್ರಯೋಜನ ಪಡೆಯುವ ಸಾಮಾನ್ಯ ಸನ್ನಿವೇಶಗಳು ಇಲ್ಲಿವೆ:
- HTTP ರಿಕ್ವೆಸ್ಟ್ಗಳನ್ನು ಪರಿವರ್ತಿಸುವ, ಅಥೆಂಟಿಕೇಶನ್ ಮಾಡುವ ಅಥವಾ ಲೈಟ್ವೇಯ್ಟ್ AI ಇನ್ಫರೆನ್ಸ್ (AI inference) ಮಾಡುವ ಎಡ್ಜ್ ಫಂಕ್ಷನ್ಗಳು (Edge functions).
- ಥರ್ಡ್-ಪಾರ್ಟಿ ಡೆವಲಪರ್ಗಳು ಸ್ಯಾಂಡ್ಬಾಕ್ಸ್ ಮಾಡಬೇಕಾದ ಬೈನರಿಗಳನ್ನು ಸಲ್ಲಿಸುವ ಪ್ಲಗಿನ್ ಅಥವಾ ಎಕ್ಸ್ಟೆನ್ಶನ್ ಆರ್ಕಿಟೆಕ್ಚರ್ಗಳು.
- ಇಮೇಜ್ ರಿಸೈಜಿಂಗ್, ಡೇಟಾ ವ್ಯಾಲಿಡೇಶನ್ ಅಥವಾ ಫೀಚರ್-ಫ್ಲಾಗ್ ಇವ್ಯಾಲ್ಯೂಯೇಶನ್ನಂತಹ ಅಲ್ಪಾವಧಿಯ, ಸ್ಟೇಟ್ಲೆಸ್ ಕಂಪ್ಯೂಟ್ (stateless compute).
Docker ಅನ್ನು ಪ್ರಸ್ತುತವಾಗಿರಿಸುವ ಮಿತಿಗಳು
Wasm ಕಂಟೇನರ್ಗಳಿಗೆ ಸಾರ್ವತ್ರಿಕ ಬದಲಾವಣೆಯಲ್ಲ (universal replacement). ಇದರ ಸ್ಯಾಂಡ್ಬಾಕ್ಸ್ ಪೂರ್ಣ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಪ್ರದರ್ಶಿಸುವುದಿಲ್ಲ, ಇದರರ್ಥ:
- ಮೆಮೊರಿ ಅಥವಾ ಡಿಸ್ಕ್ನಲ್ಲಿ ಸ್ಟೇಟ್ ಅನ್ನು ಕಾಯ್ದುಕೊಳ್ಳುವ ದೀರ್ಘಕಾಲದ ಸೇವೆಗಳು ಇಂದಿಗೂ ಕಂಟೇನರ್ಗಳನ್ನೇ ಹೆಚ್ಚು ಇಷ್ಟಪಡುತ್ತವೆ.
- ನೇರ GPU ಪ್ರವೇಶ, ವಿಶೇಷ ಕರ್ನಲ್ ಮಾಡ್ಯೂಲ್ಗಳು ಅಥವಾ ಆಳವಾದ ಸಿಸ್ಟಮ್-ಮಟ್ಟದ ಏಕೀಕರಣದ ಅಗತ್ಯವಿರುವ ಅಪ್ಲಿಕೇಶನ್ಗಳು Docker ಅಥವಾ ಅಂತಹ ರನ್ಟೈಮ್ಗಳಲ್ಲೇ ಉಳಿಯುತ್ತವೆ.
ಈ ನಿರ್ಬಂಧಗಳಿಂದಾಗಿ, ಅನೇಕ ಸಂಸ್ಥೆಗಳು ಹೈಬ್ರಿಡ್ ಸ್ಟ್ಯಾಕ್ ಅನ್ನು ಬಳಸುತ್ತವೆ: ವೇಗವಾದ ಮತ್ತು ಅಗ್ಗದ ಎಡ್ಜ್ ಲೇಯರ್ಗಾಗಿ Wasm ಮತ್ತು ಭಾರೀ ಕೆಲಸ ಮಾಡುವ ಬ್ಯಾಕ್-ಎಂಡ್ ಸೇವೆಗಳಿಗಾಗಿ ಕಂಟೇನರ್ಗಳನ್ನು ಬಳಸುತ್ತವೆ.
ಮುಂದೆ ಏನನ್ನು ಗಮನಿಸಬೇಕು
- Tooling maturity – Wasm ಗಾಗಿ ಡಿಬಗ್ಗಿಂಗ್, ಪ್ರೊಫೈಲಿಂಗ್ ಮತ್ತು ಅಬ್ಸರ್ವೇಬಿಲಿಟಿ (observability) ಪರಿಕರಗಳು ದಶಕಗಳ ಹಳೆಯ Docker ಪರಿಸರ ವ್ಯವಸ್ಥೆಯನ್ನು ಹಿಂಬಾಲಿಸಲು ಇಂದಿಗೂ ಪ್ರಯತ್ನಿಸುತ್ತಿವೆ.
ಅಂತಿಮವಾಗಿ
WebAssembly ಬ್ರೌಸರ್ ಕುತೂಹಲದಿಂದ ಆಧುನಿಕ ಸರ್ವರ್ಲೆಸ್ ಮತ್ತು ಎಡ್ಜ್ ಮೂಲಸೌಕರ್ಯದ ಪ್ರಮುಖ ಭಾಗವಾಗಿ ಬದಲಾಗಿದೆ. ಅದರ ವೇಗ, ಅತ್ಯಲ್ಪ ಗಾತ್ರ ಮತ್ತು ಅಂತರ್ಗತ ಐಸೊಲೇಶನ್ (isolation), ತಕ್ಷಣವೇ ಪ್ರಾರಂಭವಾಗುವ ಮತ್ತು ಎಡ್ಜ್ನಲ್ಲಿ ಅಗ್ಗವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ವರ್ಕ್ಲೋಡ್ಗಳಿಗೆ ಅದನ್ನು ಮೊದಲ ಆದ್ಯತೆಯ ಆಯ್ಕೆಯನ್ನಾಗಿ ಮಾಡುತ್ತದೆ. ಉಳಿದೆಲ್ಲಾ ವಿಷಯಗಳಿಗಾಗಿ—ಸ್ಟೇಟ್ಫುಲ್ ಸೇವೆಗಳು, GPU-ಭಾರಿತ ಕೆಲಸಗಳು, ಆಳವಾದ OS ಏಕೀಕರಣ—ಕಂಟೇನರ್ಗಳು ಇಂದಿಗೂ ಮೇಲುಗೈ ಹೊಂದಿವೆ.