بررسی معماری بدون سرور در محیط‌های ابری

امیرمحمد کرم‌زاده - مجتبی مرادی

چکیده

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

مقدمه

تاریخ بروز رایانش‌ابری را می‌توان پس از تصبیت فناوری‌های مجازی‌سازی دانست. با تثبیت مجازی‌سازی، ارائه‌دهندگان خدمات اقدام به توسعه خدمات و سرویس‌هایی بر این بستر کرده‌اند. مشهورترین خدمت بر بستر سامانه‌های مجازی شده، رایانش ابری است. استفاده‌ از ابر مزایای بسیاری برای ما به ارمغان می‌آورد که از بین آن‌ها می‌توان پرداخت به ازای مصرف و تمرکز بیشتر بر کسب‌ وکار اشاره کرد.

به طور کلی، خدمات رایانشی در ابر را می‌توان به ۳ دسته تقسیم کرد: نرم‌افزار به عنوان سرویس (SaaS)، سکو به عنوان سرویس (PaaS) و زیرساخت به عنوان سرویس (IaaS). در SaaS، ارائه‌دهندگان ابر انواع مختلفی از نرم افزارها را به عنوان خدمات به کاربران ارائه می‌دهند. به عنوان مثال، Google برنامه‌های بسیاری را به عنوان یک سرویس ارائه می‌دهد (برای مثال، Gmail، Google Docs، Google Sheets و Google forms). در این نوع ابر، کاربر مسئولیتی در قبال توسعه، استقرار و مدیریت خدمات ندارد. کاربر در اینجا فقط از آنها استفاده می‌کند بدون اینکه نگران تنظیمات باشد. در PaaS، شرکت‌های ابری خدماتی مانند ذخیره‌سازی، سرورها و سیستم‌عامل‌ها را برای توسعه دهندگان ارائه می‌دهند. توسعه‌دهندگان برای استقرار، اجرا و مدیریت برنامه‌های خود به این خدمات دسترسی دارند. در این نوع ابر، توسعه دهنده مسئول استقرار و مدیریت (تنظیمات و تنظیمات) نرم افزار خود است تا اطمینان حاصل کند که برنامه در حال اجرا است. در نهایت، در دسته IaaS، مصرف کنندگان ابر خدماتی مانند دسترسی به شبکه، سرورها، سیستم عامل‌ها و ذخیره سازی را کنترل و مدیریت می‌کنند و تقریبا تمامی وظایف مانند کارهای نظارتی و ... برعهده مشتریان است.

مدیریت خدمات ابری اصلا کار ساده ای نیست. این‌ چالش‌ها می‌توانند دسترس‌پذیری، تعادل بار، مقیاس‌پذیری خودکار، امنیت، نظارت و ... باشد. برای مثال، کاربر ابر این انتظار را دارد که سرویس‌ابری همیشه در دسترس باشد و برنامه‌اش همیشه در دسترس باشد. چالش دیگر تعادل بار است. در این حالت، کاربر ابری باید اطمینان حاصل کند که درخواست‌های سرویس‌ها بین منابع مختلف به صورت متعادل توزیع می‌شوند.

وجود این چالش‌ها منجر به معرفی مدل دیگری از رایانش ابری شده است که محاسبات ابری بدون‌سرور نامیده می‌شود. محاسبات ابری بدون‌سرور با backend به عنوان سرویس (BaaS) و تابع به عنوان یک سرویس (FaaS) ارائه می‌شود. این مفاهیم را در قسمت‌های بعدی توضیح خواهیم داد. از FaaS به عنوان غالب ترین مدل بدون سرور یاد می‌شود و همچنین به عنوان "تابع‌های رویداد محور" شناخته می‌شوند.

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

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

ساختار این پژوهش به این شکل است: در بخش معماری بدون‌سرور، ابتدا مفهوم «بدون‌سرور» را تعریف می‌کنیم؛ سپس مزایا و معایب آن را شرح می‌دهیم. در بخش مقایسه با سایر معماری‌ها، معماری بدون‌سرور را با سایر معماری‌های مطرح روز مقایسه می‌کنیم. در بخش ارائه‌دهندگان خدمات بدون‌سرور با شرکت‌های مطرحی که خدمات بدون‌سرور به مشتریانشان ارائه می‌دهند، آشنا‌ می‌شویم. در سکو‌های ارائه خدمات بدون سرور، سکو‌های نرم‌افزاری برای استقرار برنامه‌های بدون‌سرور در محیط ابری معرفی می‌شوند. این سکو‌ها هم می‌توانند متن‌باز باشند و هم تجاری. در بخش چارچوب‌های بدون‌سرور نیز چارچوب‌های نرم‌افزاری برای توسعه برنامه‌ها در محیط بدون‌سرور معرفی می‌شوند. در بخش پایش برنامه‌ها در معماری بدون سرور به معرفی ابزارها و راهکارها برای پایش یک برنامه بدون‌سرور خواهیم پرداخت. در بخش مهاجرت به معماری بدون سرور به ارائه مثالی از مهاجرت یک سرویس با معماری یک‌تکه به معماری بدون‌سرور و تاثیرات معماری جدید بر کارایی برنامه خواهیم پرداخت. ما در بخش الگو‌های معماری بیش از ۲۰ الگوی معمارانه برای پیاده‌سازی یک سامانه بدون‌سرور پرداخته‌ایم. در این الگو‌ها ابتدا مشکل و زمینه را ذکر کرده و معماری پیشنهادی را پیشنهاد می‌دهیم. در بخش مثال‌هایی از استفاده از خدمات بدون سرور، مثال‌هایی از برنامه‌هایی که به معماری بدون‌سرور مهاجرت کرده‌اند را ذکر می‌کنیم. در نهایت در فاز جمع‌بندی و نتیجه‌گیری، به بیان خلاصه‌ و نتایج این تحقیق می‌پردازیم.

معماری بدون‌سرور

متاسفانه تعریف دقیقی برای توضیح رایانش بدون‌ سرور وجود ندارد. رایانش بدون سرور نیز مانند بسیاری از مفاهیم دیگر در مهندسی کامپیوتر از جنبه‌های متفاوتی قابل بررسی و ارزیابی است. بنابراین ممکن نیست که بتوان برای آن تعریف واحدی را ارائه داد که تمامی جنبه‌های آن را پوشش دهد؛ بلکه تعاریف مختلف سعی می‌کنند که تنها قسمت‌هایی از رایانش بدون سرور را پوشش دهند. برای شروع می‌خواهیم دو جنبه از رایانش بدون سرور را توضیح دهیم [1].

• بدون‌سرور برای توصیف معماری برنامه‌های‌کاربردی به کار برده می‌شود که سرویس‌هایشان را به طور کامل یا قابل توجهی بر روی ساختار یک ارائه‌دهنده خدمات ابری مستقر کرده‌اند. در این معماری، مدیریت سرویس‌ها به طور کامل برعهده ارائه‌دهندگان سرویس می‌باشد. شرکت‌های ارائه‌دهنده خدمات بدون سرور برنامه‌ها و سرویس‌های ثالثی را توسعه داده‌اند که برنامه‌نویس می‌تواند از آن‌ها استفاده کند (از سرویس‌ احراز هویت گرفته تا سرویس ارسال ایمیل و سرویس‌های پردازش تصویر در آمازون و مایکروسافت). این سرویس‌ها را اصطلاحا Backend-as-a-Service یا به اختصار BaaS می‌نامیم.
• کاربرد دیگری که برای رایانش بدون سرور می‌توان متصور شد این است که برنامه‌ بدون‌سرور برنامه‌ای است که برای اجرای منطق برنامه، باید آن را به سرویس‌های کوچکتری بشکنیم و توابعی را در حالت بدون حالت (Stateless) اجرا کنیم. این ویژگی رایانشی در معماری بدون سرور را Function-as-a-Service یا به اختصار FaaS می‌نامیم.

پس تا اینجا متوجه‌ شده‌ایم که معماری بدون سرور به معنای نداشتن سرور نیست؛ بلکه به معنای معماری ‌است که کنترل و مدیریت سرور برعهده ارائه‌دهندگان سرویس‌های ابری است. در مورد مزایا و معایب معماری بدون سرور در قسمت‌های آتی بحث خواهیم کرد. بدون سرور را می‌توان یک مدل اجرایی در رایانش ابری نامید که در قالب‌های BaaS و FaaS پیاده‌سازی شده است. زمینه کلی برنامه‌های بدون سرور در شکل ۱ نمایش داده شده است.

شکل فوق زمینه کلی معماری بدون سرور را نمایش می‌دهد. جایی که یک خدمت ابری بدون سرور را جایی بین PaaS و SaaS می‌دانند. در میانه شکل ۱ همانگونه که مشاهده می‌کنید، serverless قرار گرفته است که یک زیرساخت اشتراکی بین تمامی کاربران سرویس داریم که در آن کد‌های اختصاصی خود را بارگذاری و پیاده‌سازی می‌کنیم. در طرف راست تصویر، SaaS قرار دارد که در آن زیرساخت و کدی که کاربران با آن تعامل دارند، هردو اشتراکی است و در طرف چپ این تصویر، کد و زیرساخت در PaaS‌هر دو اختصاصی است [۲].

اما معماری کلی یک برنامه بدون سرور چگونه است؟ این معماری در شکل ۲ نشان داده شده است [۳].

همانگونه که شکل ۲ نشان می‌دهد، معماری کلی یک برنامه بدون سرور به شکل فوق است. منطق برنامه در قالب توابعی در سرورهای ابری پیاده‌سازی می‌شوند. این سرویس‌ها ممکن است از سرویس‌هایی مانند دلال پیام (message Broker) یا پایگاه‌داده استفاده کند. بنابراین، برخی از سرویس‌های BaaS در تعامل با سرویس FaaS هستند تا عملکرد کامل و مطمئن آن را تضمین کنند. اما برای فراخوانی توابع باید کاربران از طریق دروازه‌های پیام اقدام به فراخوانی توابع کنند. درواقع سرویس‌های FaaS به خاطر معماری میکروسرویس و توانایی مقیاس‌پذیری آن‌ها به صورت مستقیم فراخوانی نمی‌شوند، بلکه باید این کار از طریق واسطی به نام API Gateway صورت بگیرد.

اما اکنون که با مفهوم بدون‌سرور آشنا شدیم، برای درک بهتر چند ویژگی ‌از آن را مجددا مرور کنیم. یک سرویس بدون سرور، خدمتی است که ویژگی‌های زیر را دارا می‌باشد.

• محیط اجرایی از مشتری مخفی نگه ‌داشته می‌شود. در مدل بدون سرور لازم نیست مشتری اطلاعی از جزئیات اجرای برنامه‌ مانند محیط نگه‌داری کد‌ها، اطلاعات ماشین مجازی، کانتینر و سیستم‌عامل اجرا کننده کد داشته باشد. از نظر بازبودن (openness) معماری بدون‌سرور اطلاعات اندکی به مشتریان می‌دهد.
• ارائه‌دهنده باید قابلیت مقیاس‌پذیری خودکار (autoscaling) برای سرویس‌های خود را فعال کرده‌باشد. منابع به ازای درخواست، قابلیت افزایش داشته باشند.
• مکانیسم پرداخت در سرویس‌های بدون سرور از نوع Pay-as-you-go یا همان پرداخت به ازای استفاده است.
• ارائه‌دهنده خدمات ابری، مانند تمامی سرویس‌های ابری دیگر خود را ملزم به رعایت توافق‌نامه سطح سرویس (Service Leven Agreement) بداند.
• عناصر پایه‌ای در معماری بدون‌سرور توابع هستند که لازم است منابعشان از ارائه‌دهنده خدمات مخفی بماند.

مزایا و معایب

معماری بدون‌سرور نیز مانند معماری‌های دیگری که در دنیای مهندسی نرم‌افزار وجود دارد، دارای معیاب و مزایایی می‌باشد. در [1،2 و 3] این موارد ذکر شده‌اند. مزایایی که برای رایانش بدون‌سرور می‌توان در نظر گرفت عبارتند از:

• مقیاس‌پذیری خودکار: کاربران لازم نیست دغدغه‌ای بابت مقیاس‌پذیر بودن برنامه‌خود در محیط ابری داشته باشند؛ بلکه این ارائه‌دهنده خدمات است که بر اساس ترافیک و تقاضایی که برای یک تابع وجود دارد، آن تابع را مقیاس‌پذیر کند و تضمین این مورد را نیز در sla به صراحت ذکر کرده است.
• پیاده‌سازی آسان:‌ کاربر برای پیاده‌سازی برنامه‌ خود کافی است تا برنامه‌ را در پنل مربوطه بارگذاری کند یا این کار را با چند دستور cli انجام دهد.
• کاهش هزینه مقیاس‌پذیری در مقایسه با روش‌های دیگر
• کاهش زمان انتشار محصول (Time to Market)
• رایانش سبز‌تر: با توجه به قوانین سخت‌گیرانه احداث و استفاده از مراکز داده؛ این مراکز باید کاملا در مصرف انرژی بهینه باشند.

در ادامه معایب رایانش بدون سرور را مورد بحث قرار خواهیم داد:‌

• مشکل تاخیر شروع سرد: تاخیر شروع سرد باعث می‌شود تا بلافاصله بعد از فراخوانی توابع، توابع اجرا نشوند. تاخیر شروع سرد یکی از اصلی ترین چالش‌های رایانش بدون سرور برای پیاده‌سازی عملی بسیاری از سرویس‌ها مخصوصا سرویس‌های درلحظه (Real Time) که تاخیر شروع سرد بسیار اندکی را طلب می‌کنند.
• اجرای طولانی مدت توابع: در مدل بدون سرور توابع نمی‌توانند به مدت طولانی در حال اجرا باشند. توابع در مدل بدون‌سرور اجرای کوتاه‌ مدتی دارند و باید منابع محدودی را مصرف کنند.
• تست و اشکال‌یابی توابع: از آنجایی که توابع در کانتینر‌ها یا ماشین‌های مجازی جعبه ‌سیاهی اجرا می‌شوند، عملیات اشکال‌زدایی و تست نرم‌افزار تنها باید به صورت جعبه ‌سیاه صورت بپذیرد و دسترسی به کد پروژه وجود ندارد.
• مشکل vendor lock-in: این مشکل زمانی به وجود می‌آید که برنامه در بستر ابری یک ارائه‌دهنده آنقدر توسعه پیدا کرده‌است که دیگر مهاجرت از آن ارائه‌دهنده خدمات ابری به ارائه‌دهندگان دیگر بسیار سخت یا غیرممکن باشد. در این حالت توسعه‌دهنده محکوم به استفاده از آن سرویس ‌ابری هستند.
• توابع بدون حالت (Stateless Functions):‌ در معماری بدون‌سرور، توابع باید به صورت بدون حالت اجرا شوند و حالت‌های قبلی را نگه ندارند. اگرچه بسیاری از به‌روش‌های معماری نرم‌افزار به سمت استفاده از الگو‌های بدون حالت حرکت کرده، اما اگر بخواهیم یک برنامه‌ حالت‌دار (Stateful) را به معماری بدون‌سرور مهاجرت دهیم، قطعا با چالش‌های بسیاری مواجه خواهیم شد.

چالش‌ها

مواردی که در قسمت قبلی ذکر شد اگرچه نقاط ضعف معماری‌های بدون سرور را مورد بحث قرار می‌داد، بلکه می‌توانست به عنوان چالش‌هایی برای مهاجرت به معماری‌های بدون‌سرور نیز فرض شود. در [۴] سه چالش‌ اصلی برای معماری بدون‌سرور مورد بحث قرار گرفته‌است. این چالش‌ها به طور کلی چالش‌های مطرح در مهندسی نرم‌افزار مانند کمبود تجربه در توسعه معماری‌های بدون سرور، چالش‌های اجرایی (operational) مانند حل مشکلات برنامه‌های با زمان اجرای بالا یا منابع محدود و چالش‌هایی برای مهندسی کارایی در سطح برنامه، مانند مدیریت بارهای‌کاری سیستم است. در [۵] چالش‌های معماری بدون سرور در دامنه یک مسئله اینترنت اشیا که از معماری بدون سرور استفاده‌ می‌کند، مطرح شده است. چالش‌های آن سیستم اینترنت اشیا مورد بحث عبارت بودند از زمان پاسخ و Jitter بالا. راه‌حل مقاله، استفاده از وب‌اسمبلی در سیستم بدون سرور بود تا هم زمان پاسخ و هم Jitter کاهش یابد. به علاوه، با استفاده از وب‌اسمبلی، حجم کانتینر و زمان شروع سرد نیز کاهش می‌یافت.

در [۶] نیز چالش‌های دیگر معماری بدون سرور مورد بحث قرار گرفته است که یکی از همین چالش‌ها، برنامه‌ریزی برای اجرای کانتینر‌ها توسط ارائه‌دهنده سرویس ابری بود. برنامه‌ریزی در این محیط‌ها می‌تواند بر اساس مصرف انرژی، مصرف منابع، نوع و طول جریان‌کاری یا جریان‌های داده‌ای باشد. در [۷] مشکل دیگر و مهم رایانش ‌بدون سرور مطرح شد. از آنجایی که تمامی کد‌های کاربران توسط ارائه‌دهنده خدمات ابری نگهداری و اجرا می‌شود. لذا کد‌ها باید در فضای ایزوله‌ای اجرا شوند. این درحالی بوده که کانتینر‌ها این اطمینان از ایزوله‌ بودن کد را نمی‌دهند. در نقطه مقابل ماشین‌های مجازی شروع سرد بسیار طولانی داشتند. ایده مقاله استفاده از ماشین‌های مجازی سبک و کوچک کردن هسته سیستم‌عامل لینوکس تا حدی که تنها برای اجرای یک تابع مناسب باشد، بود.

مقایسه با سایر معماری‌ها

در [۸] مقایسه دو معماری بدون سرور و میکروسرویس مورد بحث قرار گرفته است. این دو معماری اگرچه در مفاهیم و جزئیات با یکدیگر متفاوت هستند اما هر دو یک‌دیگر را تقویت می‌کنند. معماری میکروسرویس این قابلیت را به وجود آورده که تیم‌های کوچکی از توسعه‌دهندگان شرکت هرکدام برروی جنبه‌هایی از برنامه تمرکز کنند. در واقع، معماری میکروسرویس این امکان را به وجود آورده است تا یک برنامه خیلی بزرگ‌ را بتوانیم به چندین برنامه کوچک‌تر بشکنیم. معماری بدون سرور هم این کمک را می‌کند تا با کمترین زحمت و هزینه، میکروسرویس‌ها را در محیط ابری اجرا و مقیاس‌پذیر کنیم. در معماری میکروسرویس استفاده از توابع و سرویس‌های بدون‌حالت (stateless) یک به‌روش است در حالی‌که استفاده از توابع بدون حالت در معماری بدون‌سرور یک اجبار است. از این نظر دو معماری با یکدیگر شبا‌هت دارند. استفاده از معماری بدون‌سرور در یک محیط ابری بدون‌سرور (همان ترکیب معماری‌های بدون‌سرور و میکروسرویس)، باعث می‌شود تا معماری مقاومی در برابر خرابی‌ها داشته باشیم، معماری مقیاس‌پذیری خودکار داشته باشد و نگرانی از مسائل پایه‌ای امنیتی در معماری خود نداشته باشیم. در ادامه در جدول ۱، مواردی که بهتر است از معماری میکروسرویس یا بدون‌سرور استفاده کنیم، ذکر شده است.

ارائه‌دهندگان خدمات بدون سرور

ارائه‌دهندگاه خدمات ابری در سراسر جهان اقدام به ارائه خدمات بدون‌سرور برای راحتی توسعه‌ معماری‌ بدون‌سرور کرده‌اند. متاسفانه هیچ‌کدام از این سرویس‌ها در کشور ایران قابل دسترسی نیست. در لیست زیر تعدادی از ارائه‌دهندگان خدمات بدون‌سرور ذکر شده‌اند.

• آمازون: شرکت آمازون را می‌توان بزرگترین ارائه‌دهنده خدمات ابری در دنیا نامید. این شرکت در سال ۲۰۱۴ برای اولین بار مفهوم رایانش بدون‌سرور را مطرح کرد و با انتشار سکوی بدون‌سرور خود یعنی AWS Lambda باعث انقلابی در عرصه رایانش ابری شد و داستان رایانش بدون‌سرور را آغاز کرد. سرویس AWS Lambda را می‌توان کامل‌ترین سرویس رایانش بدون سرور در دنیا نامید که از زبان‌های برنامه‌نویسی بسیاری مانند C#، جاوا، پایتون، گو و جاوااسکریپت پشتیبانی می‌کند. همچنین سرویس AWS سرویس‌های آماده‌ای جهت پردازش فایل‌ها و تصاویر، احراز هویت، ارسال notification، تحلیل‌داده‌ها در سطح اینترنت اشیا و ... دارد [9].
• گوگل: شرکت گوگل به عنوان یک غول در صنعت IT در حوزه رایانش بدون‌سرور نیز فعال است. این شرکت در سال ۲۰۱۶ با معرفی سرویس Google Cloud Functions وارد عرصه رقابت در حوزه رایانش بدون سرور شده است. یکی از مواردی که سکوی بدون‌سرور گوگل برروی آن تاکید بسیاری دارد، عدم امکان vendor lock-in پس از مهاجرت به سرویس‌های ابری گوگل است. زیرا، سرویس بدون‌سرور گوگل برپایه سکوی متن‌باز knative توسعه داده می‌شود [10].
• مایکروسافت: مایکروسافت به عنوان غول صنعت نرم‌افزار چندسالی است که با توسعه پلتفرم Microsoft Azure وارد صنعت رایانش ابری شده است. مایکروسافت سرویس‌های بدون سروری را تحت عنوان Microsoft Serverless پیاده‌سازی کرده که شامل سرویس FaaS، سرویس Kubernetes و سرویس BaaS می‌شود [11].
• اوراکل: شرکت اوراکل نیز جز شرکت‌هایی است که خدماتی مبنی بر معماری بدون سرور را به فروش می‌رساند. این شرکت راهکا‌رهایی برای ارائه خدمات در قالب کانتینر‌های داکری ارائه می‌دهد. یکی از مزایایی که اوراکل در مورد سرویس‌های خود ادعا می‌کند این است که درصورت استفاده از سرویس‌های اوراکل خطر vendor lock-in متوجه کاربران و کسب‌وکارها نیست زیرا سرویس های بدون‌سرور توراکل بر پایه پروژه متن‌ باز Fn توسعه داده شده است. این سرویس انتخاب مناسبی برای کسب‌وکارهایی است که به دنبال یک ارائه‌دهنده که از کانتیرها استفاده می‌کند، هستند [12].
• کلودفلر: شرکت cloudflare به خاطر سرویس‌های CDN معروف خود، در جهان رایانش ابری بسیار خوشنام است. اما سرویس Cloudflare workers آخرین تلاش این شرکت برای بدست آوردن جایگاهی در رایانش بدون‌سرور است. این شرکت در ۹۰ کشور و بیش ‌از ۲۰۰ شهر جهان مراکز داده‌ای احداث کرده‌است که باعث شده این توانایی را داشته باشد تا با کمترین تاخیر پاسخ درخواست کاربران را بدهد. این شرکت ادعا می‌کند که به ازای استفاده از سرویس بدون‌سرور خود، کاربر شروع سردی بیش از چند میلی‌ثانیه را تجربه نخواهد کرد [13].
• شرکت IBM: سرویس IBM Cloud Functions نیز آخرین تلاش شرکت بزرگ IBM برای رقابت در حوزه معماری بدون سرور است، این مشرکت برپایه پروژه متن ‌باز خود در حوزه رایانش بدون سرور، یعنی OpenWhisk‌ اقدام به معرفی سرویس‌های ابری خود در حوزه رایانش بدون سرور مانند IBM Function Sequences و openwhisk‌ کرده است [14].

سکو‌های (Platform) ارائه خدمات بدون سرور

برای ارائه خدمات بدون‌سرور سکو‌های بسیاری برای اجرای برنامه‌ها تحت معماری بدون‌سرور توسعه داده شده است. این پلتفرم‌ها می‌توانند با هدف تجاری و اجرای برنامه‌های تجاری عرضه ‌شده باشند یا مقاصد تحقیقاتی داشته باشند.

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

سکو‌های متن‌بسته

AWS Lambda Functions

Google Cloud Functions

IBM Cloud Functions

Azure Serverless

سکو‌های متن‌باز

Knative

OpenFaaS

OpenWhisk

Fission

بسیاری از سکو‌های متن ‌باز در سکو‌های تجاری شرکت‌های بزرگ استفاده می‌شوند. برای مثال، از سکوی Knative در سرویس بدون‌سرور شرکت گوگل استفاده می‌شود.

• سکو‌های با مقاصد آموزشی یا تحقیقاتی: بسیاری از پژوهشکده‌ها و دانشگاه‌ها با اهداف متنوعی اقدام به توسعه سکو‌های بدون‌سرور می‌کنند. برای مثال در [15] سرویس OpenLambda با اهداف آموزشی و حل بسیاری از مشکلات پایه‌ای در رایانش بدون‌سرور توسط محققین در آینده، توسعه داده شد و چندین سال است که دیگر از آن پشتیبانی نمی‌شود.

سکوی TinyFaas یکی دیگر از سکو‌های توسعه‌داده شده در رایانش بدون سرور بود که هدف از توسعه‌ آن، حل مشکلات موجود در سرویس‌های لبه در رایانش ابری بود. یکی از این مشکلات زمان بالای استقرار و حجم بالای کانتینری بود که در لایه لبه سرویس‌های اینترنت اشیا که از معماری ابری و بدون‌سرور استفاده می‌کنند، بود [16].

یکی از موارد بالقوه استفاده از سرویس‌های بدون‌سرور، استفاده از این معماری در توسعه برنامه‌های کاربردی مبتنی بر یادگیری ماشین بوده است. در [17] تلاش شده است تا با توسعه‌ cirrus سکویی مناسب اجرای برنامه‌های با قابلیت یادگیری ماشین در معماری بدون‌سرور فراهم شود.

در [18] این مشکل توسط محققان مورد توجه‌ قرار گرفته است که برنامه‌های کاربردی که در محیط ابری توسعه‌داده می‌شوند شامل تعدادی از توابع هستند که به صورت زنجیره‌ای اجرا می‌شوند. حال فراخوانی زنجیره‌وار این توابع ممکن است موجب شروع سرد آبشاری شود. شکل ۳، شروع سرد آبشاری را نمایش می‌دهد.

با توجه به شکل ۳، می‌بینیم برای اجرای یک جریان‌کاری متشکل از ۴ تابع، به ترتیب توابع دچار شروع سرد شده و پس از اجرای آخرین تابع، مجموع زمان اجرای تابع برابر خواهد شد با مجموع زمان اجرای توابع با مجموع زمان شروع‌سرد برای هر تابع. ایده‌ی Xanadu این است که با شناسایی مسیری که بیشترین احتمال اجرا را دارد و شروع سرد را در اجرای توابع موجود در جریان‌های کاری توابع کاهش‌ دهد تا از این طریق، زمان اجرای کل جریان کاری کاهش یابد.

در [19] نیز سکویی برای توسعه برنامه‌های بدون‌سرور مبتنی بر بلاک‌چین معرفی و معرفی شده است که سعی می‌کند بلاک‌های بلاک‌چین را در نودهای مختلف اجرا‌کننده توزیع کند.

مقایسه سکو‌ها

در [20] سکو‌های بدون‌سرور مورد مقایسه قرار گرفته‌اند. نویسندگان مقاله مجموعه تست‌های بنچمارکی به نام FaaSDOM Benchmark Suit توسعه داده‌اند که معیاری برای مقایسه و آزمون سکو‌های بدون سرور است. اولین معیار مقایسه در FaaSDOM بر اساس زبان‌های پشتیبانی شده در سکو‌های بدون سرور است که در شکل ۴ مشخص شده است.

در پنل برنامه FaaSDOM که در شکل ۵ آمده است، می‌توان نوع تست، حافظه مدنظر برای اجرای تست، زمان Timeout، نوع زیرساخت‌ ابری، زبان برنامه‌نویسی و مکان سرویس‌های ابری را برای انجام تست در نظر گرفت و سپس براساس مقادیر مشخص شده، سامانه را تست کرد. FaaSDOM برای تولید بار‌های کاری از مجموعه‌ی داده‌های wrk2 برای تولید داده‌های faas استفاده می‌کند. سپس نتایج در پایگاه‌داده برنامه که از نوع influx DB‌ است ذخیره شده و نمایش اطلاعات نیز در پنل گرافانا صورت می‌گیرد.

شکل ۶ یک نمونه از نتایج اجرا در FaaSDOM را نشان می‌دهد که سنجش براساس تاخیر برنامه ‌بوده و نتایج هر ۵ ثانیه یکبار لاگ شده‌اند. از موارد برتری FaaSDOM نسبت به سایر مجموعه‌های آزمون، امکان مقایسه قیمت‌های تمام‌ شده به ازای موارد انتخاب شده است. توسعه‌دهندگان FaaSDOM معیار قیمت را براساس معیاری که خود مشخص‌کرده‌اند استخراج می‌کنند که دقت چندان بالایی ندارد.

در [21] نیز ۴ سکوی ابری azure، AWS، Google Cloud Functions و IBM OpenWhisk مورد بررسی قرار گرفته‌اند. این مجموعه‌ی آزمون شامل بررسی و مقایسه مواردی ازجمله شیوه اعتبارسنجی و تعیین حق دسترسی، مقیاس‌پذیری، حداکثر تعداد توابع سکو‌های ابری، حداکثر تعداد اجراهای موازی توابع، حداکثر زمان اجرای یک تابع، حداکثر حجم کدها و شیوه‌های ذخیره‌سازی توابع است.

چارچوب‌های (Framework) بدون‌سرور

چارچوب‌های بسیاری برای توسعه برنامه‌ها براساس معماری بدون‌سرور توسعه داده شده است. این چارچوب‌ها در راستای سازگاری بهتر و راحتتر معماری برنامه توسعه‌داده شده با سکوی ‌بدون‌سرور، یا ساختاردهی به برنامه‌های توسعه‌داده شده با معماری بدون سرور است. یکی از این تلاش‌ها، چارچوب توسعه داده شده برای سکوی نودجی‌اس به نام Claudia است که سعی می‌کند با ساختاردهی به پروژه توسعه داده‌شده با نود‌جی‌اس، تعامل بین سرویس AWS Lambda و توسعه‌دهنده را تسهیل کند [22].

در [23] نیز معماری چارچوب Kappa مورد بحث قرار گرفته است. هدف این چارچوب ارائه یک بستر مقیاس‌پذیر برای محاسبات عمومی با قابلیت اجرای بلند مدت توابع است. قابلیت اجرای توابعی که اجرای بلند مدت دارند در توسعه‌ برنامه‌های یادگیری ماشین، بیگ‌دیتا، کراولر و آنالیز استریم‌ها کاربرد دارد. با استفاده از چارچوب کاپا می‌توان در کد چک ‌پوینت‌هایی برای ذخیره حالت برنامه مشخص کرد. پس از اتمام مدت زمان مجاز اجرای برنامه، برنامه با مراجعه به حالت ذخیره‌شده تابع، اجرا را از همان‌جایی که چک ‌پوینت برای آن در نظر گرفته‌شده بود، ادامه می‌دهد.

چارچوب‌های مختلفی جهت توسعه برنامه‌های بدون‌سرور با زبان‌های مختلف توسعه داده شده است. یکی از این چارچوب‌ها Kotless نام‌ دارد [24] که هدف آن، توسعه برنامه‌های موبایل با زبان کاتلین در محیط‌های بدون‌ سرور است و با سکوی AWS Lambda سازگاری مناسبی دارد.

پایش برنامه‌ها در معماری بدون سرور

به علت نو بودن مباحث رایانش بدون‌سرور ابزار‌های اندکی برای پایش و خطایابی توابع در رایانش‌ بدون‌سرور وجود دارد. با این وجود ابزار‌های تجاری مانند Dashbird، Thundra.io یا CloudWatch سعی‌کرده‌اند پایش‌ معماری سامانه‌های بدون‌سروری که در سکوی ابری AWS Lambda پیاده‌سازی شده‌اند را فراهم آورد. پایش و خطایابی در معماری بدون‌سرور موضوع برخی از پژوهش‌ها و پروژه‌های تحقیقاتی در شرکت‌ها و دانشگاه‌ها بوده است. برای مثال در [25] پروژه SeMode معرفی شده‌ است که رویکرد‌های پایش و خطایابی در معماری بدون‌سرور را ترکیب‌کرده است تا این دو مورد را در کنار یکدیگر داشته باشد. ایده SeMoDeترکیبی بین یک محیط شبیه‌سازی و محک است که قبلاً منتشر شده است. همچنین علایق تحقیقاتی بیشتر، مانند اندازه‌گیری عملکرد و غیره، در این ابزار ادغام شده‌اند تا ابزاری برای اهداف و پلتفرم‌های مختلف ارائه دهند. SeMode برای پروژه‌هایی مناسب است که بر بستر سیستم AWS Lambda میزبانی می‌شوند و قالب‌هایی برای تولید تست خودکار برای برنامه به صورت آماده دارد که آماده فراخوانی و تغییر پارامتر جهت تست‌ برنامه هستند. یک مثال از قالب‌های تست SeMoDe در شکل ۷ نمایش داده شده است.

مهاجرت به معماری بدون سرور

مهاجرت از سایر معماری‌ها به معماری بدون‌سرور موضوع بسیاری از پژوهش‌ها در حوزه معماری بدون‌سرور بوده است. در [26] نویسندگان قصد دارند تا یک برنامه تبدیل فایل‌های تصویری به متن را به معماری بدون‌سرور مهاجرت دهند. این برنامه تعدادی فایل تصویری با پسوند pdf را از کاربر دریافت کرده، با استفاده از تکنیک‌های یادگیری ماشین و شبکه‌های عصبی متن آن را استخراج کرده و در نهایت، فایل متنی را به pdf تبدیل می‌کند. بعلاوه، متن‌های استخراج‌شده توسط الگوریتم OCR‌ خود را در پایگاه‌داده جهت کارهای آتی ذخیره می‌کند. مهاجرت از معماری یک‌تکه به معماری بدون‌سرور برای نویسندگان این مقاله ۲ چالش داشته است.

1. محدودیت استفاده از منابع: همانطور که می‌دانیم استفاده از منابع در معماری بدون‌سرور دارای محدودیت‌هایی است. این برنامه از یک الگوریتم شبکه‌عصبی استفاده می‌کند تا طبقه‌بندی اطلاعات را صورت بدهد. این الگوریتم منابع عظیمی را مصرف می‌کند. راهکار نویسندگان مقاله، تقسیم این الگوریتم به ۲ تابع جهت دورزدن این محدودیت است.

2. چالش دوم زمان بالای اجرای توابع و برنامه بود. نویسندگان در معماری جدید، سعی کرده‌اند تا هنگامی که برنامه می‌تواند منتظر پاسخ فراخوانی تابع نماند به کار دیگری مشغول شود. برای این منظور بسیاری از فراخوانی‌ها از نوع آسنکرون بوده تا زمان اجرای برنامه تا حد قابل قبولی پایین بیاید.

در شکل ۸، معماری این سیستم نمایش داده شده است. این سیستم از ۵ جز اصلی تشکیل شده است:

• سرویس Dispatcher: یک پیام pub/sub را دریافت می‌کند که حاوی لینکی از آن سطل (Bucket)ای است که سند‌های تصویری در آن‌ قرار دارند. هر کدام از این سد‌ها توسط Dispatcher به یک Coordinator وصل می‌شود.
• سرویس Coordinator: نقش همنواساز (Orchestrator) در جریان تبدیل فایل تصویری به متنی را دارد. همنواساز مسئول کنترل خط لوله اجرای برنامه‌است و قسمت‌های مختلف را به یک‌دیگر متصل می‌کند.
• سرویس Page Classifier 1&2: وظیفه‌ی دسته‌بندی سند‌ها را برعهده دارند. هر page Classifier مسئول دسته‌بندی یک صفحه از سند است. برای راحتی و رعایت محدودیت‌های معماری بدون‌سرور، page classifier به دو تابع شکسته شده است.
• سرویس OCR: براساس دسته‌بندی خروجی از page classifier، محتوای متن را از تصویر استخراج می‌کند و برای coordinator‌ ارسال می‌کند.

جدول ۲ نتیجه مهاجرت به این معماری را نشان می‌دهد. این نتیجه نشان می‌دهد که ارسال ۱۰۰ سند تصویری همزمان به برنامه تحت معماری‌های بدون‌سرور و یک‌تکه است. همانگونه که مشاهده می‌شود برنامه‌ یک‌تکه‌ای که در ماشینی با ۴cpu و ۱۵ گیگابایت رم مستقر شده است، عملیات را در بیش از ۶ ساعت انجام می‌دهد و برای کاهش ۱ ساعته زمان اجرا باید برنامه را به ماشینی ببریم که 96 CPUو ۳۶۰ گیگابایت حافظه دارد. در حالی‌که با استفاده از معماری بدون‌سرور و استقرار بر سکوی AWS Lambda این کار تنها در 4 دقیقه انجام شده و هزینه آن کمتر از 2.5 دلار در ساعت شده است.

الگو‌های معماری

الگو‌های معماری مجموعه‌ای از جواب‌هایی به مسائل عمومی (general) و تکرار شونده در حوزه معماری نرم‌افزار هستند. معماری بدون سرور به عنوان یک معماری نوظهور درگیر بسیاری از مسائل و مشکلات در سطح معماری نرم‌افزار است. بنابراین، خبرگان معماری نرم‌افزار اقدام به جمع‌آوری تعدادی از راه‌حل‌های بهینه برای حل مسائل معماری یک سامانه نرم‌افزاری، کرده‌اند.

در [27، 28 و 29] تعدادی از الگو‌های معماری نرم‌افزار جمع‌آوری شده‌اند که آن‌ها را می‌توان در ۵ دسته کلی همنوا‌سازی و تجمیع (Orchestration and aggregation)، مدیریت رویداد (event management)، دسترس‌پذیری(Availability)، ارتباطات (Communication) و تعیین حق‌دسترسی (authorization) دسته‌بندی کرده‌ایم.

• الگو‌های همنواسازی و تجمیع: یکی از به‌روش‌های تولید نرم‌افزار‌ها با روش بدون‌سرور این است که توابعی که ایجاد می‌کنیم تنها یک کار را انجام دهند. از طرفی جریان‌های کاری درخواستی در برنامه‌های ما می‌توانند کارهای پیچیده‌ای انجام دهند. بنابراین، باید این توابع توانایی ترکیب و همنواسازی را داشته باشند تا بتوانیم یک جریان کاری پیچیده را به مجموعه ‌کارهای ساده‌ای تبدیل کنیم. برای این‌کار الگو‌هایی طراحی شده است که هدف آن‌‌ها ایجاد میکروسرویس‌ها است.

الگوی Aggregator : گاهی اوقات می‌خواهیم با فراخوانی یک api تعدادی سرویس را به صورت همزمان یا غیرهمزمان فراخوانی کنیم. در این حالت توصیه می‌شود که از الگوی Aggregator استفاده کنیم. راه حل این است که یک سرویس به طور جداگانه اقدام به صدا زدن سرویس‌ها کند. در نهایت آن سرویس نتایج را جمع‌آوری کرده و ادغام کند و در معرض نمایش قرار دهد.

الگوی دریاچه داده (DataLake): گاهی اوقات باید پردازش‌های مختلفی برروی داده‌هایی که در اختیار داریم انجام دهیم. این پردازشات بعضا می‌توانند با یکدیگر درتناقض نیز باشند. همانگونه که در شکل 10 نیز مشاهده می‌شود، داده‌های خام در یک حافظه فیزیکی ذخیره شده و اگر بخواهیم پردازشی بر روی آن‌ها انجام دهیم، transformation این‌داده‌ها دیگر جایگزین‌ داده‌های جدید نخواهد شد.

الگوی fan-in/fan-out : کارها یا کارهای بزرگ به راحتی می‌توانند از محدودیت زمانی اجرا در توابع لامبدا تجاوز کنند. استفاده از استراتژی تقسیم و غلبه می‌تواند به کاهش این مشکل کمک کند.کار بین کارگران مختلف لامبدا تقسیم می شود. هر کارگر کار را به صورت ناهمزمان پردازش می‌کند و زیرمجموعه نتیجه خود را در یک مخزن مشترک ذخیره می‌کند. نتیجه نهایی را می‌توان با فرآیند دیگری جمع‌آوری و به هم متصل کرد. الگوی fan-in fanout در واقع دو الگو هستند که با هم استفاده می‌شوند. پیام‌های الگویFan-out به توابع تحویل داده می‌شود و هر کدام یک زیرکار تقسیم‌بندی شده از وظایف اصلی را دریافت می‌کنند. الگوی Fan-in نتیجه همه توابع را جمع آوری می‌کند، آن را جمع می کند، ذخیره می‌کند، و یک رویداد ارسال می‌کند که نشان می‌دهد کار انجام شده است.

الگوی زنجیره توابع (function chain): همانطور که قبلا ذکر کرده‌ایم، یکی از مشکلات معماری بدون‌سرور این است که نمی‌توانیم توابع را به صورت طولانی مدت اجرا کنیم. بنابراین، یک راه‌حل شکستن یک تابع بسیار طولانی به توابع کوچک‌تر برای تقسیم‌کار و رعایت محدودیت سقف زمانی و پردازشی توابع در رایانش بدون‌سرور هستیم.

الگوی پروکسی (Proxy): گاهی می‌خواهیم در توابع بدون‌سرور از برنامه‌ها و سرویس‌های قدیمی استفاده کنیم و داده‌هایی که برگردانده می‌شود، ممکن است طبق پروتکل‌ استانداردی نباشد یا اینکه پاسخ بسیار بیش از حد باشد. بنابراین همانگونه که در شکل ۱۳ دیده می‌شود، باید از یک سرویس میانی (middleware) استفاده‌کنیم که عمل ترجمه و فیلتر داده‌ها را برای ما انجام می‌دهد. بنابراین آن‌چه که در نتیجه خواهیم داشت یک API تمیز با دسترسی آسانتر برای مشتریانی است که می‌خواهند از یک یا چند سرویس قدیمی استفاده کنند.

الگوی The Frugal Consumer:‌ در سیستم‌های ما برخی سرویس‌ها کمتر مقیاس‌پذیر هستند. یعنی در معماری سعی می‌کنیم که که یک سرویس کمترین نمونه ممکن را داشته باشد، این درحالی رخ می‌دهد که مثلا سرویس‌های زیادی سعی بر فراخوانی آن تابع دارند. بنابرین در این حالت می‌تواند نمونه‌های بسیاری از آن سرویس ایجاد شود. راه‌حل این است که این سرویس‌ها درخواست‌های خود را برای یک تابع بفرستند و آن تابع درخواست‌ها را به ترتیب به صف پیام ارسال کند.

الگوی API قوی: بهتر است هر سرویسی که می‌خواهد توسط مشتری فراخوانی شود، از API Gateway عبور کند تا سرویس‌دهی با اطمینان ایجاد شود. البته این کار ممکن است پیچیدگی را افزایش دهد.

الگوی State Machine: معمولا معماری‌های بدون سرور نیاز به همنواسازی دارند. بدون شک AWS Step Functions بهترین راه برای مدیریت ارکستراسیون در برنامه‌های بدون سرور AWS است که از ماشین‌های حالت استفاده می‌کند. ماشین‌های حالت برای هماهنگ کردن چندین کار و حصول اطمینان از تکمیل صحیح آن‌ها با اجرای تلاش‌های مجدد و تایمرهای انتظار، عالی هستند. با این حال، استفاده از StepFunction محدودیت‌هایی دارد مثلا فراخوانی‌ها آسنکرون هستند، به این معنی که شما نمی‌توانید منتظر نتیجه یک تابع Step باشید و سپس به یک درخواست همزمان پاسخ دهید.

الگوی Router: الگوی State Machine قدرتمند است زیرا ابزارهای ساده‌ای را برای مدیریت پیچیدگی، موازی سازی، مدیریت خطا و موارد دیگر در اختیار ما قرار می‌دهد. با این حال، استفاده از step functions رایگان نیست و اگر از آن برای همه چیز استفاده کنید، احتمالاً صورتحساب های هنگفتی دریافت خواهید کرد. برای همنواسازی‌های ساده‌تر که کمتر نگران انتقال حالت هستیم، می‌توانیم آنها را با استفاده از الگوی روتر مدیریت کنیم. برای این‌کار می‌توان تابعی ایجاد‌ کرد که وظیفه‌ی سیستم همنواساز برای فراخوانی توابع را در نظر گرفت.

الگوی Thick Client: این الگو بیان می‌کند که گاهی اضافه‌کردن لایه‌ها و سرویس‌هی مختلف برای پاسخ به درخواست مشتریان می‌تواند زمان پاسخ را به حد بسیاری افزایش دهد. بنابراین، یک راه می‌تواند این باشد که تا جای ممکن از اضافه کردن لایه‌ها و سرویس‌های مختلف پرهیز کنیم و اجازه دهیم کاربران مستقیما به سرویس‌ها دسترسی داشته باشند.

• الگو‌های مدیریت رویداد: در حوزه معماری بدون‌سرور، مشکلات بسیاری در حوزه ارتباطات بین توابع وجود دارد. این دسته از الگو‌های معماری سعی بر حل مشکلات ارتباطی بین توابع را دارند.

الگوی تفکیک مسئولیت: گاهی اوقات یک تابع هم وظیفه خواندن داده‌ها را دارد و هم تغییر و ایجاد داده‌ها در پایگاه‌داده. این روش در معماری بدون‌سرور روش استانداردی نیست. بهتر است در معماری بدون سرور توابعی که وظیفه خواندن داده‌ها را دارند و توابعی که وظیفه نوشتن داده‌ها در پایگاه داده را دارند، در قالب یک تابع یا کانتینر بسته‌بندی نشوند.

الگوی Distributed Triggers : گاهی نیاز تابع فراخوانی کننده ممکن است چندین سرویس‌ را فراخوانی کند و هر کدام از این درخواست باید در صف‌هایی قرار بگیرند تا نوبت سرویس‌دهی به آن‌ها برسد. برای این کار بهتر است که صف‌های مختلفی برای فراخوانی هر سرویس به طور مجزا وجود داشته باشد.

الگوی internal hand-off: گاهی از فراخوانی (رویداد) برای یک رویداد ناهمزمان استفاده می‌کنیم. پس از اتمام اجرا، تابع به طور خودکار متوقف می‌شود و در صورت نیاز به طور خودکار دوباره تلاش می‌کند. گاهی نیز در عملکرد تابع خطاهایی به علت‌ نقص تابع وجود دارد که بهتر است این موارد بررسی شوند. در این حالت بهتر است لاگ‌های این چنینی برای صفی ارسال شوند تا failureهای برنامه جمع‌آوری و در صورت لزوم بررسی شوند.

الگوی فراخواننده دوره‌ای (periodic invoker): گاهی برخی توابع باید به صورت دوره‌ای اجرا شوند. برای این کار بهتر است از سرویس‌های شخص ثالثی که از بیرون توابع را فراخوانی می‌کنند استفاده کنیم. ابزار Cloudwatch یا google scheduler‌ مثال‌های خوبی برای این‌کار هستند.

• الگو‌های دسترس‌پذیری: این گروه از الگوها به حل مشکلات در دسترس بودن، کاهش زمان گرم کردن و خرابی های احتمالی کمک می‌کند.

الگوی bulkhead: گاهی خرابی یک تابع مهم ممکن است کل عملکرد برنامه را تحت تاثیر خود قرار دهد. برای حل چنین مشکلی بهتر است هنگامی که می‌خواهیم جریان‌های کاری خود را ایجاد کنیم، از poolهای مختلف استفاده کنیم تا بارهای کاری را به نحوی پارتیشن‌بندی کرده باشیم.

الگوی Circuit Breaker:‌ گاهی درخواست‌هایی که برای برنامه‌ می‌آیند دچار خطا و شکست می‌شوند و پاسخی برای آن‌ها دریافت نمی‌شود. برای این‌کار باید ماژول یا سرویسی مسئول پی‌گیری درخواست‌های در شبکه باشند که اگر تعداد خطاها از تعداد معینی بیشتر شد، تمامی درخواست‌ها را بلاک ‌می‌کند و سپس به مرور زمان مدار را به حالت نیمه‌ باز برمی‌گرداند تا تنها تعدادی از درخواست‌‌ها را جواب دهد و اگر تمامی درخواست‌ها با موفقیت بازگردانده شد مدار را می‌بندد تا سیستم به سرویس‌دهی بارکاری گذشته خود برگردد.

توابع کامپایل شده: در رایانش ابری هرچقدر حجم تابع کمتر و تکنولوژی زبان تابع سریعتر باشد، تابع زودتر پاسخ داده می‌شود. بنابراین یک به‌روش در پیاده‌سازی معماری بدون‌سرور در سامانه‌هایی که نیاز به زمان پاسخ سریع دارد، استفاده از زبان‌ها و تکنولوژی‌هایی است که در آن توابع را باید کامپایل کنیم. نکته مهم این است که این توابع باید گرم بمانند زیرا در این صورت باید بعد از up کردن توابع مدت‌ زمانی را درگیر کامپایل توابع کنیم که از نظر شروع سرد اصلا به صرفه نیست.

الگوی گرم‌کننده توابع (Function Warmer): گاهی اوقات به دلیل محدودیت‌هایی که داریم می‌خواهیم تابع دچار مشکل شروع سرد نشود. از آنجایی که هر تابع مدت‌ زمان اندکی پس از اجرا گرم می‌ماند و اگر فراخوانی نشد منابع آن گرفته ‌می‌شود، بنابراین باید به نحوی این مشکل را دور زد. یک راه حل قدیمی که به عنوان الگویی برای معماری سامانه‌های بدون‌سرور در آمده‌است، الگوی گرم‌کننده توابع است. این الگو اینگونه عمل می‌کند که تابعی به صورت دوره‌ای و در intervalای مشخص، اقدام به صدا زدن توابع می‌کند تا آن‌ها اصطلاحا سرد نشوند. ابزارهایی مانند Amazon Cloudwatch چنین امکانی در اختیار کاربران قرار می‌دهند. البته این راه‌کار از نظر هزینه اصلا بهینه نیست و در معماری سامانه‌های بدون‌سرور به هیچ‌عنوان یک به‌روش محسوب نمی‌شود.

توابع بزرگ (oversized function): در رایانش بدون سرور، امکان انتخاب نوع و تعداد cpu و حافظه به طور مجزا را نداریم. طبق قاعده‌ای کلی تعداد cpuها به ازای ۲ برابر شدن حافظه بزرگتر می‌شوند. بنابراین حین درخواست تابعی که مثلا cpu زیادی تب می‌کند، باید حافظه‌ را بزرگ درنظر گرفت حتی اگر این میزان از حافظه نیاز نباشد.

الگوی Read-heavy report engine: گاهی اوقات داده‌هایی که باید خوانده شوند که یا درخواست‌های خواندن زیادی برای آن‌ها وجود دارد یا پاسخ‌دادن به آن بسیار سنگین و زمانبر است. بنابراین همچون معماری‌هایی مانند میکروسرویس، بهتر است از یک حافظه کش برای پاسخ‌ دادن به درخواست‌ها استفاده کنیم. این کار باعث افزایش بهره‌وری و کاهش زمان‌پاسخ نیز می‌شود.

الگوی timeout: گاهی مدت‌ زمان بالای timeout برای یک سرویسی که قرار نیست پاسخی به ما بدهد، تجربه بدی برای کاربر خواهد بود. بهتر است معماری سیستم به‌ گونه‌ای باشد که پاسخ درخواست‌ها کمتر از ۲-۳ ثانیه طول بکشد. اگر سرویس چنین مهمی را رعایت کند، زمان timeoutای حدود ۳۰ ثانیه برای یک سرویس gateway کاملا بی‌معنی است. یعنی علاوه‌ بر اینکه کاربر باید مدت ‌زمان بسیاری را متنظر بماند، درنهایت پاسخ خود را دریافت نخواهد کرد. بنابراین باید timeout سرویس‌های مختلف به صورت متناسب انتخاب شود.

• الگو‌های ارتباطی: این الگو‌ها، الگو‌های معماری برای ارتباط بین توابع هستند.

الگوی جریان‌ها و خط‌ لوله‌ها: یکی از ویژگی‌های مهمی که اغلب می‌بینیم، پردازش جریان‌های داده است، به همان سرعتی که داده‌ها تولید می‌شوند و به سرعت مقیاس می‌شوند تا تقاضای حجم زیادی از رویدادها را برآورده کنند. سرویس‌های پایین دست جریان را دریافت می‌کنند و منطق تجاری را برای تبدیل، تجزیه و تحلیل یا توزیع داده‌ها اعمال می‌کنند. نمونه‌های متداول، ثبت رفتار کاربر مانند جریان‌های کلیک و تعاملات رابط کاربری است. مواردی از استفاده شامل داده‌ها برای تجزیه و تحلیل داده‌های حسگرهای اینترنت اشیا و غیره است. سرویس Kinesis Analytics داده‌های جستجوی سریع را در جریان در زمان واقعی ارائه می‌دهد. با ادغام S3 تمام داده‌ها برای تجزیه و تحلیل آینده و بینش واقعی ذخیره می‌شوند. آتنا برای تمام داده‌های تاریخی پرس و جو فراهم می‌کند. در واقع پردازش چنین جریاناتی با استفاده از ابزار‌هایی انجام می‌گیرد که ارائه‌دهنده در اختیار کاربران قرار داده است که در اینجا ما از سرویس AWS Lambda برای پردازش جریانات داده‌ای استفاده کرده‌ایم. همه ارائه دهندگان ابر برای خطوط لوله داده، پردازش جریان، و تجزیه و تحلیل پیشنهاداتی دارند، اما ممکن است به خوبی با خدماتی که بخشی از اکوسیستم آنها نیستند، ادغام شوند. این راه‌کار اگرچه مناسب است اما خطر vendor lock-in را هم دارد.

حالت خارجی (External State):‌ گاهی اوقات چند تابع در حال اجرا نیاز دارند که وضعیت خود را با دیگر توابع به اشتراک بگذارند. راه‌حل این است که پایگاه‌داده واسطه‌ای وجود داشته باشد تا مسئول این باشد تا ارتباط توابع از طریق ثبت و خواندن وضعیت توابع در آن اتفاق بیافتد.

الگوی pub/sub: گاهی می‌خواهیم برای سرویس‌های داخلی که در سامانه‌ خود داریم، اعلان‌هایی را ارسال کنیم. راه‌حل بهینه این است که در صف ارسال پیام یک topic ویژه ایجاد کنیم که مخصوص این‌کار است و در آن صف گیرنده‌های مجاز مشخص شده باشد. این topic بهتر است که مجزا و ایزوله از بقیه topicها باشد. این کار برای سیستم‌هایی است که از معماری رویداد-محور استفاده می‌کنند. این تاپیک‌ها قابلیت ایجاد در سرویس‌هایی مانند kenesis، kafka یا Google's Cloud Pub/Sub را دارد.

• الگو‌های تعیین حق‌دسترسی (Authorization):

الگوی دروازه‌بان (the GateKeeper): گاهی سرویس‌ها سرویس‌هایی را فراخوانی می‌کنند که حق دسترسی به آن‌ها را ندارند. بهتر است در مسیر فراخوانی سرویس‌ها یک سرویس GateKeeper‌ پیاده‌سازی شود که وظیفه‌ آن بررسی header‌ درخواست‌ها و رد یا پذیرش آن‌ها براساس سیاست‌های تعیین حق دسترسی است باشد.

مثال‌هایی از استفاده از معماری بدون سرور

پژو‌هش‌های بسیاری حول استفاده از معماری بدون‌سرور در سامانه‌های ابری انجام گرفته است. در [30] نویسندگان مقاله سعی کرده‌اند تا یک وب‌اپلیکیشن یکپارچه برای رمزگذاری و رمزگشایی پیام‌ها را تحت معماری بدون‌سرور پیاده‌سازی کنند. این برنامه دو بخش به نام createDocument‌ و ReadDocument دارد.

در شکل ۲۷ متد createDocument نشان داده شده‌است. برطبق این متد، در ابتدا متن وارد شده، سپس الگوریتم رمزنگاری داده‌ها مشخص شده و یک عبارت به عنوان کلید رمزنگاری مشخص می‌شود. پس از مشخص‌ شدن این موارد، سند باید فشرده شود، سپس رمزگذاری شود و در قالب یک URL دربیاید. در مرحله آخر نیز این فایل URL در حافظه کپی شود.

شکل ۲۸، شیوه خواندن URL و رمزگشایی را نشان می‌دهد. پس از وارد کردن یک URL معتبر، صفحه‌ای می‌آید تا عبارت کلید رمزگشایی را وارد کنیم. سپس در صورت معتبربودن کلید، عبارت رمزگشایی و پس از آن Decompress می‌شود. در مرحله‌نهایی یک عبارت رمزگشایی شده به رندر گرفته می‌شود و به کاربر نشان داده می‌شود.

در [31] نویسندگان اقدام به توسعه‌ چت‌بات با پشتیبانی از صدا با معماری بدون‌سرور کرده‌اند. این سیستم از APIهای IBM Watson برای هماهنگی و انجام کارهای محول‌شده استفاده می‌کند. کارهایی که این سیستم پشتیبانی می‌کند، عبارتند از تعریف لطیفه و جوک، وضعیت آب‌وهوای شهر‌ها، آموزش موسیقی و یادآوری تاریخ‌ها و مناسبت‌ها است. دلایل مهاجرت توسعه‌دهندگان این سامانه به معماری بدون سرور، مقیاس‌پذیری خودکار و دسترس‌پذیری بالای سامانه‌های ابری بوده و از سکوی Apache Openwhisk برای میزبانی برنامه‌ خود استفاده کرده‌اند. شکل ۳۱ بخش‌های مختلف این برنامه را نمایش می‌دهد.

طبق شکل ۳۱، این برنامه از سرویس‌های زیر تشکیل شده است:

• سرویس Audio I/O‌: این سرویس مسئول تبدیل صدا به متن و بالعکس است و یکی از APIهای سرویس IBM Watson است.
• سرویس Text I/O: این سرویس مسئول این است تا موضوع اصلی دیالوگی که برقرار شده است را پیدا کند و آن را در یکی از دسته‌بندی‌های موجود قرار دهد.
• سرویس Speech-to-Action: این سرویس از Watson Alchemy استفاده می‌کند تا سرویس مربوطه را فراخوانی کند.
• سرویس Abilities: این سرویس با استفاده از پارامتر‌هایی که در بخش Speech-to-Action مشخص شده، توابعی در محدوده توانایی‌های خودش فراخوانی می‌کند.
• سرویس‌های شخص ثالث: سرویس‌هایی هستند که عملیات مورد نظر از آن‌ها درخواست می‌شود.

برای مثال، اگر بخواهیم یک سرویس اعلام دمای آب و هوا از روی صدا را مورد مطالعه قرار دهیم، جریان کاری آن به شکل ۳۲ می‌شود.

در ابتدا با استفاده از API‌ سرویس Watson Stt صوت تبدیل به متن می‌شود. در مرحله بعدی دسته‌بندی دیالوگ از روی الگو‌های دیالوگ مشخص می‌شود. حال که مشخص شد سرویس از نوع درخواست آب و هوا بر اساس نام شهر است؛ باید ابتدا نام ‌شهر استخراج شود. سپس با استفاده از API سرویس آب‌وهوا موقعیت lat & lon شهر استخراج شود و از روی مختصات جغرافیایی گزارش آب و هوا استخراج شود. در نهایت سرویس TTS این گزارش را به صوت تبدیل می‌کند و برای کاربر می‌خواند.

یکی دیگر از کارهایی که در حوزه معماری بدون‌سرور انجام گرفته است، معماری بدون‌سرور در بستر یک سیستم اینترنت اشیا است. از نظر نویسندگان مقاله [32] یک معماری خوب باید قابل اطمینان باشد، محاسبات ایمن داشته باشد، مزیت رقابتی‌ برنامه و کسب‌وکار را بتواند به راحتی پیاده‌سازی کند و امنیت را در ابعاد گوناگون معماری سامانه پیاده‌سازی کند. امنیت در سامانه‌های اینترنت اشیا شامل امنیت در برابر هک سامانه و مکانیزم‌هایی برای مقابله با آسیب‌پذیری‌ها و یا بازیابی سیستم پس از خطا‌های عامل انسانی است. معماری پیشنهادی [32] سامانه‌ای متشکل از ۳ لایه فیزیکی، لبه/مه و ابری است. معماری سامانه در شکل ۳۳ مشخص شده است.

بلوک‌های بلاک‌چین می‌تواند در نود‌های مختلف میزبان در لایه‌های ابری یا مه قرار داشته باشد. بلاک‌چین در اینجا دیتابیس‌های غیرقابل تغییر درنظر گرفته‌شده‌اند. داده‌های بلاک‌چین نیز قابلیت orchestrate شدن حین کم و زیاد شدن ماشین‌های مجازی را دارند.

کار دیگری که در حوزه معماری بدون‌سرور در اینترنت اشیا صورت گرفته مدل CSPOT [33] است که هدف آن ارائه مدلی ایمن و سریع است که با سیستم AWS Lambda IOT قابلیت رقابت داشته باشد. از نظر نویسندگان مقاله به دلیل ماهیت فراخوانی براساس رخداد‌ها، اینترنت اشیا و معماری بدون‌سرور بریکدیگر منطبق هستند. بلوک‌های پایه‌ای در CSPOT اشیا حافظه‌داری به نام WOOF است که حالت‌های برنامه را در خودنگه می‌دارند. با فراخوانی رویداد‌ها یک شئی WOOF برای هر تابع ساخته و اطلاعات وضعیت برنامه در آن نگه‌داری می‌شود. توسعه‌دهندگان CSPOT آن را برروی کانتنر‌های داکر و سیستم همنواساز Docker Swarm ایجاد کرده‌اند. سپس آن را در یک سناریو ارزیابی دمای گلخانه‌های کشاورزی توسط نودهایی که برروی رزبری‌پای پیاده‌سازی کرده‌اند، بررسی می‌کنند. در جدول ۳ مقایسه زمان‌پاسخ AWS Lambda IOT با CSPOT ذکر شده است.

در [35] محققین اقدام به پیاده‌‌سازی برنامه‌های پردازش ویدیو‌ در معماری بدون‌سرور کرده‌اند. معماران این سیستم با استفاده از الگوی pipe and filter اقدام به پیاده‌سازی ۲ جریان‌کاری برای این برنامه کرده‌اند. جریان کاری اول، اعمال فیلتر‌های تصویری مختلف بر ویدیو است که جریان‌کاری آن در شکل ۳۴ نمایش داده شده است.

در این جریان ویدیو‌ها در ابتدا decodeمی‌شوند، سپس فیلتر مربوطه بر آن‌ها اعمال شده و سپس encode‌ می‌شوند. در نهایت، خروجی با فرمت دلخواه داده ‌می‌شود. جریان کاری دیگر هنگامی‌ است که بخواهیم در یک فیلم به دنبال سکانس‌هایی باشیم که فرد خاصی در آن حضور دارد (مثلا سکانس‌هایی که در یک فیلم از حیاط مدرسه که کودک مشخصی در آن حاضر است). جریان‌کاری این برنامه در شکل ۳۵ نمایش داده شده است.

همانطور که شکل ۳۵ نشان می‌دهد، برای ساخت یک ویدیو جدید در یک جریان کاری مجزا، نام فرد وارد می‌شود و تصویر مدنظر را انتخاب می‌کنیم. سپس در ویدیو‌ مجزایی فایل ویدیویی decodeشده، scene صحنه از بین صحنه‌های موجود تغییر داده می‌شود تا بهترین وضعیت شناسایی فرد صورت گیرد؛ سپس، صورت شناسایی می‌شود و بر روی فیلم علايمی جهت شناسایی فرد کشیده می‌شود. در نهایت فایل ویدیویی encode شده و به فرمت دلخواه در‌می‌آید. این برنامه قابلیت‌های دیگری مانند Streaming را نیز در اختیار کاربران گذاشته‌است.

در [36] یک معماری برای data lake که در توصیف داده‌های بزرگ کاربرد دارد ارائه شده‌است. چالش این معماری این است که داده‌ها حجم عظیمی دارند و مدیریت این میزان از داده‌ها بسیار چالش برانگیز است. در این معماری سعی شده‌ است که ذخیره‌سازی و پردازش داده‌ها با هم به کار برده شود. معمای این برنامه در شکل ۳۶ نشان داده ‌شده است.

دریاچه داده (Data Lake) چیست؟ دریاچه‌داده یک مخزن است که در آن ما شروع به آوردن کل داده های سازمانی در یک مکان مرکزی می کنیم. این امر حیاتی است زیرا کسب‌وکارها یا سازمان‌ها با انواع مختلفی از داده‌ها سروکار دارند که هم داخلی و هم خارجی را شامل می‌شود. علاوه بر این، داده ها می توانند در قالب های متعددی باشند.

در طراحی دریاچه‌داده ۴ لایه در نظر گرفته شده است:

1. منطقه خام: برای آوردن داده ها چگونه می توانیم داده‌ها را از منابع خارجی مختلف به ساختار یا سیستم خود بیاوریم و ذخیره کنیم؟ چگونه می توانیم داده های ارتباطی یا رسانه های اجتماعی را بیاوریم؟ چگونه می توانیم داده های مشتری خود را بیاوریم؟ اولین قدم ما آوردن و ذخیره داده ها از همه منابع خارجی است.

2. منطقه انتخاب شده: برای استانداردسازی داده‌ها چگونه می توانیم داده‌ها را مدیریت کنیم؟ همانطور که داده‌هایی که ما آورده‌ایم از منابع مختلف است و به همین دلیل است که وجود آن در قالب‌های مختلف آشکار است.

3. منطقه اکتشافی: برای کاوش الگوهای داده های پنهان چیزهای ناشناخته زیادی در داده‌ها وجود دارد. به عنوان مثال، چگونه یک پلت فرم رسانه‌های اجتماعی، توییتر بر قیمت سهام تأثیر می‌گذارد. در لایه سوم دریاچه داده، ما در تلاشیم تا به چیزهای پنهان موجود در داده‌ها پی ببریم.

4. منطقه تامین: برای تولید داده‌ها لایه چهارم دریاچه داده در حال تولید است. اکنون، ما برنامه های تجاری یا شرکتی خود را اجرا می‌کنیم. همچنین به عنوان منطقه تامین کننده شناخته می شود که داده‌هایی را برای توانمندسازی برنامه‌های تجاری ارائه می‌دهد.

همانگونه که در شکل ۳۶ نشان داده شده است، معماری این سیستم کاملا وابسته به سکوی AWS Lambda است و از سرویس‌های آن استفاده می‌کند. در لایه اول، مسئله این است که چگونه می‌توانیم به منابع خارجی مختلف متصل شویم تا داده‌های کامل را به منطقه خام بیاوریم. در مرحله دوم، با استفاده از خدمات Glue، داده‌های خام را به داده‌های انتخاب شده تغییر دادیم. مرحله سوم ارتقای داده‌ها برای کشف است. در اینجا، کشف به این معنی است که ما نگاهی دقیق به داده‌های انتخاب شده می‌کنیم و برای اینکار از سرویس Amazon SeigeMaker استفاده شده است. در نهایت، در منطقه ارائه، از طیف آمازون آتنا استفاده می‌کنیم. هر دوی این سرویس ها دارای قابلیت ذخیره‌سازی داده هستند. با استفاده از این خدمات، می‌توان جداول فرآیند را برای تقویت برنامه‌های تجاری خود ساخت.

در [37] کاری مشابه [26] انجام شده است که در آن از FaaS و معماری بدو‌ن‌سرور برای تبدیل سند‌های متنی استفاده شده است. معماری این سیستم این بار بر پایه AWS Lambda است و این بار از سرویس‌های پایه‌ای آن استفاده می‌کند.

مزیت این معماری نسبت به معماری‌های قبلی در هزینه به ازای درخواست و سرعت بالاتر اجرای درخواست‌هاست. تا جایی که در شکل ۳۸ نیز این محاسبه به خوبی انجام شده است.

یکی دیگر از کار‌های انجام شده به کمک محاسبات بدون سرور، ایجاد توابع شبکه (NF) به عنوان یک سرویس (NFaaS) است [38]. امروزه با کمک تکنیک مجازی سازی می‌توانیم از توابع شبکه استفاده کنیم ولی حجم بار کاری این مجازی سازی، هزینه‌ها، مقیاس پذیری و برنامه نویسی برای توابع برای ما چالش برانگیز است و با کمک محاسبات بدون سرور مجموعه‌ایی کلیدی از بلوک‌ها برای رسیدگی به این مسائل NFV فراهم می‌شود.

ایده این مقاله بدین صورت است که تخصیص کارها و بحث‌های برنامه نویسی برای بسته‌هایی که از طریق جریان‌های مختلف به ما میرسد را از هم جدا کنیم. یعنی ما رسیدن یک جریان را به عنوان یک رویداد تلقی کنیم و سپس براساس نیاز آن جریان را به تابع مناسب هدایت کنیم.

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

در معماری پلتفرم NFaaS بدون سرور SNF ما دو جز اصلی داریم: 1- کنترل کننده، 2-زمان اجرا NFها

در کنترل کننده ما 3 جز مجزا داریم:1- جداسازی و دانه بندی بسته‌ها و بار‌های کاری دریافت شده(WG) 2- تخصیص بسته‌ها به توابع مناسب(WA) 3 - مدیریت حالت بسته‌ها (SM).

همانطور که میدانیم در Faas ما نیاز به توابع بدون حالت داشتیم و هدف از استفاده از SM این است که ما بتوانیم توابع بدون حالت را در معماری بدون سرور پیاده سازی کنیم در صورتی که برای انجام پردازش به حالت‌های آن نیاز داریم و SM این حالت‌ها را برای ما مدیریت می‌کند و این کار را به کمک یک سری حافظه و remote control انجام می‌دهد تا در صورت نیاز به آن مراجعه شود.

زمان اجرا NFها وظیفه‌ی مدیریت حالت هر واحد محاسباتی را برعهده دارد.

لازم به ذکر است ایده‌ایی که در این مقاله مطرح شده است توسط ارائه دهنده‌های کمی پشتیبانی شده و محدودیت‌های خیلی زیادی برای استفاده از آن اعمال شده است.

جمع‌بندی و نتیجه‌گیری

در این پژوهش سعی کرده‌ایم تا هر آنچه‌ که یک معماری نرم‌افزار برای مهاجرت به معماری ابری نیاز دارد را جمع آوری کرده تا بتواند تصمیم بهتری برای مهاجرت به معماری بدون‌سرور داشته باشد. مواردی که در این گزارش ذکر شد شامل مفاهیم رایانش‌ بدون‌سرور، FaaS، BaaS، ارائه‌دهندگان خدمات بدون‌سرور، سکو‌های بدون سرور، مقایسه‌ بین آن‌ها از جنبه‌های مختف، الگو‌های معماری سامانه‌های بدون سرور و مثال‌هایی برای مهاجرت به معماری بدون‌سرور بوده است.

متاسفانه معماری بدون‌سرور آن‌چنان که شایسته است در کشور ما جا نیافتاده است. البته این موضوع می‌تواند دلایل مختلفی از جمله تازگی این مبحث و تحریم‌ تمامی ارائه‌دهندگان خدمات ابری علیه ایرانیان باشد. در پژوهش‌های آتی در این حوزه قصد داریم به راه‌های کاهش شروع سرد در معماری‌های بدون‌سرور بپردازیم و مثال‌هایی از مهاجرت به معماری بدون سرور را ارائه‌دهیم.

مراجع و منابع

[1] Roberts, M. (2016). Serverless architectures. https://martinfowler. com/articles/serverless.html, 4.

[2] Shafiei, H., Khonsari, A., & Mousavi, P. (2019). Serverless computing: A survey of opportunities, challenges and applications. arXiv preprint arXiv:1911.01296.

[3] Hassan, H. B., Barakat, S. A., & Sarhan, Q. I. (2021). Survey on serverless computing. Journal of Cloud Computing, 10(1), 1-29.

[4] van Eyk, E., & Iosup, A. (2018). Addressing performance challenges in serverless computing. In Proc. ICT. OPEN.

[5] Gadepalli, P. K., Peach, G., Cherkasova, L., Aitken, R., & Parmer, G. (2019, October). Challenges and opportunities for efficient serverless computing at the edge. In 2019 38th Symposium on Reliable Distributed Systems (SRDS) (pp. 261-2615). IEEE.

[6] Shafiei, H., Khonsari, A., & Mousavi, P. (2019). Serverless computing: A survey of opportunities, challenges and applications. arXiv preprint arXiv:1911.01296.

[7] Manco, F., Lupu, C., Schmidt, F., Mendes, J., Kuenzer, S., Sati, S., ... & Huici, F. (2017, October). My VM is Lighter (and Safer) than your Container. In Proceedings of the 26th Symposium on Operating Systems Principles (pp. 218-233).

[8] Jambunathan, B., & Yoganathan, K. (2018, March). Architecture decision on using microservices or serverless functions with containers. In 2018 International Conference on Current Trends towards Converging Technologies (ICCTCT) (pp. 1-7). IEEE.

[9] https://aws.amazon.com/lambda/

[10] https://cloud.google.com/functions

[11] https://azure.microsoft.com/en-us/services/functions/

[12] https://www.oracle.com/cloud-native/functions/

[13] https://developers.cloudflare.com/pages/platform/functions

[14] https://cloud.ibm.com/functions/

[15] Hendrickson, S., Sturdevant, S., Harter, T., Venkataramani, V., Arpaci-Dusseau, A. C., & Arpaci-Dusseau, R. H. (2016). Serverless computation with openlambda. In 8th {USENIX} Workshop on Hot Topics in Cloud Computing (HotCloud 16).

[16] Pfandzelter, T., & Bermbach, D. (2020, April). tinyfaas: A lightweight faas platform for edge environments. In 2020 IEEE International Conference on Fog Computing (ICFC) (pp. 17-24). IEEE.

[17] Carreira, J., Fonseca, P., Tumanov, A., Zhang, A., & Katz, R. (2019, November). Cirrus: A serverless framework for end-to-end ml workflows. In Proceedings of the ACM Symposium on Cloud Computing (pp. 13-24).

[18] Daw, N., Bellur, U., & Kulkarni, P. (2020, December). Xanadu: Mitigating cascading cold starts in serverless function chain deployments. In Proceedings of the 21st International Middleware Conference (pp. 356-370).

[19] Ghaemi, S., Khazaei, H., & Musilek, P. (2020). ChainFaaS: An open blockchain-based serverless platform. IEEE Access, 8, 131760-131778.

[20] Maissen, P., Felber, P., Kropf, P., & Schiavoni, V. (2020, July). Faasdom: A benchmark suite for serverless computing. In Proceedings of the 14th ACM International Conference on Distributed and Event-based Systems (pp. 73-84).

[21] Martins, H., Araujo, F., & da Cunha, P. R. (2020). Benchmarking serverless computing platforms. Journal of Grid Computing, 18(4), 691-709.

[22] https://claudiajs.com/

[23] Zhang, W., Fang, V., Panda, A., & Shenker, S. (2020, October). Kappa: A programming framework for serverless computing. In Proceedings of the 11th ACM Symposium on Cloud Computing (pp. 328-343).

[24] Tankov, V., Golubev, Y., & Bryksin, T. (2019, November). Kotless: A serverless framework for kotlin. In 2019 34th IEEE/ACM International Conference on Automated Software Engineering (ASE) (pp. 1110-1113). IEEE.

[25] Manner, J., Kolb, S., & Wirtz, G. (2019). Troubleshooting serverless functions: a combined monitoring and debugging approach. SICS Software-Intensive Cyber-Physical Systems, 34(2), 99-104.

[26] Goli, A., Hajihassani, O., Khazaei, H., Ardakanian, O., Rashidi, M., & Dauphinee, T. (2020, April). Migrating from monolithic to serverless: A fintech case study. In Companion of the ACM/SPEC International Conference on Performance Engineering (pp. 20-25).

[27] https://medium.com/@taibi.davide/serverless-patterns-e1fb3f1d753e

[28] https://www.infoq.com/articles/design-patterns-for-serverless-systems/

[29] https://medium.com/@eduardoromero/serverless-architectural-patterns-261d8743020

[30] Prasetyadi, G., Hantoro, U. T., Mutiara, A. B., Muslim, A., & Refianti, R. (2019, October). Heresy: A serverless web application to store compressed and encrypted document in the form of url. In 2019 Fourth International Conference on Informatics and Computing (ICIC) (pp. 1-5). IEEE.

[31] Yan, M., Castro, P., Cheng, P., & Ishakian, V. (2016, December). Building a chatbot with serverless computing. In Proceedings of the 1st International Workshop on Mashups of Things and APIs (pp. 1-4).

[32] Benedict, S. (2020). Serverless blockchain-enabled architecture for iot societal applications. IEEE Transactions on Computational Social Systems, 7(5), 1146-1158.

[33] Wolski, R., Krintz, C., Bakir, F., George, G., & Lin, W. T. (2019, November). Cspot: Portable, multi-scale functions-as-a-service for iot. In Proceedings of the 4th ACM/IEEE Symposium on Edge Computing (pp. 236-249).

[35] Ao, L., Izhikevich, L., Voelker, G. M., & Porter, G. (2018, October). Sprocket: A serverless video processing framework. In Proceedings of the ACM Symposium on Cloud Computing (pp. 263-274).

[36] Rahman, M. M., & Hasan, M. H. (2019, October). Serverless architecture for big data analytics. In 2019 Global Conference for Advancement in Technology (GCAT) (pp. 1-5). IEEE.

[37] Chahal, D., Ojha, R., Ramesh, M., & Singhal, R. (2020, October). Migrating large deep learning models to serverless architecture. In 2020 IEEE International Symposium on Software Reliability Engineering Workshops (ISSREW) (pp. 111-116). IEEE.

[38] Singhvi, A., Khalid, J., Akella, A., & Banerjee, S. (2020, October). Snf: Serverless network functions. In Proceedings of the 11th ACM Symposium on Cloud Computing (pp. 296-310).

«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است»