زمان مطالعه: ۷ دقیقه
مخاطب: توسعه‌دهندگان، DevOpsها، مدیران فنی، تیم‌های استارتاپی
مقدمه: وقتی همه دنبال بی‌سرور شدن هستن، ولی کسی درست نمی‌دونه یعنی چی!
چند ساله واژه‌ی "Serverless" توی وبلاگ‌ها، کنفرانس‌ها و توی معرفی سرویس‌های ابری پر شده. همه ازش حرف می‌زنن، ولی وقتی میری سراغ اجرا، نتیجه معمولاً چیزی نیست که انتظار داشتی: زمان پاسخ بالا می‌ره، دیباگ سخت می‌شه، هزینه بیشتر از حد تصوره یا اصلاً نمی‌دونی برای چی باید ازش استفاده کنی! در حالی که Serverless می‌تونه واقعا نجات‌دهنده باشه... اگه بدونی کجا باید ازش استفاده کنی.Serverless به این معنا نیست که «هیچ سروری در کار نیست». بلکه یعنی: مدیریت سرورها، زیرساخت، مقیاس‌پذیری و در دسترس بودن، از عهده‌ی شما خارج می‌شه و به عهده‌ی سرویس‌دهنده‌ست.
شما فقط کدی می‌نویسی که روی event خاصی اجرا می‌شه. بقیه‌اش رو پلتفرم انجام می‌ده: اجرای فانکشن فقط در زمان نیاز، پرداخت بر اساس زمان اجرا (نه رزرو منابع ثابت) و مقیاس‌پذیری خودکار بر اساس ترافیک.
ولی Serverless به معنی این‌ها نیست:
داشتن بک‌اند آماده یا بدون نیاز به فکر کردن به معماری
جایگزین کامل همه‌چیز (مثلاً دیتابیس یا فایل‌سیستم)
همیشه ارزون‌تر یا سریع‌تر از روش‌های سنتی
چرا خیلی‌ها Serverless رو اشتباه استفاده می‌کنن؟
۱. فکر می‌کنن برای همه‌چی مناسبه
بعضی تیم‌ها فکر می‌کنن می‌تونن کل اپ رو serverless کنن، بدون اینکه بفهمن فانکشن‌ها برای وظایف «کوتاه، مشخص، و رویدادمحور» طراحی شدن، نه پردازش‌های سنگین یا طولانی‌مدت.
۲. کد رو همون‌جوری که برای سرور نوشتن، بدون تغییر منتقل می‌کنن
Serverless ساختار متفاوتی می‌خواد. فانکشن باید سبک، سریع، stateless و مستقل باشه. اما خیلی‌ها همون کد مونولیت قبلی رو برمی‌دارن و انتظار دارن خوب کار کنه.
۳. انتظار دارن همیشه سریع‌تر باشه
هر بار که فانکشن جدیدی اجرا می‌شه، ممکنه cold start ایجاد بشه. یعنی تأخیر اولیه‌ای که باعث می‌شه کاربر حس کنه سیستم کنده.
۴. هزینه‌ها قابل پیش‌بینی نیستن
در ظاهر، Serverless ارزونه چون فقط زمان اجرا حساب می‌شه. ولی اگه فانکشن‌هات خیلی زیاد اجرا بشن یا اشتباهی loop بشن، ممکنه قبضت غیرمنتظره بشه.
Serverless واقعاً کجا خوب جواب می‌ده؟
- ارسال نوتیفیکیشن‌ها بعد از رویداد (مثلاً ثبت سفارش)
- اجرای پردازش‌های image، PDF یا ویدیو در لحظه
- ثبت لاگ، گزارش‌گیری، ارسال ایمیل بعد از رویداد
- فانکشن‌هایی مثل webhookها یا triggerهای فرم تماس
- سیستم‌هایی با ترافیک متغیر (کم + گاهی پیک بالا)
وقتی serverless درست پیاده شد...
در یکی از پروژه‌های فروش بلیت، برای تولید PDF بلیت‌ها، تیم تصمیم گرفت فانکشن serverless استفاده کنه. به‌جای اجرا روی یک سرور ثابت که گاهی می‌مرد، هر درخواست تولید بلیت یک فانکشن جدا اجرا می‌کرد. مقیاس‌پذیر شد، نیاز به queue و worker نداشت، و هزینه به‌شکل چشم‌گیری پایین اومد. در عوض، فانکشن فقط همون ۳ ثانیه اجرا می‌شد و بعد تمام.
اما کجاها نباید از Serverless استفاده کرد؟
- سیستم‌هایی با نیاز به اتصال دائم (مثل websocketها)
- پردازش‌های طولانی‌مدت (مثلاً jobهای چند دقیقه‌ای)
- اپ‌هایی که نیاز به write سنگین به دیتابیس دارن
- وقتی latency بسیار پایین و ثابت می‌خوای (مثلاً realtime games)
- جایی که هزینه پیش‌بینی‌پذیر و ثابت می‌خوای (مثلاً SaaS با بار بالا)
آیا پروژه‌ات برای Serverless مناسبه؟
- فانکشن‌ها کوتاه و مستقل هستن؟
- اجرای eventها قابل پیش‌بینی‌ه؟
- latency خیلی پایین نیاز نداری؟
- state و session وابسته به local نداری؟
- مصرف منابع متغیره یا غیر دائمیه؟
Serverless در برنت نه فقط اجرا، بلکه دیده‌شدن!
- فانکشن‌هات رو در فضای ایزوله و امن تعریف کنی
- لاگ دقیق و لحظه‌ای از اجرای هر فانکشن ببینی
- eventهای ثبت‌شده رو trace و debug کنی
- زمان اجرا، مصرف منابع و آمار دقیق ببینی
- با ابزارهای مانیتورینگ متصلش کنی (مثلاً ارتباط مستقیم با Queue یا Storage)
و مهم‌تر از همه بدون فکر کردن به daemon، queue، سرور یا process فقط اجرا کن.
Serverless ابزار قدرتمندیه، ولی جای درست داره...
مثل هر ابزار دیگه‌ای، Serverless هم اگه درست استفاده بشه فوق‌العاده‌ست، ولی اگر صرفاً چون ترنده یا به امید هزینه پایین ازش استفاده کنی، ممکنه پروژه رو پیچیده‌تر و گرون‌تر کنه.
Serverless برای بخش‌هایی از اپ عالیه، نه برای همه‌چیز باید فانکشن‌ها سبک و event-driven باشن و باید ابزار دید و کنترل داشته باشی، نه فقط اجرا... Serverless یعنی تمرکز بیشتر روی کد، و کمتر روی ماشین‌ها اما به شرطی که بدونی چطور، کِی، و کجا.
