Serverless چیست؟ راهنمای کامل معماری بدون سرور، مزایا، معایب و کاربردها

Serverless یا معماری بدون سرور، رویکردی در Cloud Computing است که در آن توسعه‌دهنده لازم نیست مستقیماً Serverها و بخش زیادی از زیرساخت موردنیاز برای اجرای Application را مدیریت کند. در این مدل، Cloud Provider مسئولیت‌هایی مانند Provisioning، نگهداری و مدیریت زیرساخت را تا حد زیادی بر عهده می‌گیرد

البته عبارت «بدون سرور» کمی گمراه‌کننده است. Server همچنان وجود دارد و Application روی Infrastructure واقعی اجرا می‌شود؛ تفاوت اصلی این است که مدیریت آن Infrastructure از دید توسعه‌دهنده تا حد زیادی پنهان می‌شود.

در معماری سنتی، تیم فنی ممکن است مجبور باشد Server تهیه کند، سیستم‌عامل را تنظیم کند، ظرفیت منابع را مشخص کند و برای افزایش Traffic برنامه‌ریزی داشته باشد. در Serverless، بخش قابل‌توجهی از این مسئولیت‌ها به Provider واگذار می‌شود و تیم توسعه می‌تواند تمرکز بیشتری روی Code و منطق Application داشته باشد.

یکی از مهم‌ترین ویژگی‌های Serverless این است که منابع معمولاً بر اساس نیاز Workload مصرف می‌شوند. بنابراین به‌جای اینکه همیشه یک Server مشخص در حال اجرا باشد، Application می‌تواند در پاسخ به Event یا Request اجرا شود.

به همین دلیل، Serverless بیشتر از اینکه به معنی حذف Server باشد، به معنی کاهش مسئولیت مدیریت Server برای تیم توسعه است.

Serverless  چگونه کار می‌کند؟

در یک معماری Serverless، Application معمولاً به بخش‌های کوچک‌تر تقسیم می‌شود که می‌توانند در پاسخ به یک Event اجرا شوند.

برای مثال، تصور کنید کاربری در یک فروشگاه اینترنتی تصویری را آپلود می‌کند. این اتفاق می‌تواند یک Event ایجاد کند و یک Function Serverless را اجرا کند. Function می‌تواند تصویر را دریافت کند، اندازه آن را تغییر دهد و نسخه پردازش‌شده را در Storage ذخیره کند.

فرآیند کلی می‌تواند چنین باشد:

Event → Function → Processing → Response / Storage

در این مدل، توسعه‌دهنده بیشتر روی Code مربوط به Function تمرکز می‌کند و Provider مسئول فراهم کردن محیط اجرای آن است.

یکی دیگر از ویژگی‌های Serverless، Auto Scaling است. اگر تعداد درخواست‌ها افزایش پیدا کند، پلتفرم می‌تواند تعداد Executionها را متناسب با Workload افزایش دهد. پس از کاهش درخواست‌ها نیز منابع موردنیاز می‌توانند کاهش پیدا کنند.

البته نحوه Scaling، محدودیت‌های Execution و مدل Pricing به سرویس و Provider مورد استفاده بستگی دارد.

اجزای اصلی معماری Serverless

Serverless یک محصول یا فناوری واحد نیست و معمولاً از چند نوع سرویس در کنار یکدیگر تشکیل می‌شود. دو مفهوم مهم در این معماری، FaaS و BaaS هستند.

FaaS یا Function as a Service به مدلی گفته می‌شود که در آن توسعه‌دهنده Functionهای کوچک را می‌نویسد و Provider محیط اجرای آن‌ها را مدیریت می‌کند. این Functionها معمولاً در پاسخ به Event اجرا می‌شوند.

در کنار آن، BaaS یا Backend as a Service قرار دارد. در این مدل، سرویس‌هایی مانند Authentication، Database، Storage یا Messaging می‌توانند به‌صورت Managed Service در اختیار Application قرار بگیرند.

یک معماری Serverless ممکن است از اجزای زیر تشکیل شود:

بنابراین یک Application Serverless لزوماً فقط از Function تشکیل نشده است. معمولاً مجموعه‌ای از سرویس‌های Managed در کنار Functionها قرار می‌گیرند و Backend سیستم را تشکیل می‌دهند.

FaaS چیست و چه ارتباطی با Serverless دارد؟

FaaS یا Function as a Service یکی از مهم‌ترین الگوهای مرتبط با Serverless است. در این مدل، Application به Functionهای کوچک تقسیم می‌شود و هر Function وظیفه مشخصی را انجام می‌دهد.

برای مثال، یک Application می‌تواند Function جداگانه‌ای برای ثبت سفارش، پردازش تصویر یا ارسال Notification داشته باشد. هر Function می‌تواند در زمان موردنیاز اجرا شود و پس از پایان Execution، محیط اجرای آن دیگر نیازی به مدیریت مستقیم توسط توسعه‌دهنده ندارد.

این مدل باعث می‌شود توسعه‌دهنده به‌جای مدیریت یک Server دائمی، روی منطق مربوط به Function تمرکز کند.

با این حال، FaaS و Serverless کاملاً مترادف نیستند. FaaS یکی از رایج‌ترین روش‌های اجرای Serverless Workloadهاست، اما Serverless مفهوم گسترده‌تری دارد و سرویس‌های Managed دیگری مانند Database، Storage و Authentication را نیز شامل می‌شود.

به زبان ساده:

FaaS = اجرای Function به‌عنوان سرویس

Serverless = معماری گسترده‌تری که می‌تواند FaaS و سایر Managed Serviceها را شامل شود

این تفاوت هنگام طراحی معماری اهمیت دارد؛ زیرا یک سیستم Serverless می‌تواند علاوه بر Functionها، به سرویس‌های مختلف دیگری نیز وابسته باشد.

BaaS  چیست؟

BaaS یا Backend as a Service رویکردی است که در آن بخش‌هایی از Backend Application به شکل سرویس آماده در اختیار توسعه‌دهنده قرار می‌گیرد.

برای مثال، یک تیم توسعه ممکن است به‌جای پیاده‌سازی کامل سیستم Authentication، از یک سرویس آماده برای ثبت‌نام، ورود کاربران و مدیریت Identity استفاده کند.

سرویس‌هایی مانند Database، Storage، Authentication، Messaging و Notification می‌توانند در یک معماری Serverless نقش BaaS داشته باشند.

مزیت اصلی این مدل، کاهش مقدار Infrastructure و Backend Codeای است که تیم باید خودش طراحی و مدیریت کند. توسعه‌دهندگان می‌توانند از سرویس‌های آماده استفاده کنند و تمرکز بیشتری روی قابلیت‌های اصلی Application داشته باشند

فرض کنید قرار است یک Application موبایل ساخته شود. تیم می‌تواند از یک سرویس Managed برای Authentication و Storage استفاده کند و فقط منطق اختصاصی محصول خود را توسعه دهد.

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

مزایای Serverless

یکی از جذاب‌ترین ویژگی‌های Serverless، کاهش مسئولیت مدیریت Infrastructure است. توسعه‌دهنده لازم نیست برای بسیاری از Workloadها مستقیماً Server Provision کند یا ظرفیت آن را به‌صورت دستی مدیریت کند

Scalability  نیز اهمیت زیادی دارد. در بسیاری از سناریوها، پلتفرم می‌تواند اجرای Functionها را بر اساس تعداد درخواست‌ها افزایش یا کاهش دهد. این قابلیت برای Workloadهایی که Traffic متغیری دارند بسیار کاربردی است.

از طرف دیگر، Serverless می‌تواند به کاهش زمان توسعه کمک کند. استفاده از سرویس‌های Managed باعث می‌شود تیم توسعه برای قابلیت‌هایی مانند Authentication، Storage یا بعضی سرویس‌های Backend، کمتر درگیر ساخت Infrastructure از صفر شود.

مدل هزینه نیز می‌تواند یک مزیت باشد. در بسیاری از سرویس‌های Serverless، هزینه بر اساس میزان استفاده محاسبه می‌شود و برای Workloadهایی که دائماً فعال نیستند، این مدل می‌تواند جذاب باشد.

مهم‌ترین مزایا را می‌توان این‌طور خلاصه کرد:

• کاهش نیاز به مدیریت مستقیم Server
• امکان Auto Scaling
• سرعت بیشتر در توسعه برخی Applicationها
• استفاده از سرویس‌های Managed
• مناسب بودن برای Workloadهای Event-driven
• پرداخت متناسب با میزان مصرف در بسیاری از سرویس‌ها
• کاهش عملیات Infrastructure برای تیم توسعه

البته این مزایا به نوع Workload و نحوه طراحی معماری بستگی دارند. Serverless در همه پروژه‌ها الزاماً انتخاب بهتری نیست و محدودیت‌هایی مانند Cold Start، محدودیت Execution و Vendor Lock-in نیز باید در مراحل بعدی مقاله بررسی شوند.

معایب و محدودیت‌های Serverless

با وجود مزایایی که Serverless دارد، این معماری برای همه Applicationها مناسب نیست. یکی از مهم‌ترین محدودیت‌های آن Cold Start است. زمانی که یک Function برای مدتی اجرا نشده باشد، ممکن است اجرای درخواست جدید به زمان بیشتری نیاز داشته باشد؛ البته شدت این مسئله به Runtime، Provider و نحوه طراحی Application بستگی دارد.

محدودیت دیگر، وابستگی به Cloud Provider است. بسیاری از سرویس‌های Serverless به APIها و قابلیت‌های اختصاصی یک Provider متکی هستند و انتقال Application به محیط دیگر ممکن است نیازمند تغییرات قابل‌توجه باشد.

از طرف دیگر، Debugging و Monitoring در یک سیستم Serverless می‌تواند پیچیده‌تر شود. چون Application ممکن است از تعداد زیادی Function و سرویس Managed تشکیل شده باشد، پیدا کردن علت یک خطا همیشه به سادگی یک Application یکپارچه نیست.

برخی محدودیت‌های مهم Serverless عبارت‌اند از:

• Cold Start در برخی Workloadها
• محدودیت زمان اجرای Function
• پیچیدگی Debugging
• وابستگی احتمالی به Provider
• دشواری Monitoring در معماری‌های بزرگ
• محدودیت‌های Runtime و منابع
• پیچیدگی مدیریت سرویس‌های متعدد

بنابراین قبل از انتخاب Serverless باید بررسی شود که محدودیت‌های این مدل با نیازهای Application سازگار هستند یا خیر.

Serverless  در برابر معماری سنتی

در معماری سنتی، تیم Infrastructure معمولاً مسئول تهیه و مدیریت Serverهاست. ظرفیت منابع نیز باید از قبل تخمین زده شود تا Application بتواند در شرایط مختلف پاسخ‌گو باقی بماند.

در Serverless، بخش قابل‌توجهی از این مسئولیت به Cloud Provider واگذار می‌شود. توسعه‌دهنده Function یا Application خود را Deploy می‌کند و Provider محیط اجرای آن را مدیریت می‌کند.

در نتیجه، Serverless بیشتر برای سازمان‌هایی جذاب است که می‌خواهند تمرکز تیم را از مدیریت Infrastructure به سمت توسعه Application منتقل کنند.

 Serverless در برابر  Containers

Serverless و Containers هر دو می‌توانند برای ساخت Applicationهای Cloud Native استفاده شوند، اما سطح کنترلی که در اختیار توسعه‌دهنده قرار می‌دهند متفاوت است.

در Containerها، تیم معمولاً کنترل بیشتری روی Environment اجرای Application دارد. می‌توان Image را مدیریت کرد، Runtime را مشخص کرد و Container را در محیط‌های مختلف اجرا کرد.

در Serverless، این مسئولیت‌ها بیشتر به Provider واگذار می‌شوند و توسعه‌دهنده معمولاً با یک Abstraction بالاتر کار می‌کند.

برای مثال، اگر Application نیاز به کنترل دقیق Runtime، Network یا Process داشته باشد، Container می‌تواند گزینه مناسبی باشد. اما اگر هدف اجرای سریع Functionهای کوتاه و Event-driven باشد، Serverless می‌تواند انتخاب ساده‌تری باشد.

بنابراین انتخاب میان این دو به Control، Scalability، نوع Workload و پیچیدگی عملیاتی بستگی دارد.

 Serverless و DevOps

Serverless مسئولیت Infrastructure را کاهش می‌دهد، اما نیاز به فرآیندهای DevOps را از بین نمی‌برد.

تیم همچنان باید Code را مدیریت کند، Test بنویسد، تغییرات را بررسی کند و Deployment را به شکل قابل‌اعتماد انجام دهد. در اینجا CI/CD می‌تواند نقش مهمی داشته باشد.

برای مثال، با هر تغییر در Code می‌توان Pipelineای ایجاد کرد که مراحل Test، Build و Deployment Function را به‌صورت خودکار انجام دهد.

همچنین Infrastructure as Code می‌تواند برای تعریف API Gateway، Permissionها، Database و سایر منابع استفاده شود.در نتیجه، Serverless می‌تواند مقدار Infrastructure Operation را کاهش دهد، اما Automation و DevOps همچنان بخش مهمی از چرخه توسعه هستند.

امنیت در معماری  Serverless

در Serverless بسیاری از مسئولیت‌های مربوط به Infrastructure بر عهده Provider است، اما Security همچنان مسئولیت مشترک محسوب می‌شود.

یکی از مهم‌ترین موضوعات، Permission Management است. هر Function باید فقط به منابعی دسترسی داشته باشد که واقعاً برای اجرای وظیفه خود نیاز دارد.

برای مثال، Function مربوط به پردازش تصویر نباید بدون دلیل به تمام Databaseها یا سرویس‌های سازمان دسترسی داشته باشد. اجرای اصل Least Privilege می‌تواند سطح ریسک را کاهش دهد.

مدیریت Secrets، Encryption، API Security، Logging و Monitoring نیز اهمیت زیادی دارند.

در معماری Serverless، تعداد Functionها و Endpointها می‌تواند زیاد شود؛ بنابراین مدیریت منظم Identity و Access اهمیت بیشتری پیدا می‌کند.

کاربردهای Serverless

 Serverless برای Workloadهایی که به شکل Event-driven اجرا می‌شوند، کاربرد زیادی دارد. یعنی اجرای Application در پاسخ به یک اتفاق مشخص آغاز می‌شود.

برای مثال، آپلود یک فایل می‌تواند باعث اجرای Function پردازش تصویر شود. دریافت یک Request از API نیز می‌تواند Function مربوط به آن Endpoint را اجرا کند.

برخی کاربردهای رایج Serverless عبارت‌اند از:

• پردازش فایل و تصویر
• Backend برای Applicationهای Web و Mobile
• APIهای سبک
• پردازش Eventها
• ارسال Notification
• Data Processing
• Automation
• اجرای Jobهای کوتاه‌مدت

Serverless همچنین برای Prototypeها و پروژه‌هایی که هنوز میزان Traffic آن‌ها مشخص نیست، می‌تواند گزینه جالبی باشد؛ زیرا نیاز به Provisioning گسترده Infrastructure را کاهش می‌دهد.

 Serverless برای چه پروژه‌هایی مناسب است؟

هیچ معماری‌ای برای همه پروژه‌ها بهترین گزینه نیست. Serverless زمانی جذاب‌تر می‌شود که Workload ماهیت Event-driven داشته باشد یا Traffic آن متغیر باشد.

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

Applicationهایی که نیاز به Scaling سریع، Deploymentهای مکرر و مدیریت کم‌تر Infrastructure دارند نیز می‌توانند کاندیدای مناسبی باشند.

در مقابل، Applicationهایی که نیازمند اجرای مداوم Processهای طولانی، کنترل کامل روی Operating System یا تنظیمات خاص Infrastructure هستند، ممکن است با مدل‌های دیگری سازگاری بیشتری داشته باشند.

چه زمانی نباید از Serverless استفاده کنیم؟

اگر Application نیاز به اجرای طولانی‌مدت و دائمیProcessها داشته باشد،  Serverlessممکن است بهترین انتخاب نباشد؛ زیرا Functionها معمولاً محدودیت‌هایی در زمان Execution و منابع دارند.

همچنین اگر سازمان به کنترل بسیار دقیق روی Infrastructure نیاز داشته باشد، واگذاری بخش زیادی از مدیریت Server به Provider می‌تواند محدودیت ایجاد کند.

Vendor Lock-in نیز باید جدی گرفته شود. اگر Application به تعداد زیادی سرویس اختصاصی Provider وابسته شود، مهاجرت به Cloud دیگر ممکن است دشوار باشد.

پس در چنین شرایطی بهتر است گزینه‌هایی مانند Virtual Machine، Containers یا معماری ترکیبی نیز بررسی شوند.

هزینه Serverless چگونه محاسبه می‌شود؟

یکی از ویژگی‌های مهم Serverless، مدل پرداخت مبتنی بر مصرف است. در بسیاری از سرویس‌ها، عواملی مانند تعداد درخواست‌ها، مدت زمان اجرای Function و میزان منابع مصرف‌شده در هزینه نهایی تأثیر دارند.

این مدل برای Workloadهایی که دائماً فعال نیستند می‌تواند اقتصادی باشد؛ زیرا سازمان لزوماً برای یک Server دائمی هزینه پرداخت نمی‌کند.

اما افزایش شدید تعداد Requestها یا استفاده زیاد از سرویس‌های جانبی می‌تواند هزینه را بالا ببرد. به همین دلیل، Monitoring و Cost Management همچنان ضروری هستند.

در محاسبه هزینه باید فقط قیمت Function را در نظر نگرفت. API Gateway، Database، Storage و Data Transfer نیز می‌توانند بخشی از هزینه نهایی Architecture باشند.

نمونه سرویس‌های Serverless

Cloud Providerهای مختلف سرویس‌های Serverless متنوعی ارائه می‌کنند. در بخش FaaS، سرویس‌هایی برای اجرای Functionها وجود دارند و در کنار آن‌ها، سرویس‌های Managed دیگری برای Database، Storage، Messaging و API نیز قابل استفاده هستند.

به‌عنوان نمونه، در اکوسیستم‌های Cloud می‌توان سرویس‌هایی مانند AWS Lambda،  Azure Functions و Google Cloud Functions را مشاهده کرد.

انتخاب میان این سرویس‌ها بهتر است بر اساس مواردی مانند Runtime، Integration، Pricing، محدودیت‌ها، Security و نیازهای معماری انجام شود؛ نه صرفاً محبوبیت Provider.

جمع‌بندی

Serverless رویکردی در Cloud Computing است که در آن توسعه‌دهنده بخش زیادی از مدیریت مستقیم Server و Infrastructure را به Cloud Provider واگذار می‌کند.

این معماری می‌تواند برای Workloadهای Event-driven، Applicationهای دارای Traffic متغیر و پروژه‌هایی که به توسعه سریع نیاز دارند بسیار کاربردی باشد. Auto Scaling و مدل پرداخت مبتنی بر مصرف نیز از ویژگی‌هایی هستند که Serverless را جذاب می‌کنند.

در مقابل، محدودیت‌هایی مانند Cold Start، محدودیت Execution، پیچیدگی Monitoring و Vendor Lock-in باید پیش از انتخاب آن بررسی شوند.

در نهایت، Serverless قرار نیست جایگزین تمام مدل‌های اجرای Application شود. انتخاب میان Serverless، Containers، Virtual Machines یا معماری ترکیبی باید بر اساس نیاز واقعی Workload انجام شود.

سوالات متداول

• Serverless چیست؟

Serverless معماری‌ای است که در آن مدیریت بخش زیادی از Server و Infrastructure به Cloud Provider واگذار می‌شود و توسعه‌دهنده بیشتر روی Code و منطق Application تمرکز می‌کند.

• آیا در Serverless واقعاً Server وجود ندارد؟

خیر. Serverها همچنان وجود دارند؛ فقط مدیریت بخش زیادی از آن‌ها از دید توسعه‌دهنده پنهان شده و توسط Provider انجام می‌شود.

• FaaS چیست؟

FaaS یا Function as a Service مدلی برای اجرای Functionهای Application به‌صورت سرویس است و یکی از مهم‌ترین فناوری‌های مرتبط با Serverless محسوب می‌شود.

• آیا Serverless همان FaaS است؟

خیر. FaaS بخشی از مفهوم Serverless است. Serverless می‌تواند سرویس‌های Managed دیگری مانند Database، Storage و Authentication را نیز شامل شود.

• مهم‌ترین مزیت Serverless چیست؟

کاهش نیاز به مدیریت مستقیم Infrastructure، امکان Scaling خودکار و تمرکز بیشتر تیم توسعه روی Application از مهم‌ترین مزایای آن هستند.

• مهم‌ترین محدودیت Serverless چیست؟

Cold Start، محدودیت‌های Execution، پیچیدگی Debugging و احتمال Vendor Lock-in از مهم‌ترین محدودیت‌های Serverless هستند.

• آیا Serverless برای Applicationهای بزرگ مناسب است؟

می‌تواند مناسب باشد، اما به Architecture بستگی دارد. Applicationهای بزرگ معمولاً از ترکیبی از Serverless، Containers، Database و سایر سرویس‌های Cloud استفاده می‌کنند.

• تفاوت Serverless و Container چیست؟

در Container معمولاً کنترل بیشتری روی محیط اجرای Application در اختیار تیم است، در حالی که در Serverless بخش بیشتری از مدیریت Infrastructure به Provider واگذار می‌شود.

• آیا Serverless بخشی از Cloud Native است؟

Serverless می‌تواند یکی از مدل‌های مورد استفاده در معماری Cloud Native باشد، اما Cloud Native مفهومی گسترده‌تر از Serverless است.