Function as a Service یا FaaS چیست؟

FaaS یکی از مهم‌ترین مدل‌های اجرای نرم‌افزار در معماری‌های Serverless است که به توسعه‌دهندگان اجازه می‌دهد منطق برنامه را به شکل Functionهای مستقل اجرا کنند، بدون اینکه لازم باشد مستقیماً درگیر مدیریت دائمی سرور، سیستم‌عامل و زیرساخت اجرای آن باشند.

در معماری سنتی، برای اجرای یک سرویس معمولاً باید سرور یا ماشین مجازی ایجاد شود، سیستم‌عامل و Runtime تنظیم شود، منابع CPU و RAM اختصاص داده شود و سپس برنامه روی آن مستقر شود. در FaaS، بخش قابل توجهی از این مسئولیت‌ها به پلتفرم اجراکننده واگذار می‌شود و تیم توسعه بیشتر روی منطق کسب‌وکار و کد Function تمرکز می‌کند.

اما FaaS به معنای «بدون سرور بودن واقعی» نیست. سرورها همچنان وجود دارند؛ تفاوت در این است که مدیریت مستقیم زیرساخت از دید توسعه‌دهنده پنهان می‌شود. به همین دلیل FaaS را باید یکی از مدل‌های Serverless Computing دانست، نه یک فناوری که واقعاً بدون Server اجرا می‌شود.

FaaS مخفف چیست؟

FaaS مخفف Function as a Service و به معنی «تابع به‌عنوان سرویس» است. در این مدل، Application به مجموعه‌ای از Functionهای کوچک‌تر تقسیم می‌شود که معمولاً در پاسخ به یک Event یا Request اجرا می‌شوند.

برای مثال، فرض کنید یک فروشگاه اینترنتی دارید و پس از ثبت سفارش باید کارهای مختلفی انجام شود:

• ثبت سفارش در Database
• ارسال Email تأیید
• ارسال Notification
• تولید فاکتور
• به‌روزرسانی موجودی کالا

در یک معماری سنتی ممکن است تمام این عملیات در یک سرویس بزرگ انجام شوند. اما در معماری FaaS می‌توان بخشی از این وظایف را به Functionهای مستقل تبدیل کرد و هر Function را در زمان مورد نیاز اجرا کرد.

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

مدل FaaS معمولاً بر پایه یک الگوی Event-Driven کار می‌کند. یک Event باعث اجرای Function می‌شود، Function عملیات موردنظر را انجام می‌دهد و پس از پایان اجرا، منابع آن می‌توانند آزاد شوند.

یک جریان ساده را می‌توان این‌گونه تصور کرد:

1. یک Event یا HTTP Request ایجاد می‌شود.
2. FaaS Platform Function مربوطه را پیدا می‌کند.
3. در صورت نیاز، Runtime مناسب را ایجاد یا فعال می‌کند.
4. کد Function اجرا می‌شود.
5. نتیجه به درخواست‌کننده یا سیستم Event ارسال می‌شود.
6. پس از پایان کار، محیط اجرا می‌تواند متوقف یا برای Requestهای بعدی نگهداری شود.

این مدل باعث می‌شود ظرفیت زیرساخت بتواند بر اساس میزان واقعی درخواست‌ها تغییر کند.

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

FaaS و Serverless مترادف کامل یکدیگر نیستند.

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

بنابراین هر FaaS معمولاً در دسته Serverless قرار می‌گیرد، اما هر Serverless Application الزاماً یک FaaS Application نیست.

اجزای اصلی یک معماری FaaS

اگرچه معماری محصولات مختلف متفاوت است، معمولاً چند جزء اصلی در یک سیستم FaaS وجود دارد.

1. Function

Function همان واحد اصلی اجرای کد است. معمولاً یک Function باید یک مسئولیت مشخص داشته باشد و تا حد امکان مستقل طراحی شود.

2. Trigger

Trigger مشخص می‌کند Function چه زمانی اجرا شود. Trigger می‌تواند یک HTTP Request، پیام Queue، تغییر فایل، Event مربوط به Database یا یک Schedule باشد.

3. Runtime

Runtime محیطی است که کد Function در آن اجرا می‌شود. بسته به Platform ممکن است Runtimeهای مختلفی مانند Node.js، Python، Java، Go یا .NET در دسترس باشند.

4. Event Source

Event Source سیستمی است که Event را تولید می‌کند؛ برای مثال یک Message Queue، Object Storage، Database یا API Gateway.

5. API Gateway

در سناریوهای HTTP، API Gateway می‌تواند ورودی درخواست‌ها را مدیریت و آن‌ها را به Function مناسب هدایت کند. همچنین می‌تواند مسئولیت‌هایی مانند Routing، Authentication، Rate Limiting و Logging را بر عهده بگیرد.

6. Monitoring و Observability

در معماری‌های FaaS نیز Monitoring، Logging و Tracing اهمیت زیادی دارند. کوتاه بودن عمر Executionها باعث می‌شود مشاهده‌پذیری سیستم بدون طراحی مناسب دشوار شود.

یک مثال ساده از FaaS

فرض کنید یک API برای دریافت تصویر دارید و می‌خواهید پس از Upload، تصویر به صورت خودکار Resize شود.

در یک معماری FaaS می‌توان چنین جریان کاری داشت:

1. کاربر تصویر را در Object Storage آپلود می‌کند.
2. Storage یک Event تولید می‌کند.
3. Event باعث اجرای Function مربوط به Image Processing می‌شود.
4. Function تصویر را دریافت و Resize می‌کند.
5. نسخه پردازش‌شده در Storage ذخیره می‌شود.

در این سناریو لازم نیست یک Server دائماً منتظر Upload تصویر باشد. Function تنها زمانی اجرا می‌شود که Event مربوط به Upload اتفاق افتاده باشد.

مزایای Function as a Service

کاهش درگیری با مدیریت زیرساخت

در FaaS بسیاری از عملیات زیرساختی مانند Provisioning منابع، مدیریت Runtime و Scaling توسط Platform انجام می‌شود. این موضوع می‌تواند زمان تیم توسعه را برای تمرکز روی Application آزاد کند.

مقیاس‌پذیری خودکار

یکی از مهم‌ترین مزایای FaaS، امکان افزایش و کاهش ظرفیت اجرای Function بر اساس حجم درخواست‌هاست. این ویژگی به‌خصوص برای Workloadهایی که Traffic متغیری دارند جذاب است.

پرداخت بر اساس مصرف

در برخی مدل‌های FaaS هزینه بر اساس تعداد Invocation، زمان Execution و منابع مصرف‌شده محاسبه می‌شود. بنابراین در Workloadهای متناوب ممکن است نسبت به اجرای دائمی یک سرویس، مدل اقتصادی‌تری باشد.

مناسب برای Event-Driven Architecture

FaaS برای معماری‌هایی که تعداد زیادی Event در آن‌ها وجود دارد بسیار مناسب است. Queueها، Storageها، سیستم‌های Notification و سرویس‌های مختلف می‌توانند Trigger اجرای Function باشند.

Deployment مستقل

Functionهای کوچک را می‌توان مستقل از یکدیگر توسعه و Deploy کرد. این موضوع در معماری Microservices و سیستم‌های Event-Driven می‌تواند مزیت قابل توجهی باشد.

معایب و چالش‌های FaaS

FaaS با وجود مزایای زیاد، برای تمام Applicationها انتخاب مناسبی نیست.

Cold Start

یکی از شناخته‌شده‌ترین چالش‌های FaaS، Cold Start است. اگر Function برای مدتی اجرا نشده باشد، Platform ممکن است نیاز داشته باشد یک Execution Environment جدید ایجاد و Runtime را آماده کند. این فرآیند می‌تواند Latency اولیه را افزایش دهد.

محدودیت زمان اجرا

بسیاری از FaaS Platformها برای مدت زمان Execution، Memory، حجم Request و سایر منابع محدودیت‌هایی دارند. بنابراین Workloadهای طولانی یا پردازش‌های سنگین همیشه گزینه مناسبی برای FaaS نیستند.

پیچیدگی Distributed System

وقتی Application به تعداد زیادی Function تقسیم می‌شود، ارتباط بین اجزا، مدیریت خطا، Retry، Idempotency، Distributed Tracing و Debugging اهمیت بیشتری پیدا می‌کند.

Vendor Lock-in

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

مشکلات Observability

در یک سیستم سنتی ممکن است یک سرویس دائماً در حال اجرا باشد، اما در FaaS Executionها کوتاه‌مدت و پراکنده هستند. بنابراین جمع‌آوری و ارتباط Logs، Metrics و Traces اهمیت بیشتری پیدا می‌کند.

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

FaaS یا Container؟

FaaS و Container رقیب مستقیم یکدیگر نیستند. Container یک روش بسته‌بندی و اجرای Application است، در حالی که FaaS یک مدل ارائه و اجرای Function است.

در Container شما کنترل بیشتری روی محیط اجرا، Runtime، Network و منابع دارید. در FaaS بخش زیادی از این مسئولیت‌ها به Platform منتقل می‌شود.

اگر Application شما یک API دائمی، سرویس پردازش سنگین یا Workload با Runtime سفارشی است، Container می‌تواند گزینه مناسب‌تری باشد. اما اگر با Functionهای کوچک و Eventهای متناوب سروکار دارید، FaaS می‌تواند انتخاب بسیار خوبی باشد.

FaaS یا Kubernetes؟

مقایسه مستقیم FaaS و Kubernetes نیز چندان دقیق نیست. Kubernetes یک Container Orchestration Platform است و کنترل بسیار بیشتری روی Infrastructure و Workload در اختیار تیم قرار می‌دهد.

در مقابل، FaaS معمولاً سطح Abstraction بالاتری ارائه می‌کند و هدف آن کاهش مسئولیت‌های عملیاتی است.

محبوب‌ترین پلتفرم‌های FaaS

امروزه FaaS هم در سرویس‌های Cloud عمومی و هم در راهکارهای Open Source و Self-Hosted قابل پیاده‌سازی است.

AWS Lambda

AWS Lambda یکی از شناخته‌شده‌ترین سرویس‌های FaaS است و با سایر سرویس‌های AWS مانند S3، API Gateway، EventBridge و بسیاری از سرویس‌های دیگر Integration عمیقی دارد.

Azure Functions

Azure Functions راهکار FaaS مایکروسافت است و برای سازمان‌هایی که اکوسیستم Azure و Microsoft را استفاده می‌کنند گزینه مهمی محسوب می‌شود.

Google Cloud Functions

Google Cloud Functions نیز امکان اجرای Functionهای Event-Driven را در زیرساخت Google Cloud فراهم می‌کند.

OpenFaaS

OpenFaaS یک راهکار Open Source برای اجرای Functionها و Microservices است که می‌تواند روی Containerها و زیرساخت‌هایی مانند Kubernetes اجرا شود.

Knative

Knative مجموعه‌ای از اجزای Open Source برای اجرای Workloadهای Serverless روی Kubernetes است و امکاناتی مانند Serving و Eventing را فراهم می‌کند.

در محیط‌هایی که کنترل زیرساخت، استقلال از Provider و امکان Self-Hosting اهمیت دارد، راهکارهایی مانند Knative و OpenFaaS می‌توانند ارزش بیشتری داشته باشند.

FaaS روی Kubernetes چگونه پیاده‌سازی می‌شود؟

یکی از جذاب‌ترین سناریوها برای سازمان‌هایی که Kubernetes را در اختیار دارند، اجرای قابلیت‌های Serverless روی Cluster داخلی است.

در این مدل، Kubernetes وظیفه Orchestration را بر عهده دارد و لایه‌ای مانند Knative می‌تواند قابلیت‌های Serverless را به آن اضافه کند.

در نتیجه می‌توان Application را به Functionها یا Serviceهای کوچک تقسیم کرد و از قابلیت‌هایی مانند:

• Auto Scaling
• Event-Driven Execution
• Revision Management
• Traffic Routing
• Container-based Deployment

استفاده کرد.

این مدل به‌خصوص برای سازمان‌هایی که نمی‌خواهند تمام Workload خود را به یک Cloud Provider وابسته کنند، می‌تواند جذاب باشد.

چه زمانی FaaS انتخاب مناسبی است؟

FaaS معمولاً در سناریوهای زیر عملکرد خوبی دارد:

• پردازش Eventها
• APIهای سبک و Stateless
• پردازش فایل و تصویر
• پردازش پیام‌های Queue
• Automation و Jobهای کوتاه
• Backend برای برخی Applicationهای Serverless
• پردازش داده‌های ورودی به صورت Event-Driven
• Scheduled Jobs
• Notification و Integration بین سرویس‌ها

چه زمانی FaaS انتخاب خوبی نیست؟

در مقابل، برخی Workloadها ممکن است با FaaS سازگاری کمتری داشته باشند.

• پردازش‌های بسیار طولانی
• Workloadهای دائماً در حال اجرا
• پردازش‌های بسیار سنگین CPU یا GPU
• Applicationهایی که نیازمند کنترل کامل سیستم‌عامل هستند
• Workloadهایی با Network Configuration پیچیده
• سیستم‌هایی که به Storage محلی دائمی وابسته‌اند
• Applicationهایی که به Low Latency کاملاً پایدار نیاز دارند و Cold Start برای آن‌ها قابل قبول نیست

Best Practices در معماری FaaS

Functionها را کوچک اما بیش از حد ریز نکنید

هدف از FaaS تقسیم منطقی Application است، نه اینکه هر چند خط کد را به یک Function مستقل تبدیل کنیم. تعداد بیش از حد Functionها می‌تواند Complexity سیستم را افزایش دهد.

Functionها را Stateless طراحی کنید

تا حد امکان State را خارج از Function نگهداری کنید؛ برای مثال در Database، Cache، Object Storage یا Message Broker. این کار Scaling و مدیریت Executionها را ساده‌تر می‌کند.

Idempotency را جدی بگیرید

در سیستم‌های Event-Driven ممکن است یک Event بیش از یک بار پردازش شود. بنابراین Functionها باید تا حد امکان Idempotent طراحی شوند تا اجرای مجدد باعث ایجاد داده یا عملیات تکراری ناخواسته نشود.

Timeout و Retry را به‌درستی تنظیم کنید

Retry بدون طراحی مناسب می‌تواند یک خطای کوچک را به یک زنجیره از درخواست‌های تکراری تبدیل کند. برای هر Function باید Timeout، Retry و Dead Letter Queue با توجه به ماهیت Workload طراحی شوند.

Observability را از ابتدا طراحی کنید

برای محیط‌های FaaS بهتر است Logging، Metrics و Distributed Tracing از ابتدای طراحی در نظر گرفته شوند. ابزارهایی مانند Prometheus، Grafana، Loki و OpenTelemetry می‌توانند در معماری‌های Self-Hosted نقش مهمی داشته باشند.

برای آشنایی بیشتر با این موضوع می‌توانید راهنمای OpenTelemetry و مقاله مانیتورینگ Log با Loki و Grafana را مطالعه کنید.

امنیت را به Function محدود نکنید

امنیت FaaS فقط به کد Function محدود نمی‌شود. IAM، Secret Management، Network Policy، API Gateway، Dependencyهای نرم‌افزاری، Logging و کنترل دسترسی به Event Sourceها همگی باید در Security Architecture دیده شوند.

در محیط‌های سازمانی، FaaS باید بخشی از یک رویکرد جامع امنیت و Hardening زیرساخت باشد.

FaaS و Microservices

FaaS می‌تواند برای پیاده‌سازی بخشی از معماری Microservices استفاده شود، اما این دو مفهوم یکسان نیستند.

Microservice معمولاً یک سرویس مستقل با Lifecycle و Interface مشخص است. یک Function می‌تواند بسیار کوچک‌تر باشد و عمر اجرای کوتاه‌تری داشته باشد.

در برخی معماری‌ها می‌توان ترکیبی از هر دو مدل داشت؛ برای مثال Core Serviceها به صورت Containerized Microservice اجرا شوند و عملیات Event-Driven یا Jobهای خاص با FaaS انجام شوند.

FaaS و DevOps

استفاده از FaaS باعث حذف DevOps نمی‌شود؛ بلکه ماهیت برخی مسئولیت‌های DevOps را تغییر می‌دهد.

حتی در Serverless Architecture همچنان باید موارد زیر مدیریت شوند:

• Source Control
• CI/CD
• Infrastructure as Code
• Secret Management
• Monitoring
• Logging
• Security
• Cost Management
• Testing
• Disaster Recovery

به همین دلیل، FaaS را نباید راهکاری برای حذف نیاز به خدمات دواپس یا خدمات devops دانست. اتفاقاً در محیط‌های Enterprise، طراحی درست Pipeline، Observability، Security و Governance اهمیت بیشتری پیدا می‌کند.

چک‌لیست پیاده‌سازی FaaS

قبل از پیاده‌سازی FaaS بهتر است این موارد بررسی شوند:

• آیا Workload واقعاً Event-Driven است؟
• آیا Functionها Stateless هستند؟
• آیا Cold Start قابل قبول است؟
• حداکثر زمان اجرای Function چقدر است؟
• Function به چه منابعی مانند Database، Queue یا Storage نیاز دارد؟
• Retry و Failure Handling چگونه انجام می‌شود؟
• آیا Dead Letter Queue لازم است؟
• Logging و Tracing چگونه پیاده‌سازی می‌شوند؟
• Secretها چگونه مدیریت می‌شوند؟
• مدل هزینه در Peak و Average Traffic چگونه خواهد بود؟
• میزان وابستگی به Provider چقدر است؟
• در صورت از کار افتادن Platform، Business Continuity چگونه حفظ می‌شود؟

آیا FaaS برای سازمان‌های Enterprise مناسب است؟

پاسخ کوتاه این است: بله، اما نه برای همه Workloadها و نه لزوماً به شکل یکپارچه.

در یک سازمان بزرگ ممکن است بخشی از سیستم‌ها روی Kubernetes، بخشی روی Virtual Machine و بخشی روی FaaS اجرا شوند. انتخاب Architecture باید بر اساس نوع Workload، SLA، امنیت، Latency، هزینه، قابلیت نگهداری و الزامات کسب‌وکار انجام شود.

در سازمان‌هایی که نیاز به کنترل بیشتر روی Infrastructure دارند، پیاده‌سازی Serverless داخلی روی Kubernetes با ابزارهایی مانند Knative می‌تواند گزینه‌ای بین Cloud FaaS و زیرساخت سنتی باشد.

FaaS چه تفاوتی با Serverless Database و BaaS دارد؟

در اکوسیستم Serverless، FaaS تنها یکی از اجزاست. سرویس‌های Backend آماده، Databaseهای Serverless و Object Storage می‌توانند در کنار Functionها قرار بگیرند.

به عنوان نمونه، یک معماری Serverless می‌تواند شامل API Gateway، Function، Database، Object Storage و Message Queue باشد که هر کدام مسئولیت مشخصی دارند.

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

سؤالات متداول درباره FaaS

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

خیر. FaaS یکی از مهم‌ترین مدل‌های Serverless است، اما Serverless مفهوم گسترده‌تری دارد و سرویس‌هایی مانند BaaS و Serverless Database را نیز شامل می‌شود.

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

خیر. Serverها همچنان وجود دارند، اما مدیریت مستقیم آن‌ها از دید توسعه‌دهنده تا حد زیادی توسط Platform انجام می‌شود.

آیا FaaS برای Microservices مناسب است؟

بله، در برخی سناریوها. FaaS می‌تواند برای سرویس‌های کوچک و Event-Driven مناسب باشد، اما همه Microserviceها الزاماً باید به Function تبدیل شوند.

مهم‌ترین مشکل FaaS چیست؟

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

آیا می‌توان FaaS را روی Kubernetes اجرا کرد؟

بله. ابزارهایی مانند Knative و OpenFaaS امکان اجرای Workloadهای Function-based روی Kubernetes را فراهم می‌کنند.

آیا FaaS جایگزین Kubernetes است؟

خیر. این دو در دو سطح متفاوت قرار دارند. Kubernetes کنترل و انعطاف بیشتری روی Container و Infrastructure فراهم می‌کند، در حالی که FaaS سطح Abstraction بالاتری ارائه می‌دهد.

آیا FaaS برای API مناسب است؟

برای APIهای Stateless و سبک می‌تواند گزینه بسیار خوبی باشد، اما برای APIهای دائمی، پیچیده یا بسیار حساس به Latency باید شرایط Workload دقیقاً بررسی شود.

آیا FaaS باعث حذف DevOps می‌شود؟

خیر. CI/CD، امنیت، Monitoring، Logging، مدیریت Secret، هزینه و Reliability همچنان باید مدیریت شوند. FaaS بیشتر مسئولیت مدیریت مستقیم Server را کاهش می‌دهد.

جمع‌بندی

Function as a Service یا FaaS یکی از مهم‌ترین مدل‌های اجرای Application در دنیای Serverless است که امکان اجرای Functionهای مستقل را بر اساس Event یا Request فراهم می‌کند.

مزیت اصلی FaaS، کاهش درگیری تیم با مدیریت مستقیم زیرساخت، امکان Scaling خودکار و مناسب بودن برای Workloadهای Event-Driven است. در مقابل، Cold Start، محدودیت Execution، Vendor Lock-in و پیچیدگی Observability از چالش‌های مهم آن هستند.

بنابراین انتخاب FaaS نباید صرفاً به دلیل مدرن بودن آن انجام شود. Architecture مناسب باید بر اساس ماهیت Workload، SLA، هزینه، امنیت، Performance و میزان کنترل موردنیاز روی Infrastructure انتخاب شود.

اگر قصد دارید یک معماری Serverless، Containerized یا Event-Driven برای سازمان خود طراحی و پیاده‌سازی کنید، راهکارهای سازمانی آلتیمیت کلاد می‌توانند از مرحله Architecture و انتخاب Technology تا پیاده‌سازی، Automation، Monitoring و مدیریت زیرساخت در کنار تیم شما باشند.