Serverless چیست؟ محاسبات سرورلس، توضیح ساده
Serverless روشی برای اجرای کد است که در آن هیچ سروری را خودتان راه نمی‌اندازید یا مدیریت نمی‌کنید. کدتان را به یک ارائه‌دهنده‌ی ابری می‌دهید و فقط وقتی چیزی آن را فعال کند اجرا می‌شود، مثلاً یک درخواست وب، یک فایل آپلودشده یا اطلاع پرداخت، و بعد متوقف می‌شود. معمولاً برای مدت زمانی که کد واقعاً اجرا می‌شود پول می‌دهید، نه برای ماشینی که بیکار نشسته.
چرا serverless وقتی با هوش مصنوعی می‌سازید مهم است
وقتی با هوش مصنوعی اپلیکیشن می‌سازید و به گزینه‌های میزبانی یا کد نگاه می‌کنید، به «توابع serverless»، «توابع edge» یا «توابع ابری» برمی‌خورید. بسیاری از پلتفرم‌های میزبانی این را ارائه می‌دهند و بعضی ابزارهای ساخت، بک‌اند را به همین شکل مستقر می‌کنند. درک این مدل به سه سؤال عملی کمک می‌کند:
- هزینه. آیا اپلیکیشن شما وقتی کسی استفاده نمی‌کند هم پول می‌گیرد؟
- سرعت. چرا اولین درخواست بعد از یک دورهٔ آرام کندتر است؟
- محدودیت‌ها. چرا یک کار طولانی، مثل ساختن یک گزارش بزرگ یا پردازش یک ویدیو، تایم‌اوت شد؟
همچنین کمک می‌کند بدانید serverless چه نیست: نبودن بک‌اند نیست. هنوز کد سمت سرور دارید؛ فقط کس دیگری ماشین‌ها را اجرا می‌کند. برای مبانی، سرور چیست را ببینید.
یک تشبیه روزمره
یک سرور سنتی مثل داشتن ماشین است. همیشه آماده است و بلافاصله کار می‌کند، ولی هزینه‌اش را می‌دهید، از بیمه و پارکینگ و نگهداری، چه رانندگی کنید چه نکنید.
Serverless مثل گرفتن تاکسی است. فقط برای سفرهایی که می‌کنید پول می‌دهید، و اگر صد نفر همزمان سوار شوند، صد تاکسی می‌آید. ولی ممکن است کمی منتظر ماشین بمانید (یک cold start)، هر سفر طول حداکثری دارد، و راننده شما را از سفر قبلی به یاد ندارد (توابع stateless هستند).
توابع serverless چطور کار می‌کنند
در رایج‌ترین شکلش، که functions as a service نام دارد:
- تابع می‌نویسید. یک قطعه‌ی کوچک کد که یک نوع رویداد را مدیریت می‌کند، مثل «یک POST به
/api/bookingsرا پردازش کن». - مستقرش می‌کنید. ارائه‌دهنده آن را ذخیره می‌کند و به یک trigger وصل می‌کند: یک URL، یک زمان‌بندی، یک فایل جدید در storage، یا یک پیام در صف.
- رویدادی می‌رسد. ارائه‌دهنده یک نسخه از تابع شما را راه می‌اندازد (یا یک نسخه‌ی گرم را دوباره استفاده می‌کند)، اجرایش می‌کند و نتیجه را برمی‌گرداند.
- خودش مقیاس می‌گیرد. اگر هزار درخواست همزمان برسد، ارائه‌دهنده نسخه‌های زیادی را موازی اجرا می‌کند، تا حد محدودیت‌های حساب شما.
- بیکار می‌شود. وقتی ترافیک قطع شود، نسخه‌ها خاموش می‌شوند. وقتی چیزی اجرا نمی‌شود، برای محاسبه هیچ پولی نمی‌دهید.
یک تابع serverless کوچک در JavaScript ممکن است این شکلی باشد:
export default async function handler(request) {
const { name } = await request.json();
return Response.json({ message: `Hello, ${name}` });
}
کدی برای راه‌اندازی سرور، باز کردن پورت یا نگه داشتن یک فرایند در حال اجرا وجود ندارد. پلتفرم همه‌ی این‌ها را انجام می‌دهد.
«Serverless» به‌صورت آزادتر برای سرویس‌های مدیریت‌شدهٔ دیگری هم به کار می‌رود که خودکار مقیاس می‌گیرند و بر اساس مصرف صورتحساب می‌دهند؛ برای نمونه، پایگاه‌های داده‌ی serverless که وقتی بیکارند متوقف می‌شوند.
توضیح اصطلاحات کلیدی
| اصطلاح | معنی |
|---|---|
| Function (FaaS) | قطعه‌ی کوچک کدی که ارائه‌دهنده وقتی لازم باشد اجرا می‌کند. |
| Trigger / رویداد | چیزی که تابع را راه می‌اندازد: یک درخواست HTTP، آپلود فایل، تایمر، پیام صف. |
| Cold start | تأخیر وقتی یک نسخه‌ی تازه از تابع باید قبل از پاسخ به درخواست راه بیفتد. |
| Warm | نسخه‌ای که از قبل در حال اجراست و می‌تواند فوراً پاسخ دهد. |
| Stateless | تابع بین اجراها حافظه نگه نمی‌دارد. هر چیزی که باید بماند در پایگاه داده یا storage می‌رود. |
| Timeout | حداکثر زمانی که یک اجرا مجاز است. مثلاً حداکثر AWS Lambda برای ۱۵ دقیقه است؛ بسیاری از پلتفرم‌ها پیش‌فرض‌هایی خیلی کمتر دارند. |
| Edge function | تابعی که در مکان‌های زیادی نزدیک کاربران اجرا می‌شود، اغلب با محدودیت‌های سخت‌تر. |
| Scale to zero | وقتی ترافیکی نیست، هیچ‌چیز را اجرا نمی‌کند و برای محاسبه هیچ پولی نمی‌دهد. |
یک مثال کامل: یک سایت رزرو کوچک
سایت رزرو یک استودیوی یوگا هر یکشنبه غروب، وقتی برنامه‌ی جدید منتشر می‌شود، یک سیل بازدید دارد و بقیه‌ی هفته بسیار کم.
- روی یک سرور همیشه‌روشن، استودیو برای یک ماشین ۲۴ ساعته پول می‌دهد، اندازه‌اش برای اوج یکشنبه غروب انتخاب شده، و بقیه‌ی وقت بیشترش بیکار است.
- با توابع serverless،
GET /api/classesوPOST /api/bookingsتوابع هستند. هجوم یکشنبه به‌طور خودکار نسخه‌های زیادی راه می‌اندازد؛ صبح یک سه‌شنبه‌ی آرام، تقریباً هیچ‌چیز اجرا نمی‌شود و صورتحساب نزدیک صفر است.
مصالحه‌ها هم دیده می‌شوند. اولین نفری که صبح سه‌شنبه سایت را باز کند ممکن است کمی بیشتر منتظر cold start بماند. پایگاه داده باید اتصال‌های کوتاه‌عمر زیادی از نسخه‌های زیاد تابع را تحمل کند، که ممکن است به یک connection pooler نیاز داشته باشد. و اگر استودیو بعداً بخواهد یک کار «ساخت PDF حضور سالانه‌ی همه» داشته باشد، ممکن است از محدودیت زمان تابع بگذرد و باید جای دیگری اجرا شود.
کجا serverless مناسب است و کجا نه
| مناسب | کمتر مناسب |
|---|---|
| ترافیک کم، پرش‌دار یا غیرقابل‌پیش‌بینی | ترافیک سنگین و ثابت، که در آن سرور همیشه‌روشن می‌تواند ارزان‌تر باشد |
| کارهای کوتاه درخواست/پاسخ: APIها، هندلرهای فرم، webhookها | کارهای طولانی: پردازش ویدیوی بزرگ، واردکردن داده‌ی حجیم |
| تیم‌های کوچک که نمی‌خواهند سرور مدیریت کنند | اپلیکیشن‌هایی که اتصال زنده را باز نگه می‌دارند (بعضی قابلیت‌های چت یا چندنفره)، مگر اینکه پلتفرم پشتیبانی کند |
| مدیریت رویداد: «وقتی فایلی آپلود شد، یک تصویر کوچک بساز» | اپلیکیشن‌هایی که به حافظه‌ی زیاد بین درخواست‌ها نیاز دارند |
برداشت‌های غلط رایج
- «Serverless یعنی بک‌اند نداریم.» یعنی سرور برای مدیریت نداریم. هنوز باید کد بک‌اند بنویسید و امنیتش را تأمین کنید.
- «Serverless همیشه ارزان‌تر است.» در حجم کم ارزان است، ولی قیمت به‌ازای هر درخواست در حجم زیاد و ثابت می‌تواند جمع شود.
- «Serverless بی‌نهایت مقیاس می‌گیرد.» پلتفرم‌ها محدودیت همزمانی دارند، و پایگاه داده‌ی شما ممکن است خیلی زودتر از توابع گلوگاه شود.
- «فایل‌هایی که در یک تابع ذخیره می‌شوند دفعه‌ی بعد هم هستند.» فضای ذخیره‌سازی محلی موقتی است. از پایگاه داده یا storage استفاده کنید.
- «Scale-to-zero همان serverless است.» مرتبط‌اند ولی یکی نیستند. بعضی پلتفرم‌ها اپلیکیشن را مثل یک سرور معمولی اجرا می‌کنند که وقتی بیکار است می‌خوابد و با درخواست بعدی بیدار می‌شود؛ صرفه‌جویی و تأخیر اولین درخواست مشابه است، ولی بدون محدودیت زمانی هر درخواست به سبک توابع.
از ابزار ساخت اپلیکیشنتان چه بپرسید
- «این بک‌اند به‌صورت توابع serverless اجرا می‌شود یا به‌صورت سرور همیشه‌روشن یا خوابیده؟ این برای هزینه یعنی چه؟»
- «آیا احتمال دارد برخی کارها بیشتر از محدودیت زمانی پلتفرم طول بکشند؟ اگر بله، باید چطور مدیریتشان کنیم؟»
- «هر چیزی که باید بماند را در پایگاه داده یا فایل storage ذخیره کن، نه در حافظه یا فایل‌های محلی.»
- «اگر چند نسخه همزمان اجرا شوند، اتصال‌های پایگاه داده چطور باید مدیریت شوند؟»
- «تأخیر اولین درخواست بعد از بیکاری اپلیکیشن چقدر است؟»
Mythex چطور اپلیکیشن‌ها را میزبانی می‌کند
Mythex میزبانی خود را به‌عنوان توابع serverless توصیف نمی‌کند. وقتی منتشر می‌کنید، اپلیکیشنتان به‌صورت یک اپلیکیشن وب یا کانتینر عادی اجرا می‌شود که Mythex برایتان مدیریت می‌کند؛ چیزی برای راه‌اندازی وجود ندارد. این روش scale-to-zero است: اپلیکیشن‌های منتشرشده و پایگاه داده‌شان وقتی بیکارند می‌خوابند و با بازدید بعدی بیدار می‌شوند؛ اپلیکیشن خوابیده برای محاسبه هیچ پولی نمی‌دهد، و ماشین‌های اضافی فقط وقتی ترافیک زیاد است راه می‌افتند (در پلن Pro تا ۳ ماشین برای هر سرویس). پایگاه داده‌ی Postgres متصل هم بعد از ۵ دقیقه بیکاری می‌خوابد و برای زمانی که بیدار بوده صورتحساب می‌شود. پس بخشی از مزیت «پول بدهید برای آنچه استفاده می‌کنید» را دارید، با همان نوع تأخیر اولین درخواست بعد از یک دورهٔ آرام. برای جزئیات، محدودیت‌های میزبانی را در مستندات ببینید، و راهنماهای ما دربارهٔ میزبانی وب و کاهش هزینه‌ی میزبانی.
پرسش‌ها
Serverless به زبان ساده یعنی چه؟
Serverless یعنی کدتان را به یک ارائه‌دهنده‌ی ابری می‌دهید و فقط وقتی لازم باشد اجرا می‌شود، مثلاً وقتی درخواستی می‌رسد، بدون اینکه شما سروری راه بیندازید یا نگهداری کنید. معمولاً برای مدت زمانی که کد واقعاً اجرا می‌شود پول می‌دهید، نه برای دستگاهی که همیشه روشن است.
آیا در serverless واقعاً سروری وجود ندارد؟
سرور وجود دارد؛ فقط شما آن را مدیریت نمی‌کنید. ارائه‌دهنده کدتان را روی ماشین‌های خودش اجرا می‌کند، وقتی درخواست برسد آن را راه می‌اندازد، تحت بار بیشتر مقیاس می‌دهد و وقتی بیکار است خاموشش می‌کند.
cold start چیست؟
cold start تأخیر اضافه‌ای است که وقتی یک تابع serverless بعد از بیکاری اجرا می‌شود رخ می‌دهد، چون ارائه‌دهنده ابتدا باید یک نسخه‌ی تازه از آن را راه بیندازد. بسته به پلتفرم، زبان و حجم کد، از تقریباً نامحسوس تا یک ثانیه یا بیشتر می‌تواند باشد.
آیا serverless از یک سرور معمولی ارزان‌تر است؟
برای اپلیکیشن‌هایی با ترافیک کم یا نامنظم، اغلب بله، چون وقتی بیکار است تقریباً هیچ پول نمی‌دهید. برای اپلیکیشن‌هایی با ترافیک سنگین و دائمی، یک سرور همیشه‌روشن می‌تواند ارزان‌تر دربیاید. به الگوی مصرف و قیمت ارائه‌دهنده بستگی دارد.
نمونه‌های پلتفرم serverless چیست؟
نمونه‌های شناخته‌شده شامل AWS Lambda، Google Cloud Run functions، Azure Functions، Cloudflare Workers، و قابلیت‌های تابعی پلتفرم‌های میزبانی مثل Vercel و Netlify هستند.