توابع سرورلس، به‌زودی در ایران‌کلاد

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

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

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

جدول زیر کاربردهای رایج سرورلس را با سرویسی که همین حالا در ایران‌کلاد فعال است کنار هم گذاشته است:

توابع لبهٔ ایران‌کلاد برای دامنه‌هایی است که از طریق پروکسی لبهٔ ما سرویس می‌گیرند. برای هر رکورد می‌توانید قانون تعریف کنید: درخواست‌های یک مسیر را با کد ۳۰۱ یا ۳۰۲ به آدرس دیگری بفرستید، مسیر را پیش از رسیدن به سرور بازنویسی کنید یا یک هدر به پاسخ اضافه کنید. این قانون‌ها روی لبه اجرا می‌شوند و سرور شما اصلاً درگیر نمی‌شود.

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

برای بیشتر تیم‌ها ساده‌ترین جایگزین سرورلس یک سرور ابری کوچک است که چند سرویس سبک را هم‌زمان اجرا می‌کند. هر وب‌هوک یا API را یک برنامهٔ کوچک بنویسید، با systemd یا pm2 روشن نگه دارید و با یک reverse proxy مثل Nginx و گواهی SSL روی دامنهٔ خودتان منتشر کنید.

قیمت‌های زیر لحظه‌ای و ساعتی‌اند. برخلاف سرورلس، هزینه به تعداد درخواست بستگی ندارد و تا وقتی سرور وجود دارد ثابت است؛ معادل ماهانه بر پایهٔ ۷۳۰ ساعت حساب شده است. هر سرور ۵۰ گیگابایت ترافیک ماهانه دارد.

اگر چند API کوچک دارید، همه را روی یک سرور و پشت یک reverse proxy قرار دهید و هر کدام را با یک زیردامنه یا مسیر جدا منتشر کنید. با Docker هر سرویس در محیط خودش اجرا می‌شود و وابستگی‌هایشان با هم تداخل پیدا نمی‌کند؛ راهنمای نصب Docker این مرحله را توضیح می‌دهد.

بخش بزرگی از کاربرد سرورلس، کارهای پس‌زمینه است: ارسال ایمیل بعد از ثبت‌نام، ساخت تصویر کوچک بعد از بارگذاری عکس یا به‌روزرسانی گزارش بعد از هر خرید. همین الگو را می‌توانید با صف پیام پیاده کنید: برنامهٔ اصلی رویداد را در صف می‌گذارد و فوراً به کاربر پاسخ می‌دهد، و worker جداگانه آن را برمی‌دارد و پردازش می‌کند.

مزیت این روش این است که اگر worker موقتاً از کار بیفتد یا بار ناگهان زیاد شود، پیام‌ها در صف می‌مانند و از دست نمی‌روند. برای پردازش سریع‌تر هم کافی است تعداد worker‌ها را زیاد کنید. صف پیام مدیریت‌شده ایران‌کلاد RabbitMQ و NATS را با پرداخت ساعتی ارائه می‌دهد.

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

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

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

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

پاسخ به الگوی بار شما بستگی دارد. این مقایسهٔ کلی کمک می‌کند تصمیم بگیرید:

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

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