فناوری های Serverless و کاربرد آن ها به زبان ساده
این روزها به هر رویداد آی تی یا برنامه نویسی که وارد می شوم ، امکان ندارد درباره محاسبات Serverless چیزی نشنوم. بحث بر سر این تکنولوژی نقل تمام محافل علمی و تخصصی این روزهاست. می دانیم که Less به آخر هر کلمه ای که اضافه می شود ، مفهوم متضاد را برای کلمه به بار می آورد. بنابراین در نگاه اول با تعجب تصور کردم که تکنولوژی به جایی رسیده است که محاسبات به جای پردازش بر روی ابرکامپیوتر ها و سرورها قرار است از این به بعد بر روی مولکول های هوا صورت پذیرد. بعد به این فکر کردم که شاید منظور از ServerLess یا محاسبات “بدون سرور” استفاده از کانتینرها ( مانند پلت فرم داکر ) است؟ ولی ظاهرا قضیه چیز دیگری بود. کنجکاوی و تکرار بیش از حد این واژه در تمام Meetup ها باعث شد که مقاله پیش رو در وب سایت تک تیک منتشر شود.
محاسبات سرورلس چیست؟
محاسبات Serverless به زبان ساده به معنای یک متود به منظور فراهم آوردن سرویس های Backend تنها به همان میزانی که استفاده می شوند است. اگرچه که واقعا شاید این تعریف ساده و روشن نباشد ، اما پیش از هر چیز حداقل مشخص کننده این است که Serverless ( سرورلس ) یک روش یا متد است. ارائه دهندگان Serverless ( مانند کلودفلر ) به کاربران خود ( برنامه نویسان وب ) اجازه می دهند تا بدون نگرانی از بابت زیر ساخت ، کد خود را اجرا نمایند. در واقع منظور از Serverless این نیست که هیچ سروری وجود ندارد. بلکه منظور این است که برنامه نویسان هیچ نیازی ندارند درباره سرور ها ( یا حتی کانتینرها ) اطلاعاتی کسب کنند. بنابراین نیازی به محاسبه میزان مورد نیاز منابع برای اجرای یک تابع از بین می رود. چرا که با استفاده از متود سرورلس ، توابع به عنوان یک سرویس توسط Provider ها ارائه می شوند و مقدار استفاده از توابع به جای مقدار استفاده از منابع ( تعداد سرورها و پهنای باند ) ، ملاک محاسبه هزینه خواهد بود! ارائه توابع به عنوان یک سرویس ، اصطلاح جدیدی را به دنیای آی تی و برنامه نویسی آورد که از آن به عنوان FaaS یا Function as a Service یاد می کنند.
Click here to preview your posts with PRO themes ››
اجازه دهید با مروری بر تاریخچه وب ، علت به وجود آمدن محاسبات Serverless و اینکه چرا Cloud ، به تنهایی برای سازمان ها کافی و به صرفه نیست را بررسی نماییم.
در اولین روزهای پیدایش وب ، هرکسی که قصد داشت یک برنامه تحت وب ( Web Application ) را بسازد ، باید یک سرور فیزیکی نیز تهیه می کرد. این موضوع نیازمند صرف هزینه گزاف و پیچیدگی های بسیار بود. بعد از آن فناوری Cloud متولد شد. در تعریف سنتی Cloud ، شما برای تعداد مشخصی از سرور ها و منابع آن ها به صورت ثابت یک هزینه پرداخت می کنید. در واقع یک سرور Remote را اجاره می کنیم. اگر چه در این روش ما از شر پیچیدگی نگه داری تجهیزات فیزیکی آزاد شده ایم ، اما مشکل اینجاست که به طور معمول از تمام منابعی که در حال پرداخت هزینه آن هستیم استفاده نمی کنیم. حتی با بهترین برنامه ریزی ها نیز همیشه مجبور هستیم با در نظر گرفتن ریسک های احتمالی ، مقدار بیش تری از منابع مورد نیازمان را خریداری کنیم که کیفیت سرویس مان را تضمین نماییم.
تفسیر نتایج استفاده آزمایشی فیس بوک از DNS امن CloudFlare را در این لینک بخوانید.
در تعریف مدرن محاسبات ابری به لطف مدل های Auto Scaling این مشکل نیز تقریبا حل شده است و شما تنها به مقدار منابعی که هر لحظه در حال استفاده هستید هزینه پرداخت می کنید. اما این روش نیز تا حد زیادی ممکن است هزینه اضافه ای را به سازمان تحمیل نماید. فرض کنید که شما یک سرویس ابری Auto Scale خریداری کرده اید که در پایان هر ماه ، تنها به میزان منابعی که استفاده کرده اید از شما هزینه دریافت می شود. اما اگر برای مثال دچار حمله های DDoS شوید ، مجبور به پرداخت هزینه استفاده مهاجمان از سرویس تان خواهید شد !!!
Click here to preview your posts with PRO themes ››
بنابراین در تعریف نهایی متود Serverless ، نیازی به پرداخت هزینه بابت منابع مورد استفاده نخواهید داشت. بلکه از این بعد بر مبنای توابع و Backend ای که در اختیار شما قرار خواهد گرفت ، هزینه پرداخت خواهید کرد و سایر نگرانی ها ، از جمله حمله های DDoS و … تنها متوجه Provider ها خواهد بود و آن ها تمهیدات لازم را خواهند اندیشید.
مثال های واقعی از Serverless
دامنه techtik.com را در نظر بگیرید. فرض کنید که شما از شرکتی به نام bitjoo.com یک سرویس وبلاگ خریداری نموده اید. در نتیجه دامنه techtik.bitjoo.com به شما تعلق یافته است. اکنون به دلیل قوانین سئو Best Practice این خواهد بود که کاربران برای دستیابی به سرویس وبلاگی که بر روی techtik.bitjoo.com قرار دارد آدرس ساب دایرکتوری techtik.com/blog را وارد کنند و وب سرور طوری پیکربندی شده باشد که در زمان درخواست techtik.com/blog دامنه techtik.bitjoo.com را فراخوانی کند. در این مثال اگر وب سرور ما NGINX باشد ، یکی از راه حل ها این خواهد بود که با استفاده از مصرف منابع Web Server و با راه اندازی یک Recursive Proxy ، به طور دائم تمام درخواست های ساب دایرکتوری techik.com/blog را برای از دست ندادن سودمندی های رتبه SEO دامنه Techtik.com به دامنه techtik.bitjoo.com ارسال کنیم. جدا از پیچیدگی که ایجاد یک Recursive Proxy بر روی NGINX دارد ، شما باید نگران میزان مصرف منابع مورد نیاز این تعداد از درخواست برای وب سایتی مانند تک تیک با ۷۰۰۰ بازدید در روز نیز باشید ! در اینجا متود Serverless راه حل دومی را پیش پای شما خواهد گذاشت :
Click here to preview your posts with PRO themes ››
همان طور که گفته شد یکی از شرکت های ارائه دهنده خدمات FaaS شرکت Cloudflare می باشد که این امکان را در قالب Cloudflare Workers فراهم آورده است. Workers ها توابع از پیش آماده ای هستند که توسط کلود فلیر ارائه می شوند. به منظور ایجاد چنین سناریویی هم در کلودفلیر یک Worker وجود دارد. شما کافی ست تنها با پرداخت هزینه اندک استفاده از این ورکر به صورت ماهانه و به میزان نیاز ، این سناریو را پیاده سازی نمایید !
در آینده مقاله های بیش تری از سناریوهای جالبی که می توانیم با استفاده از Worker ها در کلود فلیر پیاده سازی نماییم در وب سایت تک تیک منتشر خواهد شد. همچنین در صورت تمایل ، جهت حمایت از ما ، لطفا کانال یوتیوب را در این آدرس Subscribe نمایید.
ممنون استفاده کردم
خیلی بد بودمر
سلام. خوشحال می شدم که نقاط ضعف مقاله را متذکر می شدید تا آن را بهبود دهیم و از تولید مقاله های با کیفیت بد در آینده جلوگیری شود. اما به هر حال ممنون از وقتی که صرف نظر گذاشتن برای یک مقاله بد کردید.