Wasm: 5 چیزی که توسعه دهندگان باید دنبال کنند

ما می دانیم که Wasm در مرورگر به خوبی کار می کند. اکنون زمان آن است که در مورد امکانات Wasm در سمت سرور هیجان زده شوید.

از آنجایی که WebAssembly (Wasm) مبتنی بر مرورگر به عنوان یک فناوری پشتیبان مورد توجه قرار می‌گیرد، توسعه‌دهندگان از «هوم، جالب به نظر می‌رسد» به «بیایید ببینیم Wasm واقعاً چه کارهایی فراتر از مرورگرها می‌تواند انجام دهد، حرکت می‌کنند. بازی‌های ویدیویی و پخش محتوا.”

در همان زمان، Wasm خود شروع به تغییر شکل و تغییر می‌کند. همه اینها زمان خوبی را برای نگاهی دیگر به فناوری WebAssembly می سازد. همانطور که Wasm را برای استفاده های جدید ارزیابی می کنید، در اینجا پنج نکته وجود دارد که باید در نظر داشته باشید.

رابط

Wasm در ابتدا برای مرورگر و بدون رابط سیستم برای بهبود وضعیت امنیتی کلی آن طراحی شده بود. نویسندگان Wasm اصلی متمرکز بر وب نمی‌خواستند برنامه‌ها بتوانند منابع را درخواست کنند، دقیقاً به همان روشی که اپلت‌های جاوا در مرورگر محدود می‌شوند.

اما توسعه دهندگان Back-End با استفاده از WASM می خواهند یک رابط کاربری داشته باشند ، به طوری که آنها می توانند برنامه های موجود و الگوی برنامه نویسی را از آن استفاده و استفاده کنند (فکر کنید پایتون ، روبی ، سرورهای وب و غیره). وارد رابط سیستم وب ASSASSEMBLY پسوند ، با نام مستعار ، مجموعه ای از API های مانند POSIX که عملکرد سبک OS مانند مانند سیستم های فایل، شبکه و رمزنگاری. WASI در اجرای و قابلیت حمل نرم افزار موجود و همچنین برنامه های جدید نوشته شده با پارادایم های مشترک و موجود (با استفاده از پرونده ها ، پورت ها و غیره) بهبود می یابد.

فشار و کشش زیادی بین کسانی که فکر می کنند Wasm باید خالص باقی بماند و کسانی که خواهان یک رابط سیستمی مانند POSIX هستند، وجود داشته است. در واقع، این یک مسئله بحث برانگیز داغ در جامعه بالادستی است. برخی از جامعه سرورهای بک‌اند نوعی مصالحه را پیشنهاد کرده‌اند و پیشنهاد می‌کنند که کسانی که می‌خواهند از Wasm همانطور که در ابتدا در نظر گرفته شده بود استفاده کنند، باید این کار را انجام دهند، اما این رابط می‌تواند برای کسانی که آن را می‌خواهند در بالا اضافه شود. من؟ من فکر می کنم WASI برای موفقیت سمت سرور ضروری است.

عملکرد

در برخی از تست‌های معیار، Wasm عملکرد چشمگیری را نشان می‌دهد. بدون شک Wasm سریع و کارآمد است، اما اعداد معیار را باید با کمی نمک در نظر گرفت. برای مثال، در تست معیار Vercel اخیر، عملکرد Wasm عالی بود. در بخش e-digit که یک ارزیابی فشرده محاسباتی است، Wasm بسیار سریعتر از جاوا بود. اما راز کثیف این است که استفاده از کامپایلر بومی Rust که به زبان C نوشته شده است و روی فلز خالی اجرا می‌شود، هنوز چیزی در همسایگی چهار برابر Wasm است. علاوه بر این، در برخی دیگر از زیر آزمون های Vercel، جاوا بسیار سریعتر از Wasm است.

مسلماً، عملکرد کامل یک برنامه کاربردی به اندازه تعدادی از معیارهای مختلف است، اما توجه به این نکته مهم است که Wasm از نظر عملکرد اسلم دانک نیست. این امر به ویژه در صورتی صادق خواهد بود که عناصر بیشتری مانند WASI در بالای Wasm قرار گیرند. همچنین، منتظر جمع آوری زباله و چگونه ممکن است بر عملکرد تأثیر بگذارد.

امنیت

همانطور که قبلاً ذکر شد، Wasm به دلایل امنیتی سیستم دارای محدودیت است. با محدود کردن آن، مانند اضافه کردن رابط WASI، سطح حمله را افزایش می دهید. این احتمال وجود دارد که هرچه Wasm محبوب‌تر شود، تعداد بیشتری به آن اضافه می‌شود، که منجر به مکان‌های بیشتری برای خطاهای انسانی یا اقدامات مخرب می‌شود. به طور خاص، چند اجاره‌نشینی یک منطقه نگران‌کننده است. آیا Wasm از کانتینرها امن تر است؟ کمتر از ماشین های مجازی؟ آیا Wasm یک نقطه امنیتی شیرین بین این دو ایجاد می کند؟ حفظ این تعادل بین عملکرد و امنیت در حرکت رو به جلو حیاتی خواهد بود. توسعه دهندگانی که در نظر دارند استفاده خود از Wasm را گسترش دهند، باید در راس (و بخشی از) بحث باشند.

قابل حمل

یکی از بزرگ‌ترین جذابیت‌های Wasm، قابلیت حمل بین پلتفرم آن است. Wasm یک فرمت باینری خنثی است که می توان آن را در یک ظرف قرار داد و در هر جایی اجرا کرد. این در دنیای سخت افزاری و نرم افزاری ما که به طور فزاینده ای چند زبانه می شود، کلیدی است. توسعه دهندگان از کامپایل کردن در فرمت های مختلف متنفرند زیرا هر معماری اضافی (x86، Arm، Z، Power، و غیره) به ماتریس تست شما اضافه می کند و انفجار ماتریس های تست مشکل بسیار گرانی است. QE گلوگاه بسیاری از تیم های توسعه است.

با Wasm، شما این پتانسیل را دارید که برنامه‌ها را بنویسید، یک بار آن‌ها را کامپایل کنید، یک بار آزمایش کنید، و آنها را بر روی هر تعداد پلتفرم سخت‌افزاری و نرم‌افزاری که فضای ابری ترکیبی را در بر می‌گیرد، از لبه تا مرکز داده‌تان گرفته تا ابرهای عمومی، مستقر کنید. یک توسعه‌دهنده در مک می‌تواند یک برنامه را در یک Wasm باینری کامپایل کند، آن را به صورت محلی آزمایش کند، و سپس با اطمینان آن را به همه ماشین‌های مختلفی که قرار است روی آن‌ها مستقر شود، منتقل کند.

همه این ماشین‌ها قبلاً یک زمان اجرا Wasm بر روی آنها نصب شده‌اند، زمانی که برای آن پلتفرم خاص آزمایش شده است، در نتیجه باینری‌های Wasm را بسیار قابل حمل می‌کنند، بسیار شبیه جاوا. و هنگامی که برنامه‌ای را در آن باینری Wasm کامپایل می‌کنید، می‌توانید آن را به یک رجیستری کانتینر ارسال کنید، آن را روی دستگاه دیگری که دارای زمان اجرا Wasm است پایین بکشید، و سپس آن را در هر جایی اجرا کنید—خواه میزبان M1 یا M2 Mac باشد، یا یک سیستم x86 یا هر چیز دیگری.

وقتی به چگونگی بلند شدن Arm و RISC نگاه می کنید، متوجه می شوید که دنیای چند زبانی ما در پنج سال آینده، اگر نه زودتر، چند زبانه تر می شود. Containers plus Wasm به نظر یک برد بزرگ بین پلتفرمی است.

واسم و کوبرنتس

یکی دیگر از حوزه‌های بحث در مورد Wasm این است که آیا باینری‌های Wasm باید به صورت بومی، در کنار کانتینرها یا درون کانتینرها اجرا شوند. زیبایی این است که واقعاً مهم نیست، تا زمانی که همه ما تصویر ظرف OCI را اتخاذ کنیم. قالب خواه یک Wasm باینری را به صورت بومی در زمان اجرا Wasm اجرا کنید، یا اگر آن زمان اجرای Wasm در یک ظرف OCI اجرا شود (به یاد داشته باشید، آنها فقط فرآیندهای فانتزی)، می توانید یک تصویر ایجاد کنید که می تواند در چندین معماری مستقر شود.

یک تصویر واحد باعث صرفه جویی در فضای دیسک و زمان کامپایل می شود و همانطور که قبلا ذکر شد، از خارج شدن ماتریس تست شما جلوگیری می کند. مزایای اجرای Wasm در یک کانتینر این است که با تأثیر بسیار کمی در عملکرد، دفاعی عمیق دریافت می کنید. مزیت اجرای باینری‌های Wasm در کنار کانتینرها هنوز قابل بررسی است، اما در هر صورت، ما باید بتوانیم ارزش اکوسیستم Kubernetes را حفظ کنیم. اگر می‌خواهید کانتینرهای Wasm را زمان‌بندی کنید، آسان خواهد بود زیرا همه آنها در یک رجیستری OCI زندگی می‌کنند و می‌توانید آنها را در Kubernetes (یا Podman یا Docker) و آنها را اجرا کنید.

نتیجه گیری

ما می دانیم که Wasm در مرورگر به خوبی کار می کند. اکنون زمان آن است که در مورد نحوه عملکرد Wasm در سمت سرور هیجان زده شوید. من فکر می‌کنم همه ما هنوز در مورد اینکه Wasm ممکن است تبدیل شود، یاد می‌گیریم، اما به طور خاص، من بیشتر از پتانسیل بین پلتفرمی هیجان‌زده هستم. آیا Wasm، همراه با کانتینرها، واقعاً می تواند نوید حمل و نقل نهایی را ارائه دهد؟ فکر می‌کنم ممکن است، اما به‌عنوان فن‌شناس، باید منتظر بمانیم و ببینیم، و آن را به جایی که نیاز داریم هدایت کنیم.

Wasm هنوز در حال ظهور است – و عمدتاً آزمایش نشده – در قسمت پشتی. مهم است که همچنان پیشرفت Wasm را زیر نظر داشته باشیم و به این فکر کنیم که چگونه می تواند برای هر یک از سازمان های ما مفید باشد. آیا عملکرد واقعاً به خوبی فلز لخت خواهد بود؟ آیا Wasm حتی با یک رابط سیستم جدید، امنیت کافی برای فعال کردن چند اجاره ای را حفظ می کند؟ بیایید با هم در طول ماه‌ها و سال‌های آینده دریابیم!

در Red Hat، اسکات مک کارتی مدیر ارشد محصول RHEL Server است که مسلما بزرگترین تجارت نرم افزار منبع باز در جهان است. اسکات یک کهنه‌کار استارت‌آپ در شبکه‌های اجتماعی، یک تایمر قدیمی تجارت الکترونیک، و یک تکنسین تحقیقاتی دولتی است که دارای تجربه در شرکت‌ها و سازمان‌های مختلف، از هفت نفر استارت‌آپ تا ۱۲۰۰۰ شرکت فناوری کارمند است. این به یک دیدگاه منحصر به فرد در توسعه، تحویل و نگهداری نرم افزار منبع باز ختم شده است.

—

New Tech Forum مکانی برای کاوش و بحث در مورد فناوری سازمانی نوظهور در عمق و وسعت بی سابقه ای فراهم می کند. انتخاب ذهنی است، بر اساس انتخاب ما از فناوری هایی که معتقدیم مهم هستند و برای خوانندگان InfoWorld بیشترین علاقه را دارند. InfoWorld وثیقه بازاریابی را برای انتشار نمی پذیرد و حق ویرایش تمام محتوای ارائه شده را برای خود محفوظ می دارد. همه سوالات را به newtechforum@infoworld.com ارسال کنید.