Serverless computing روشی برای ارائه خدمات backend بر اساس استفاده است. یک ارائه‌دهنده بدون سرور به کاربران اجازه می‌دهد بدون نگرانی درباره زیرساخت‌های زیربنایی، کد بنویسند و مستقر کنند. شرکتی که خدمات پشتیبان را از یک فروشنده بدون سرور دریافت می کند، بر اساس محاسبات آنها هزینه دریافت می کند و مجبور نیست مقدار ثابتی از پهنای باند یا تعداد سرورها را رزرو و پرداخت کند، زیرا این سرویس به صورت خودکار مقیاس می شود. توجه داشته باشید که علی‌رغم نام serverless، سرورهای فیزیکی همچنان استفاده می شوند اما نیازی نیست توسعه دهندگان از آنها آگاه باشند.
قبل‌ها، هرکسی که می‌خواست یک برنامه وب بسازد باید سخت‌افزار فیزیکی مورد نیاز برای اجرای یک سرور را در اختیار داشته باشد، که کاری دست و پا گیر و پرهزینه است.
سپس محاسبات ابری آمد، که در آن تعداد ثابتی از سرورها یا مقادیری از فضای سرور را می‌توان از راه دور اجاره کرد. توسعه‌دهندگان و شرکت‌هایی که این واحدهای ثابت فضای سرور را اجاره می‌کنند، معمولاً بیش از حد خرید می‌کنند تا اطمینان حاصل کنند که افزایش ترافیک یا فعالیت از محدودیت‌های ماهانه آنها بیشتر نمی‌شود و برنامه‌های آنها را با مشکل مواجه نمی‌کند. این بدان معنی است که بسیاری از فضای سروری که برای آن پول پرداخت می شود، می تواند هدر رود. فروشندگان ابری مدل‌های مقیاس‌پذیری خودکار را برای رفع این مشکل معرفی کرده‌اند، اما حتی با مقیاس‌گذاری خودکار یک جهش ناخواسته در فعالیت‌ها، مانند حمله DDoS، ممکن است بسیار گران تمام شود.
Serverless computing به توسعه دهندگان این امکان را می دهد که خدمات پشتیبان را بر اساس «پرداخت به اندازه شما» منعطف خریداری کنند، به این معنی که توسعه دهندگان فقط باید برای خدماتی که استفاده می کنند هزینه بپردازند. این مانند تغییر از یک برنامه داده تلفن همراه با محدودیت ماهانه ثابت است، به طرحی که فقط برای هر بایت داده ای که واقعاً استفاده می شود، هزینه دریافت می کند.
اصطلاح "Serverless" تا حدودی گمراه کننده است، زیرا هنوز سرورهایی وجود دارند که این خدمات بک‌اند را ارائه می دهند، اما تمام نگرانی های مربوط به فضای سرور و زیرساخت توسط فروشنده انجام می شود. Serverless به این معنی است که توسعه دهندگان می توانند کار خود را بدون نگرانی در مورد سرور انجام دهند.
خدمات پشتیبانی بک‌اند چیست؟ تفاوت بین frontend و backend چیست؟
توسعه برنامه به طور کلی به دو حوزه تقسیم می شود: فرانت اند و بک‌اند. قسمت فرانت اند بخشی از برنامه است که کاربران می بینند و با آن تعامل دارند، مانند طرح بصری.
Backend بخشی است که کاربر آن را نمی بیند. این شامل سروری می‌شود که فایل‌های برنامه در آن مستقر شده‌اند و پایگاه داده‌ای که در آن داده‌های کاربر وجود دارد.
به عنوان مثال، بیایید وب سایتی را تصور کنیم که بلیط کنسرت می فروشد. هنگامی که کاربر آدرس وب سایتی را در پنجره مرورگر تایپ می کند، مرورگر درخواستی را به سرور پشتیبان ارسال می کند که با داده های وب سایت پاسخ می دهد. سپس کاربر قسمت Front-End سایت را می بیند که می تواند شامل محتوایی مانند متن، تصاویر و فیلدهای فرم باشد تا کاربر آن را پر کند. سپس کاربر می تواند با یکی از فیلدهای فرم در قسمت جلو ارتباط برقرار کند تا آهنگ مورد علاقه خود را جستجو کند. هنگامی که کاربر روی "ارسال" کلیک می کند، این درخواست دیگری را به Back-End آغاز می کند. کد Back-End پایگاه داده خود را بررسی می کند تا ببیند آیا خواننده‌ای با این نام وجود دارد که کنسرت داشته باشد یا خیر، و اگر وجود دارد، چه زمانی کنسرت خود را اجرا می‌کند و چند بلیط در دسترس است. سپس backend داده‌ها را به frontend برمی‌گرداند، و frontend نتایج را به گونه‌ای نمایش می‌دهد که برای کاربر منطقی باشد. به همین ترتیب، هنگامی که کاربر یک حساب کاربری ایجاد می کند و اطلاعات مالی را برای خرید بلیط وارد می کند، ارتباط رفت و برگشت دیگری بین فرانت‌اند و بک‌اند انجام می شود.
Serverless computing چه نوع خدمات بک‌اندی را می توانند ارائه دهند؟
اکثر ارائه دهندگان Serverless خدمات پایگاه داده و ذخیره سازی را به مشتریان خود ارائه می دهند و بسیاری نیز دارای پلتفرم های Function-as-a-Service (FaaS) مانند Cloudflare Workers هستند. FaaS به توسعه دهندگان اجازه می دهد تا قطعات کوچکی از کد را در لبه شبکه اجرا کنند. با FaaS، توسعه‌دهندگان می‌توانند یک معماری ماژولار بسازند، و یک پایگاه کدی بسازند که مقیاس‌پذیرتر باشد، بدون اینکه نیازی به صرف منابع برای نگهداری بک‌اند اصلی باشد.
Serverless computing چه مزایایی دارد؟
- هزینه های کمتر - Serverless computing عموماً بسیار مقرون به صرفه است، زیرا ارائه دهندگان ابر سنتی خدمات پشتیبان (تخصیص سرور) اغلب منجر به پرداخت هزینه فضای استفاده نشده یا زمان بیکار CPU توسط کاربر می شود.
- مقیاس‌پذیری ساده - توسعه‌دهندگانی که از معماری Serverless استفاده می‌کنند، لازم نیست نگران سیاست‌هایی برای افزایش مقیاس کد خود باشند. فروشنده Serverless، تمام مقیاس بندی ها را در صورت تقاضا انجام می دهد.
- کد بک‌اند ساده شده - با FaaS، توسعه دهندگان می توانند توابع ساده ای ایجاد کنند که به طور مستقل یک هدف واحد را انجام می دهند، مانند برقراری تماس API.
- چرخش سریعتر - معماری Serverless می تواند زمان عرضه به بازار را به میزان قابل توجهی کاهش دهد. توسعه‌دهندگان به‌جای نیاز به یک فرآیند استقرار پیچیده برای رفع اشکال و ویژگی‌های جدید، می‌توانند کد را به‌صورت مقطعی اضافه و تغییر دهند.
چگونه Serverless با سایر مدل‌های بک‌اند ابری مقایسه می‌شود؟
چند فناوری که اغلب با محاسبات بدون سرور ترکیب می شوند عبارتند از Backend-as-a-a-Service و Platform-as-a-a-Service. اگرچه این مدل‌ها شباهت‌های مشترکی دارند، اما این مدل‌ها الزاماً الزامات بدون سرور را برآورده نمی‌کنند.
Backend-as-a-service (BaaS) یک مدل سرویس است که در آن یک ارائه دهنده ابر خدمات باطنی مانند ذخیره سازی داده ها را ارائه می دهد، به طوری که توسعه دهندگان می توانند روی نوشتن کدهای فرانت اند تمرکز کنند. اما در حالی که برنامه های بدون سرور رویداد محور هستند و در لبه اجرا می شوند، برنامه های BaaS ممکن است هیچ یک از این الزامات را برآورده نکنند.
(PaaS) Platform-as-a-serviceمدلی است که در آن توسعه‌دهندگان اساساً تمام ابزارهای لازم را برای توسعه و استقرار برنامه‌های کاربردی از یک ارائه‌دهنده ابری، از جمله مواردی مانند سیستم‌های عامل و میان‌افزار، اجاره می‌کنند. با این حال، برنامه‌های PaaS به سادگی برنامه‌های بدون سرور مقیاس‌پذیر نیستند. PaaS همچنین لزوماً روی لبه اجرا نمی‌شود و اغلب تأخیر قابل توجهی در راه‌اندازی دارد که در برنامه‌های بدون سرور وجود ندارد.
Infrastructure-as-a-service (IaaS) یک اصطلاح مهم برای فروشندگان ابری است که زیرساخت ها را از طرف مشتریان خود میزبانی می کنند. ارائه دهندگان IaaS ممکن است عملکرد بدون سرور ارائه دهند، اما این اصطلاحات مترادف نیستند.
محاسبات بدون سرور همچنان به تکامل خود ادامه می دهد زیرا ارائه دهندگان بدون سرور راه حل هایی برای غلبه بر برخی از معایب آن ارائه می دهند.
معمولاً وقتی یک عملکرد بدون سرور خاص برای مدتی فراخوانی نشده باشد، ارائه دهنده عملکرد را خاموش می کند تا در مصرف انرژی صرفه جویی کند و از تامین بیش از حد جلوگیری کند. دفعه بعد که کاربر برنامه‌ای را اجرا می‌کند که آن عملکرد را فراخوانی می‌کند، ارائه‌دهنده بدون سرور باید دوباره میزبانی آن عملکرد را آغاز کند. این زمان راه اندازی تاخیر قابل توجهی را اضافه می کند که به عنوان "شروع سرد" شناخته می شود.
پس از راه‌اندازی و اجرا، در درخواست‌های بعدی با سرعت بیشتری ارائه می‌شود (شروع گرم)، اما اگر این تابع برای مدتی دوباره درخواست نشود، عملکرد دوباره خاموش می‌شود. این بدان معناست که کاربر بعدی که آن عملکرد را درخواست می کند، شروع سرد را تجربه خواهد کرد. تا همین اواخر، شروع سرد به عنوان یک مبادله ضروری برای استفاده از توابع بدون سرور در نظر گرفته می شد.
همانطور که بیشتر و بیشتر معایب استفاده از بدون سرور برطرف می شود و محبوبیت محاسبات لبه افزایش می یابد، می توان انتظار داشت که معماری بدون سرور گسترده تر شود.
در دنیای دیجیتال برای تبلیغات باید از کد UTM استفاده کنید
چرا از محاسبات بدون سرور (serverless) استفاده کنیم؟
محاسبات بدون سرور مزایای زیادی نسبت به زیرساخت‌های سنتی مبتنی بر ابر یا سرور محور دارد. برای بسیاری از توسعه‌دهندگان، معماری‌های بدون سرور، مقیاس‌پذیری بیشتر، انعطاف‌پذیری بیشتر و زمان انتشار سریعتر را ارائه می‌دهند که همگی با هزینه‌ای کمتر هستند. با معماری های بدون سرور، توسعه دهندگان نیازی به نگرانی در مورد خرید، تهیه و مدیریت سرورهای پشتیبان ندارند. با این حال، محاسبات بدون سرور یک گلوله جادویی برای همه توسعه دهندگان برنامه های وب نیست.
محاسبات بدون سرور (serverless) چگونه کار می کند؟
محاسبات بدون سرور معماری است که در آن یک فروشنده خدمات پشتیبان را در صورت نیاز ارائه می دهد.
محاسبات بدون سرور چه مزایایی دارد؟
- نیازی به مدیریت سرور نیست - اگرچه محاسبات "بدون سرور" در واقع روی سرورها انجام می شود، توسعه دهندگان هرگز مجبور نیستند با سرورها سروکار داشته باشند. آنها توسط فروشنده مدیریت می شوند. این می‌تواند سرمایه‌گذاری لازم در DevOps را کاهش دهد که هزینه‌ها را کاهش می‌دهد و همچنین توسعه‌دهندگان را آزاد می‌کند تا برنامه‌های خود را بدون محدودیت ظرفیت سرور ایجاد و گسترش دهند.
- برنامه‌نویس‌ها فقط برای فضای سروری که استفاده می‌کنند، هزینه دریافت می‌کنند و هزینه را کاهش می‌دهند - همانطور که در یک طرح تلفنی «پرداخت در زمان خرید»، توسعه دهندگان فقط برای آنچه استفاده می کنند هزینه دریافت می کنند. کد فقط زمانی اجرا می‌شود که برنامه‌های بدون سرور به توابع پشتیبان نیاز داشته باشند، و کد به‌طور خودکار در صورت نیاز افزایش می‌یابد. تامین پویا، دقیق و در زمان واقعی است. برخی از خدمات آنقدر دقیق هستند که هزینه های خود را به 100 میلی ثانیه تقسیم می کنند. در مقابل، در معماری سنتی «پر از سرور»، توسعه‌دهندگان باید از قبل برنامه‌ریزی کنند که چه مقدار ظرفیت سرور نیاز دارند و سپس آن ظرفیت را خریداری کنند، خواه در نهایت از آن استفاده کنند یا نه.
- معماری های بدون سرور ذاتا مقیاس پذیر هستند - تصور کنید که اداره پست بتواند به نحوی جادویی کامیون‌های تحویل را به دلخواه خود اضافه و از خدمت خارج کند، و اندازه ناوگان خود را با افزایش پست‌ها افزایش دهد و ناوگان خود را برای مواقعی که تحویل کمتری لازم است کاهش دهد. این در اصل کاری است که برنامه های بدون سرور قادر به انجام آن هستند. برنامه‌هایی که با زیرساخت بدون سرور ساخته می‌شوند، با افزایش پایگاه کاربر یا افزایش استفاده، به‌طور خودکار مقیاس خواهند شد. اگر یک تابع نیاز به اجرا در چندین نمونه داشته باشد، سرورهای فروشنده آنها را در صورت نیاز راه‌اندازی، اجرا و پایان می‌دهند و اغلب از کانتینرها استفاده می‌کنند. در نتیجه، یک برنامه بدون سرور قادر خواهد بود به همان اندازه که می‌تواند یک درخواست از یک کاربر واحد را پردازش کند، تعداد زیادی از درخواست‌ها را به طور غیرعادی مدیریت کند. یک برنامه کاربردی با ساختار سنتی با مقدار ثابتی از فضای سرور می تواند با افزایش ناگهانی استفاده از بین برود.
- استقرار سریع و به روز رسانی امکان پذیر است - با استفاده از یک زیرساخت بدون سرور، نیازی به آپلود کد در سرورها یا انجام هر گونه تنظیمات بک‌اند به منظور انتشار یک نسخه کاربردی از یک برنامه نیست. توسعه دهندگان می توانند به سرعت بیت های کد را آپلود کرده و محصول جدیدی را منتشر کنند. آنها می توانند کد را به یکباره یا یک تابع در یک زمان آپلود کنند، زیرا برنامه یک پشته یکپارچه نیست، بلکه مجموعه ای از توابع ارائه شده توسط فروشنده است. همچنین این امکان را فراهم می کند که به سرعت به روز رسانی، وصله، تعمیر یا اضافه کردن ویژگی های جدید به یک برنامه کاربردی انجام شود. نیازی به ایجاد تغییرات در کل برنامه نیست. در عوض، توسعه‌دهندگان می‌توانند برنامه را یک‌بار به‌روزرسانی کنند.
- کد می‌تواند نزدیک‌تر به کاربر نهایی اجرا شود و تأخیر را کاهش دهد - از آنجایی که برنامه روی سرور اصلی میزبانی نمی شود، کد آن را می توان از هر جایی اجرا کرد. بنابراین، بسته به فروشنده مورد استفاده، امکان اجرای توابع برنامه بر روی سرورهایی که نزدیک به کاربر نهایی هستند وجود دارد. این امر تأخیر را کاهش می‌دهد زیرا درخواست‌های کاربر دیگر لازم نیست تمام راه را به یک سرور مبدا سفر کنند.
معایب محاسبات بدون سرور چیست؟
- تست و اشکال زدایی چالش برانگیزتر می شود - تکثیر محیط بدون سرور برای اینکه ببینیم کد پس از استقرار واقعاً چگونه عمل می کند دشوار است. اشکال‌زدایی پیچیده‌تر است زیرا توسعه‌دهندگان قابلیت مشاهده در فرآیندهای بک‌اند را ندارند و به این دلیل که برنامه به توابع جداگانه و کوچک‌تر تقسیم می‌شود.
- محاسبات بدون سرور نگرانی های امنیتی جدیدی را معرفی می کند - هنگامی که فروشندگان کل بک‌اند را اجرا می کنند، ممکن است امکان بررسی کامل امنیت آنها وجود نداشته باشد، که به ویژه برای برنامه هایی که داده های شخصی یا حساس را مدیریت می کنند می تواند مشکل ساز باشد. از آنجا که به شرکت‌ها سرورهای فیزیکی مجزا اختصاص داده نمی‌شود، ارائه‌دهندگان بدون سرور اغلب کدهای چند مشتری خود را در هر زمان معین روی یک سرور واحد اجرا می‌کنند.
- معماری های بدون سرور برای فرآیندهای طولانی مدت ساخته نشده اند - این، انواع برنامه‌هایی را که می‌توانند در معماری بدون سرور اجرا شوند، محدود می‌کند. از آنجایی که ارائه دهندگان بدون سرور برای مدت زمان اجرای کد هزینه می پردازند، ممکن است هزینه اجرای یک برنامه با فرآیندهای طولانی مدت در یک زیرساخت بدون سرور در مقایسه با زیرساخت سنتی بیشتر باشد.
- عملکرد ممکن است تحت تأثیر قرار گیرد - از آنجا که به طور مداوم در حال اجرا نیست، کد بدون سرور ممکن است نیاز به "بوت کردن" در هنگام استفاده داشته باشد. این زمان راه اندازی ممکن است عملکرد را کاهش دهد. با این حال، اگر یک قطعه کد به طور منظم استفاده شود، ارائه‌دهنده بدون سرور آن را آماده فعال کردن نگه می‌دارد - درخواست برای این کد آماده، "شروع گرم" نامیده می‌شود. درخواستی برای کدی که مدتی است استفاده نشده است، "شروع سرد" نامیده می شود.
- پایان خدمات دهی فروشنده یک خطر است - اجازه دادن به یک فروشنده برای ارائه تمام خدمات بک‌اند برای یک برنامه به طور اجتناب ناپذیری اتکا به آن فروشنده را افزایش می دهد. راه‌اندازی یک معماری بدون سرور با یک فروشنده می‌تواند تعویض فروشنده‌ها را در صورت لزوم دشوار کند، به‌ویژه که هر فروشنده ویژگی‌ها و گردش‌های کاری کمی متفاوت ارائه می‌کند.
چه کسی باید از معماری بدون سرور (serverless) استفاده کند؟
توسعه دهندگانی که می خواهند زمان ورود خود به بازار را کاهش دهند و برنامه های کاربردی سبک وزن و انعطاف پذیری بسازند که می توانند به سرعت گسترش یابند یا به روز شوند، ممکن است از محاسبات بدون سرور بهره زیادی ببرند.
معماری‌های بدون سرور هزینه‌های برنامه‌هایی را که استفاده ناسازگاری دارند، با دوره‌های اوج متناوب با زمان‌های کم یا بدون ترافیک، کاهش می‌دهند. برای چنین برنامه‌هایی، خرید سرور یا بلوکی از سرورهایی که دائماً در حال اجرا هستند و همیشه در دسترس هستند، حتی زمانی که استفاده نمی‌شوند، ممکن است اتلاف منابع باشد. یک راه‌اندازی بدون سرور در صورت نیاز فوراً پاسخ می‌دهد و در حالت استراحت هزینه‌ای را متحمل نمی‌شود.
همچنین، توسعه‌دهندگانی که می‌خواهند برخی یا همه توابع برنامه خود را برای کاهش تأخیر به کاربران نهایی نزدیک کنند، حداقل به یک معماری بدون سرور نیاز دارند، زیرا انجام این کار مستلزم انتقال برخی از فرآیندها به خارج از سرور اصلی است.
چه زمانی توسعه دهندگان باید از استفاده از معماری بدون سرور اجتناب کنند؟
مواردی وجود دارد که هم از منظر هزینه و هم از دیدگاه معماری سیستم، استفاده از سرورهای اختصاصی که یا خود مدیریت هستند یا به عنوان یک سرویس ارائه می شوند، منطقی تر است. به عنوان مثال، برنامه های بزرگ با حجم کاری نسبتاً ثابت و قابل پیش بینی ممکن است به یک راه اندازی سنتی نیاز داشته باشند و در چنین مواردی راه اندازی سنتی احتمالاً هزینه کمتری دارد.
علاوه بر این، ممکن است انتقال برنامه های کاربردی قدیمی به یک زیرساخت جدید با معماری کاملاً متفاوت بسیار دشوار باشد.
