آشنایی با معماری Serverless در کلود

اگر تاکنون اخبار مربوط به سرویس‌های کلود را دنبال کرده باشید، احتمالاً می‌دانید که تکنولوژی‌های قدیمی هاستینگ و سرورها جای خود را با سرویس‌های ابری عوض کرده‌اند؛ یکی از ویژگی‌هایی که سرویس‌های کلود دارند این است که سرویس مورد نظر شما بر روی چندین سرور کلود در سراسر جهان در حال اجرا است و در صورتی که یکی از این سرورها از کار بیفتد، سرور دیگری به کاربران شما سرویس‌دهی خواهد کرد. در حال حاضر معماری Serverless و Function as a service که به اختصار FaaS گفته می‌شود، جزو جذاب‌ترین مباحث کلود کامپیوتینگ‌ هستند. در این مقاله قصد داریم توضیحات مختصری در مورد معماری Serverless برای شما ارائه دهیم؛ در ادامه با سکان‌آکادمی همراه باشید.

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

به عبارت دیگر، این سطح، سخت‌افزار موجود در دیتاسنتر را از لایهٔ نرم‌افزار جدا نموده است و برای گسترش این سطح نیاز به ارتقاء سخت‌افزار است. درست زمانی که مجازی‌سازی به حد قابل قبولی از تکامل رسید، شرکت‌هایی که سرویس هایی از قبیل VPS و ... ارائه می‌دادند اقدام به ارائه سرویس‌های خود بر بستر کلود نمودند.

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

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

معماری Serverless
در این معماری معیار اندازه‌گیری مدت زمانی است که تابع مورد نظر شما در حال استفاده منابع سرور بوده است؛ در این معماری بحث بر سر این موضوع نیست که چه مقدار RAM یا CPU برای اجرای تابع مورد نظر شما نیاز است بلکه فقط مدت زمانی که طول می‌کشد تا تابع شما اجرا شود بررسی می‌شود. در‌واقع، هیچ یک از معیارهای قدیمی در این معماری در نظر گرفته نمی‌شوند! شما تابع مورد نظر خود را می‌نویسید، آن را بر روی کلود پابلیش می‌کنید و فقط به اندازهٔ زمانی که تابع شما طول کشیده است تا اجرا شود هزینه پرداخت می‌کنید.

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

حال بیاییم نیم‌نگاهی به مسئلهٔ FaaS بیندازیم؛‌ Mike Roberts اقدام به بررسی ۶ موضوع در رابطه با FaaS کرده است که عبارتند از:

1. به صورت پایه‌ای، FaaS در رابطه با این است که کد بک‌اند شما اجرا می‌شود بدون آن‌که نیازی باشد شما سرور را مدیریت کنید یا این‌که نرم‌افزار موجود بر روی سرور را مدیریت کنید.

2. FaaS شما را محدود به استفاده از یک لایبرری یا فریمورک خاصی نمی‌کند؛ توابع FaaS زمانی که به این محیط وارد می‌شوند همچون یک اپلیکیشن معمولی هستند.

3. به این دلیل که هیچ اپلیکیشنی برای سرور وجود ندارد که اجرا شود، نحوه پابلیش شدن تابع مورد نظر کاملاً با شیوه‌های سنتی که قبلاً وجود داشته است فرق می‌کند. کد مورد نظر بر روی سرور آپلود می‌شود و بقیه کارها توسط ارائه‌دهندهٔ FaaS انجام می‌شود.

4. پیمایش عرضی به صورت کاملاً خودکار صورت می‌گیرد، منعطف است و توسط ارائه‌دهنده مدیریت می‌شود.

5. توابع FaaS بر اساس رویدادهایی که توسط ارائه‌دهنده مشخص شده است اجرا می‌شوند.

6. بیشتر ارائه‌دهندگان این سرویس اجازهٔ اجرا شدن تابع برای پاسخ به یک درخواست HTTP ورودی را می‌دهند.

در‌واقع توابعی که زمان زیادی را برای اجرا می‌طلبند به صرفه نیست که بر روی این معماری اجرا شوند؛‌ به طور کلی، شرکت‌های ارائه‌دهندهٔ سرویس FaaS عبارتند از:

- سرویس Azure Functions مایکروسافت
- سرویس AWS Lambda آمازون 
- سرویس Webtask 
- سرویس IronWorker
- سرویس Webscript

سرویس‌های بسیار دیگری نیز وجود دارند اما تفاوتی که این سرویس‌ها با یکدیگر دارند، امکانات فنی است که هر یک دارند و همچنین نحوهٔ چگونگی استفاده است.

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

A Short Introduction to Serverless Architecture

0







از طریق این فرم، می توانید بدون ثبت نام نظر دهید و یا اگر قبلا ثبت نام کرده اید، با ورود ناحیه ی کاربری می توانید علاوه بر ثبت نظر، به مدیریت نظرات خود نیز بپردازید.
(فیلد اجباری)
(فیلد اجباری)
(فیلد اجباری)
(فیلد اجباری)