img

معماری‌های بدون سرور

/
/
/

بررسی رایانش بدون سرور

ساختار های بدون سرور به اپلیکیشن هایی گفته می شود که وابستگی زیادی به خدمات شخص سوم معروف به BaaS (مخفف Backend as a service به معنیِ لایه ی پُشتی به عنوان خدمات) یا کُد های مشتری که بر روی FaaS (مخفف Function as a Service به معنی تابع به عنوان خدمات) اجرا می شوند، دارند.

 

در دهه ی ۱۹۹۰ میلادی، نیل فورد (Neal Ford) در یک شرکت کوچک کار می کرد که فعالیت آن بر روی یک فناوری به نام Clipper متمرکز شده بود. با نوشتن یک چارچوب مُبتنی بر شیء بر اساس Clipper، اپلیکیشن های DOS با استفاده از dBase ساخته می شدند. با وجود تخصص این شرکت در Clipper، آن ها توانسته بودند که یک تجارت مشاوره و آموزش موفق را راه اندازی کنند. پس از آن و با ظهور ویندوز (Windows)، ناگهان این تجارت مبتنی بر Clipper از بین رفت. بنا بر این، نیل فورد و گروهش به تکاپو اُفتادند تا فناوری های جدید را یاد گرفته و با آن ها تطبیق پیدا کنند. نباید فراموش کرد که «دنیایِ فناوری همیشه در حال تغییر است» و نمی توان بدون سازگار شدن با تغییرات زندگی کرد.
بسیاری از ما، درونِ «حُباب های فناوری» زندگی می کنیم. خیلی آسان است که در محدوده ی اَمنِ خودمان باقی بمانیم و متوجه آن چه در اطرافمان می گذرد نباشیم. ناگهان، بعد از ترکیدن حباب ها، در حالی که گیج و سرگردان هستیم به این فکر می اُفتیم که به دنبال یک کار یا تجارت جدید بگردیم. بنا بر این، مهم است که همیشه با دنیای فناوری در ارتباط باشیم. در دهه ی ۹۰ میلادی، در ارتباط بودن به معنی آشنایی با مفهوم هایی مانند رابط های کاربر گرافیکی (GUI ها)، فناوری های سرور/کاربر و وِب (World Wide Web) بود اما امروزه رایانش اَبری، یادگیریِ دستگاه (ماشین)، هوش مصنوعی و مفهوم هایی مانند این ها، به معنیِ در ارتباط بودن است.
با این پَس زمینه ی ذهنی، اجازه بدهید به موضوع این مقاله یعنی رایانش بدون سرور (serverless computing) که یکی از جدید ترین مفهوم ها در دنیای فناوری های امروز است بپردازیم. در این مقاله، خواننده را با چگونگیِ استفاده از رویکرد (رهیافت) بدون سرور در اپلیکیشن ها و فناوری های بدون سرور کلیدی آشنا کرده و در انتها نیز نگاهی به محدودیت های فناوری بدون سِروِر خواهیم داشت.

 

چرا بدون سرور؟
بسیاری از ما استفاده از فُرم های مختلف دستگاه (ماشین) های سرورِ را به خاطر داریم. یادمان می آید که از راه دور به دستگاه های سرور وارد (logging) شده و با آن ها برای چند ساعت کار می کردیم. اسم های جالبی مانند Bailey، Daisy، Charlie، Ginger و Teddy روی آن ها می گذاشتیم، با آن ها به بهترین شکل ممکن رفتار می کردیم و حسابی مواظبشان بودیم. البته در زمان استفاده از سرور های فیزیکی با این مشکلات نیز روبرو می شدیم:
* شرکت ها باید در مورد حجم اطلاعات برنامه ریزی کرده و مقدار نیازشان به منابع در آینده را پیش بینی می کردند،
* خریدن سرور ها به معنی هزینه های سرمایه ایِ (capital expenses یا capex) زیاد برای شرکت ها بود،
* برای خریدن سرور ها باید مراحل اداری زیادی انجام می شد،
* آماده کردن سرور ها بعد از خرید، کاری زمان بُر بود.
البته می توانیم به موارد بیشتری هم اشاره کنیم. مجازی کردن و استفاده از فناوری های مبتنی بر اَبر، سطحی جدید از انعطاف پذیری را برای ما ایجاد کرد که تا قبل از آن و در زمان استفاده از سرور های فیزیکی، در اختیارمان نبود. در این شرایط، نیازی به دنبال کردن مراحل طولانی خرید نداشته، نگران این که «چه کسی مالِکِ سرور های ما است» نبوده و به این موضوع که چرا فقط «گروهی خاص به سرور های قوی دسترسی دارند» فکر نمی کنیم (البته باز هم به موارد بیشتری می توانیم اشاره کنیم). در حقیقت با وجود دستگاه (ماشین) های مجازی (VM ها مخفف Virtual Machine) و اَبر، راه و روشِ خریدن سرو های فیزیکی منسوخ شده و مشکلات مربوط به آن ها نیز از سر راه ما برداشته شده اند. البته مهم ترین نکته این است که ساختار (معماری) مورد استفاده ی ما نیز عوض شده است. برای نمونه، به جای اضافه کردن حافظه یا CPU های بیشتر به سرور های فیزیکی برای تغییر مقیاس عمودی (scaling up)، با اضافه کردن دستگاه (ماشین) ها بر اساس نیازمان و البته در اَبر، شروع به تغییر مقیاس اُفقی (scaling out) می کنیم. این مُدِل، انعطاف پذیریِ یک مُدِل بازدِهِ مبتنی بر هزینه ی عملیاتی (operational expenses-based revenue model یا opex) را به ما می دهد. اگر یکی از ماشین های مجازی (VM ها) از کار بیفتد، در کمتر از چند دقیقه، ماشین های جدید در اختیار ما قرار داده می شود.
البته مجازی سازی و اَبر نیز محدودیت ها و مشکلات مربوط به خودشان را دارند. ما هنوز هم زمان زیادی به مدیریت کردن آن ها، برای نمونه بالا و پایین آوردن VM ها، اختصاص می دهیم. ما باید ساختار سازی (معماری) جدیدی برای در دسترس بودن، تحمل پذیری اشکال یا تاب آوریِ خطا (fault-tolerance)، اندازه ی حجم کار، مدیریت ظرفیت و استفاده ی سودمند داشته باشیم. اگر VM های تایین شده ای در اَبر داشته باشیم، باید مبلغی برای منابع ذخیره شده (اگر فقط برای زمان بیکاری هم باشد) بپردازیم. بنا بر این، تغییر از یک مدل هزینه ی عملیاتی (capex) به یک مدل هزینه ی سرمایه ای (opex)، به تنهایی کافی نیست. چیزی که به آن نیاز داریم این است که تنها به مقداری که نیازمان را برطرف می کند (و نه بیشتر از آن) پرداخت کرده و هزینه های بعدی را در صورت نیاز، با توجه به احتیاجات سیستم و با گذر زمان انجام دهیم. البته رایانش بدون سرور، وعده داده تا با این مشکل روبرو شود.
جنبه ی کلیدی دیگر موضوع، چابُکی است. تجارت های امروزی، باید سریع و چابُک باشند. پیچیدگیِ فناوری و گزینه های مختلف زیر ساخت نمی توانند به عنوان بهانه ای برای ارائه نکردن ارزش بر اساس مقیاس (value at scale) باشند. در بهترین حالت، بیشتر تلاش های مهندسی باید بر روی تامین کاربردی که تجربه ی مورد نیاز را منتقل کند، و نه نظارت و مدیریت زیر ساختار پشتیبانی کننده نیاز های مقیاس، متمرکز باشد. این جا همان نقطه ای است که رایانش بدون سرور، بی نظیر است.

 

معماری‌های بدون سرور بررسی رایانش بدون سرور

 

بدون سرور چیست؟
یک رُبات سخنگو (chatbot) برای رِزرو بلیط سینما را در نظر بگیرید و نام آن را MovieBot بگذارید. هر کاربری می تواند در یک سَبکِ مکالمه ای (conversational style) فیلم ها را جستجو کرده، بلیط ها را رِزِرو کرده یا رزرو ها را لغو کند.
این راه حل به ۳ قسمت یا بخش احتیاج دارد: یک کانالِ رابط چَت (chat interface channel) مانند پیام رسان Facebook یا Skype، یک پردازنده ی زبان طبیعی (NLP مخفف natural language processor) برای فهمیدن منظور کاربر (رزرو بلیط، درخواست اطلاع از موجود بودن بلیط، لغو درخواست و غیره) و در آخر دسترسی به یک لایه ی پُشتی (back-end) یا لایه ی دسترسیِ داده که در آن اطلاعات مربوط به فیلم ها ذخیره شده است. کانال های رابط چَت، جهانی (سراسری) بوده و می توانند برای انواع مختلفی از ربات ها به کار برده شوند. پردازنده ی زبان طبیعی (NLP) می تواند با استفاده از فناوری هایی مانند AWS Lex یا IBM Watson پیاده سازی شود. پُرسش این است: لایه ی پُشتی (back-end) چگونه کار می کند؟ آیا باید یک سرور (یا گروهی از سرور های) اختصاص داده شده به آن داشته باشیم، یک درگاه API برایش ایجاد کنیم، متوازن کننده های بار (load) را توسعه بدهیم یا ساز و کار (مکانسیم) های کنترل دسترسی و شناسه را اختصاص بدهیم؟ درست است! همه ی این ها هزینه ی زیادی دارند و البته آسان هم نیستند. این جا، همان جایی است که فناوری بدون سرور می تواند به کمک ما بیاید.
راه حل این است که ظرفیت محاسباتی لازم برای پردازش داده ها را از یک پایگاه داده راه اندازی (set up) کرده و از طرفی این منطق را در یک زبان انتخاب، اجرا کنیم. برای نمونه، اگر از پایگاه AWS استفاده می کنید، می توانید برای لایه ی پُشتی (back-end) از DynamoDB استفاده کرده، منطق برنامه نویسی را به عنوان تابع های Lambda نوشته و آن ها را به وسیله ی درگاه AWS API به همراه تنظیم کننده ی بار (load)، ارائه کنید. برای این نصب و راه اندازیِ کامل، نیازی به آماده سازی زیر ساختار نبوده و لازم نیست دانشی در زمینه ی چگونگی قرار داشتن سرور/VM ها در اَبر داشته باشید. شما می توانید از پایگاه داده ی مورد نظرتان برای لایه ی پُشتی (back-end) استفاده کنید. سپس یکی از زبان های برنامه نویسیِ پشتیبانی شده در AWS Lambda مانند Java، Python، JavaScript و C# را انتخاب کنید. اگر هیچ کاربری وجود نداشته باشد که از MovieBot استفاده کند، هزینه ای هم در کار نخواهد بود. اگر یک فیلم موفق روی پرده بیاید، مردم به دنبال خرید و رزرو بلیط آن خواهند رفت و همه جا را جستجو می کنند تا از جدول پخش آن خبر دار شوند پس MovieBot در این زمان بازدید کننده های زیادی خواهد داشت و همه ی کار ها بدون این که زحمت زیادی داشته باشد، انجام می شود (البته باید بابت تماس ها هزینه پرداخت کنید). باور کردنی نیست اما شما توانسته اید یک نرم افزار بدون سرور را راه اندازی کنید.
حالا زمان آن رسیده تا عبارت «بدون سرور» را تعریف کنیم. معماری (یا ساختار) بدون سرور به اپلیکیشن هایی اشاره دارد که به شکل قابل توجهی به خدمات شخص سوم (معروف به BaaS مخفف Backend as a service به معنیِ لایه ی پُشتی به عنوان خدمات) یا کُد های مشتری که بر روی حمل کننده های زود گذر یا ephemeral containers (معروف به FaaS مخفف Function as a Service به معنی تابع به عنوان خدمات) اجرا می شوند، وابسته هستند.
بسیار خوب، این تعریف عبارت های فنیِ زیادی دارد پس بهتر است معنیِ آن ها را توضیح بدهیم.
* لایه ی پُشتی به عنوان خدمات (Backend-as-a-Service): به طور نمونه، پایگاه داده (در بیشتر موارد به سبک NoSQL)، داده ها را نگه داشته و می تواند بر روی اَبر قابل دسترسی باشد و یک سرویس (خدمات) می تواند برای کمک به دستریِ این لایه ی پُشتی (back-end)، به کار گرفته شود. مخفف این عبارت Baas است.
* تابع به عنوان خدمات (Function-as-a-Service): کُدی که درخواست ها (برای نمونه، درخواست programming logic نوشته شده در زبان برنامه نویسی مورد انتخاب شما) را پردازش می کند، می تواند بر روی حمل کننده (container) هایی که بر اساس نیاز حرکت کرده و از بین رفته اند، اجرا شود. مخفف این عبارت، FaaS است.
عبارت «بدون سرور» به دلیل این که در زبان به این معنی است که هیچ سروری وجود ندارد، گمراه کننده است. در حقیقت این عبارت یعنی «من به عنوان کاربر اهمیتی نمی دهم که سرور چه چیزی است». به عبارت دیگر، بدون سرور به ما این امکان را می دهد که اپلیکیشن ها را بدون فکر کردن درباره ی سرور ها ایجاد کرده و می توانیم اپلیکیشن ها را بدون نگرانی درباره ی تامین، مدیریت یا مقیاس بندی زیر ساختار مورد نیاز آن ها، ایجاد نموده و اجرا کنیم. فقط باید کُد مورد نظرتان را در اَبر وارد کرده و آن را اجرا کنید! به خاطر داشته باشید که این شرایط در Platform-as-a-Service (به معنی پایگاه به عنوان خدمات یا همان PaaS) نیز کاربرد دارد. اگر چه ممکن است شما در زمان کار کردن با PaaS، به طور مستقیم با VM ها روبرو نشوید اما هنوز هم باید ظرفیت ها و مقیاس ها را بررسی کنید.
باید «بدون سرور» را به عنوان قسمتی از عملکردِ اجرا، و نه قسمتی از دستگاهتان، در نظر بگیرید که از راه دور کنترل می شود. به طور نوعی، تابع های بدون سرور در یک حالت رویداد محور (event-driven) اجرا می شود. این تابع ها به عنوان یک واکنش به رویداد ها و درخواست ها بر روی HTTP اجرا می شوند. در مورد MovieBot، تابع های Lambda برای کمک به پُرس و جویِ (query) کاربر و زمانی که کاربر در حال کار کردن با برنامه است، به کار گرفته می شوند.

 

موارد استفاده
با زیر ساختار یا معماریِ بدون سرور، توسعه دهندگان می توانند در حالی که هزینه ها را بهینه می کنند، انواع مختلفی از راه حل ها را برای مقیاس مورد نظرشان پیاده کنند. پیش از این، توسعه ی ربات های سخنگو (chatbot ها)، که یکی از کاربرد های کلاسیک برای رایانش بدون سرور است را بررسی کرده ایم. استفاده های مهم دیگرِ رویکرد بدون سرور را در ادامه بیان می کنیم.
۱- اپلیکیشن های وِبِ سه لایه (Three-tire): اپلیکیشن ها یا برنامه های تک صفحه ای (یا SPA مخفف Single Page Application که برنامه‌ هایِ تحت وب یا وب ‌گاه‌ هایی هستند که تنها دارای یک صفحه بوده و در حقیقت در آن ها تمامی کد های مورد نیاز سمت کاربر در یک صفحه نوشته می ‌شوند) که بر اساس خدمات مبتنی بر انتقال حالت نمایندگی (REST مخفف Representative State Transfer) برای اجرای یک عملکرد مشخص هستند، می توانند برای به کار بردن تابع های بدون سرور لایه ی جلویی (front-end) یا لایه ی ارائه با استفاده از یک درگاه API، دوباره نوشته شوند. این یک الگوی قدرتمند است که بدون توجه به پیکر بندیِ تغییر مقیاس اُفقی (scale-out) یا منبع های زیر ساختار، کمک زیادی به مقیاس بندیِ اپلیکیشن شما می کند.
۲- وظایف (کارهای) دسته ای مقیاس پذیر (Scalable batch jobs): کار ها یا وظایف دسته ای به صورت سنتی به عنوان فرآیند های پس زمینه یا دیمُن ها (Deamon که برنامه ای در سیستم عامل هایی با قابلیت چند کارگی است که به جای این که زیر کنترل مستقیم یک کاربر باشد، در پس زمینه اجرا می شود) بر روی VM های تخصیص داده شده، اجرا می شوند. در بیشتر موارد، این رویکرد، به مقیاس پذیری توجه داشته و دارای مشکلات پایایی (اعتماد پذیری) است و به همین دلیل توسعه دهندگان، فرآیند های حیاتی و مهم خودشان را با نقطه های تکیِ شکست (SPoF مخفف Single Points of Failure که قسمت هایی از سامانه هستند که در صورت شکست، تمام سامانه را از کار کردن نگه می دارند و برای قابلیت اطمینان طراحی می شوند) باقی می گذارند. با رویکرد بدون سرور، کار های دسته ای (batch jobs) می توانند به عنوان زنجیره ای از mapper ها (مخفف Maintain, Prepare, and Produce Executive Reports که یک دستگاه یا سیستم پردازش و مدیریت پایگاه داده است) و کاهنده (reducer) ها که هر کدام می توانند به عنوان تابع های مستقل اجرا بشوند، دوباره طراحی شوند. چنین mapper ها و کاهنده هایی، یک ذخیره ی داده ی (data store) مشترک مانند یک ذخیره سازی BLOB (مخفف Binary Large OBject که مجموعه ای از داده های دوتاییِ ذخیره شده به عنوان یک قسمتِ تکی در سیستم یا دستگاه مدیریت پایگاه داده است) را با یکدیگر به اشتراک گذاشته و می توانند به صورت جدا از هم تغییر مقیاس عمودی (scale up) داشته تا نیاز هایِ پردازش داده را به دست بیاورند.
۳- پردازش جریان یا رشته (Stream Processing): اُلگویِ پردازش جریان ها یا رشته های بزرگ داده ها برای پردازش نزدیکِ زمان واقعی (near-real-time) برای کارهایِ دسته ایِ مقیاس پذیر است. جریان (رشته) های خدمات مانند Kafka و Kinesis می توانند با تابع های بدون سرور که می توانند برای کاهش زمان بیکاری (تاخیر) و افزایش خروجی (عملکرد) سیستم، به صورت یکپارچه مقیاس دهی بشوند، پردازش شوند. این اُلگو می تواند با ظرافت کامل بار گذاری های سریع (تُند و تیز) را نیز مدیریت کند.
۴- پردازش رویداد محور/خودکار سازی (Automation/event-driven processing): شاید نخستین اپلیکیشن رایانشِ بدون سرور، خودکار سازی (اتوماسیون) بوده است. تابع ها می توانند برای واکنش به رویداد ها یا هُشدار های مشخص، نوشته شوند. همچنین این ها می توانند به طور دوره ای زمان بندی شده تا قابلیت های تامین کننده ی سرویس ابر را با توسعه پذیری، تقویت کنند.
آن دسته از اپلیکیشن هایی که بهترین ها برای زیر ساختار یا معماریِ بدون سرور هستند، شامل لایه ی پُشتی (back-end) های متحرک (موبایل)، سیستم های پردازش داده (زمان واقعی و دسته ای) و اپلیکیشن های وِب می باشند. به طور کُلی، معماری بدون سرور، برای هر سیستم توزیعی که به صورت پویا به رویداد ها یا حجم های کاریِ پردازش بر اساس تقاضا، واکنش نشان می دهد، مناسب هستند. برای نمونه، رایانش بدون سرور برای پردازش رویداد ها از دستگاه های IoT (مخفف Internet of Things به معنیِ اینترنت اشیاء، اینترنت چیز ها یا چیز نِت که به چیز هایی که در اطراف ما به شبکه ی اینترنت متصل هستند اشاره دارد)، پردازش مجموعه داده های بزرگ (در Big Data یا کلان داده ها) و سیستم های هوشمند که به پُرس و جو (query) ها پاسخ می دهند (مانند chatbot ها)، از هر نظر مناسبند.

 

 

 

فناوری های بدون سرور
پایگاه داده ها و فناوری های بدون سرور منبع باز کم و اختصاصیِ زیادی وجود دارند. شناخته شده (عمومی) ترین و جدید ترین فناوری بدون سرور، AWS Lambda است (که در انتهای سال ۲۰۱۴ معرفی و در ابتدای ۲۰۱۵ ارائه شد) و فناوری های دیگر هم به سرعت در حال ارائه شدن هستند. همچنین Azure Functions مایکروسافت پُشتیبانی خوبی برای محدوده ی گسترده ای از زبان های برنامه نویسی داشته و با خدمات Azure مایکروسافت نیز یکپارچه است. از طرفی، Cloud Functions گوگل هم در حال حاضر در بِتا قرار دارد. یکی از بازیگران کلیدیِ منبع باز در فناوری های بدون سرور، Apache OpenWhisk است که توسط IBM و Adobe پشتیبانی شده است. این فناوری، در بیشتر موارد برای توسعه ی مستقیم اپلیکیشن ها بر روی این پایگاه ها (AWS، Azure، Google و OpenWhisk)، خسته کننده است. چارچوب کاریِ بدون سرور، یک راه حلِ شناخته شده و پُر استفاده برای ساده سازیِ توسعه ی اپلیکیشن ها بر روی این پایگاه ها است.
بسیاری از راه حل ها (به خصوص راه حل های منبع باز) مانند Docker و Kubernetes بر روی جدا کردن جزئیات فناوری های حمل کننده (container) متمرکز شده اند. همچنین، Hyper.sh یک سرویس میزبانی از حمل کننده را تامین کرده که در آن شما می توانید به طور مستقیم از تصویر های Docker به سَبکِ (style) بدون سرور استفاده کنید. چارچوب های بدون سروری که تنها سازی (ایزوله کردن) بر روی Kubernetes را تامین می کنند، شامل Kubeless از Bitnami، Fission از Platform9 و funktion از Fabric8 می باشند.
با وجود این زیر ساختار بدون سرور به عنوان یک رویکرد جدید، فناوری ها همچنان در حال توسعه و بهتر شدن هستند پس انتظار داریم که در سال های آینده، چیز های بسیار زیادی در این زمینه ارائه شده و مورد استفاده قرار بگیرند.

 

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

* برطرف کردن اشکال یا اشکال زدایی (Debugging)
بر خلاف آن چه به طور معمول در توسعه ی اپلیکیشن می بینیم، هیچ مفهومی از یک محیط محلی (local environment) برای تابع های بدون سرور وجود ندارد. در مورد کار هایی مانند اشکال زدایی (debugging) های اساسی مانند برطرف کردن گام به گام اشکال ها، نقطه های شکست یا اشکال (breakpoint ها)، step-over و نقطه های مراقبت (watch point ها) نیز با وجود تابع های بدون سرور، در دسترس نیستند. در حال حاضر تنها باید از ثبت وقایع گسترده (extensive logging) و ابزار اشکال زدایی استفاده کنیم.
وقتی MovieBot یک واکنش متناقض نشان می دهد یا منظور کاربر را متوجه نمی شود، چگونه باید کُدی که از راه دور اجرا می شود را اشکال زدایی کنیم؟ در مورد چنین موقعیت هایی، باید اطلاعات و وقایع زیادی مانند امتیاز های NLP، واکنش های مکالمه (گفتگو)، نتایج پُرس و جوی پایگاه داده ی بلیط فیلم و غیره را ثبت کنیم. پس باید آن ها را به صورت غیر خودکار تجزیه و تحلیل کرده و بررسی کنیم که اشکال کار در کدام قسمت است. مشخص است که انجام این فرآیند، کار راحتی نیست.

 

* مدیریت موقعیت (State management)
اگر چه بدون سرور دارای یک ماهیت بدون وضعیت و موقعیت است اما اپلیکیشن های دنیای واقعی، همواره باید با موقعیت (state) روبرو شوند. هدایت یک مجموعه از تابع های بدون سرور، با وجود زمینه ی مشترکی (common context) که باید بین آن ها عبور داده شود، یک چالش جدی و اساسی به حساب می آید.
هر مکالمه ی ربات سخنگو، یک گفتگو را مشخص می کند. برای برنامه مهم است که تمام مکالمه را به طور کامل درک کند. برای نمونه، برای پس و جویی که در آن از MovieBot سوال می شود که یک فیلم در یک سینمای مشخص نمایش داده شده است، در صورت مثبت بودن پاسخ ربات سخنگو، سوال بعدی به احتمال فراوان در مورد موجود بودن یک یا چند بلیط است که اگر جواب MovieBot باز هم مثبت باشد، کاربر می تواند درخواست رزرو کردن بلیط (های) مورد نظرش را داشته باشد. برای این که این مکالمه به درستی انجام شود، MovieBot باید تمام مکالمه را که شامل نام فیلم، نام سینمایی که فیلم در آن نمایش داده می شود، نام شهر و تعداد بلیط ها را به خاطر داشته باشد. به خاطر داشتن تمام این مکالمه، نیاز به یک سری از فراخوان های تابع بدون موقعیت دارد. اگر چه لازم است که بر روی این موقعیت برای موفق بودن واکنش نهایی تاکید کنیم اما نگه داشتن این حالت ها در تابع های خارجی (external)، یک وظیفه ی خسته کننده است.

 

* وابستگی به فروشنده (Vendor lock-in)
درست است که درباره ی تابع های تنها (ایزوله) شده ای که به صورت مستقل اجرا می شوند صحبت کردیم اما در عمل وابستگی زیادی به SDK (مخفف software development kit، کیت توسعه ی نرم افزار که مجموعه توابع و کتابخانه‌ های ویرایش یا کامپایل شده ‌ای است که تولید کننده های نرم ‌افزار برای آسان کردن برنامه ‌نویسی برای محیط یا پایگاه مشخصی فراهم کرده و در اختیار برنامه ‌نویسان کاربردی قرار می ‌دهند) و خدمات تامین شده توسط پایگاه (platform) فناوری بدون سرور داریم. این موضوع با توجه به این که تغییر پایگاه از پایگاهِ جاری به یک پایگاه موازی یا مشابه دشوار است، می تواند وابستگی به فروشنده را ایجاد کند.
فرض کنیم MovieBot را با استفاده از Python بر روی پایگاه AWS Lambda پیاده سازی کرده ایم. اگر چه منطق هسته ی رُبات به عنوان تابع های Lambda نوشته شده اما باید از خدمات مرتبط دیگر از پایگاه AWS مانند AWS Lex (برای NLP)، درگاه AWS API، DynamoDB (برای پایداریِ داده ها) و مواردی دیگر برای ربات سخنگو و برای درست کار کردن استفاده کنیم. همچنین، شاید لازم باشد برای کُد رُبات از AWS SDK برای به کار گیریِ خدمات (مانند S3 یا DynamoDB) و آن چه با استفاده از boto3 نوشته شده است، استفاده کنید. به بیان دیگر، برای واقعی بودن (یا به واقعیت تبدیل کردن) رُبات، باید در کنار کُد تابع Lambda نوشته شده در Python، از خدمات بیشتری از پایگاه AWS استفاده کنید. به دلیل این که تغییر رُبات از یک پایگاه به پایگاهی دیگر، سخت و دشوار است، در نتیجه وابستگی به فروشنده، وجود دارد.

 

* چالش های دیگر (Other challenges)
هر کُد تابع بدون سرور، به طور کلی دارای وابستگی هایی به کتابخانه ی شخص سوم است. در زمان اجرای تابع بدون سرور، لازم است که بسته های وابستگیِ شخص سوم را نیز اجرا کنید که در نتیجه ی آن، اندازه ی بسته ی اجرا بیشتر می شود. از آن جایی که حمل کننده ها به عنوان لایه های زیرین برای اجرای تابع های بدون سرور استفاده می شوند، زیاد شدن اندازه ی بسته ی اجرا، زمان بیکاری (تاخیر) برای راه اندازی و اجرای تابع های بدون سرور را افزایش می دهد. همچنین، نگهداری از تمام بسته های وابسته، نسخه بندیِ آن ها و مواردی از این دست، یک چالش کاربردی دیگر است.
یک چالش دیگر، این است که در زبان هایی که در سطح گسترده ای مورد استفاده قرار می گیرند، از پایگاه های بدون سرور پشتیبانی نمی شود. برای نمونه، از ماه مِه سال ۲۰۱۷ میلادی، امکان نوشتن تابع ها در C#، Node.js (4.3 و ۶٫۱۰)، Python (2.7 و ۳٫۶) و Java 8 بر روی AWS Lambda فراهم شده است. اما درباره ی زبان های دیگر مانند Go، PHP، Ruby، Groovy، Rust یا زبان های دیگر، شرایط چگونه است؟ اگر چه راه حل هایی برای نوشتن تابع های بدون سرور در این زبان ها و البته اجرا کردنشان وجود دارد اما انجام آن ها بسیار سخت است. از آن جایی که فناوری های بدون سرور با توجه به پشتیبانی برای تعداد زیادی از زبان های برنامه نویسی در حال بهتر شدن هستند، چالش های این فناوری ها نیز با گذر زمان کم تر شده و در حال ناپدید شدن هستند.
رایانش بدون سرور در حال ایجاد راه حل های بدون فکر کردن یا نگرانی در مورد سرور ها است. فکر کردن به این که فقط لازم است کُد مورد نظرتان را در ابر قرار داده و آن را اجرا کنید، بسیار هیجان انگیز است! بدون سرور در حال تغییر بازی است چرا که دارد نگاه شما به چگونگیِ ترکیب شدن، نوشتن، اجرا شدن و مقیاس بندیِ اپلیکیشن ها را تغییر می دهد. اگر به دنبال چابُکیِ اساسی در ایجاد اپلیکیشن هایی با مقیاس پذیری بالا هستید و می خواهید همچنان از نظر هزینه، بهره وری لازم را داشته باشید، بدون سرور، همان چیزی است که به آن احتیاج دارید. تجارت ها در سراسر دنیا از مدت ها پیش در حال تامین راه حل هایی برای استفاده از فناوری های رایانش بدون سرور هستند. اپلیکیشن های بدون سرور دارای محدوده ی گسترده ای از ربات های سخنگو تا پردازش های جریان (رشته ی) زمان حقیقی از دستگاه های IoT می باشند. بنا بر این تردیدی وجود ندارد که تجارت ها باید به سمت استفاده از این فناوری حرکت کنند و تنها پرسشی که وجود دارد این است که هر کدام از آن ها چه زمانی تصمیم می گیرند تا خودشان را با رایانش بدون سرور تطبیق بدهند.

منابع
۱- فناوریِ رادار خودتان را بسازید، نوشته ی نیل فورد
http://nealford.com/memeagora/2013/05/28/build_your_own_technology_radar.html
۱- زیر ساختار های بدون سرور، نوشته ی مارتین فاولِر
https://martinfowler.com/articles/serverless.html
۳- هیاهو ها درباره ی بدون سرور برای چیست؟، نوشته ی سیمون واردلِی
http://blog.gardeviance.org/2016/11/why-fuss-about-serverless.html
۴- اُلگو های زیر ساختاریِ بدون سرور و بهترین نمونه های عملی، خدمات وب آمازون
https://www.youtube.com/watch?v=b7UMoc1iUYw

فناوری های بدون سرور
• AWS Lambda: https://aws.amazon.com/lambda/
• Azure Functions: https://functions.azure.com/
• Google Cloud Functions: https://cloud.google.com/functions/
• Apache OpenWhisk: https://github.com/openwhisk
• Serverless framework: https://github.com/serverless/serverless
• Fission: https://github.com/fission/fission
• Hyper.sh: https://github.com/hyperhq/
• Funktion: https://funktion.fabric8.io/
• Kubeless: http://kubeless.io/

نظر بدهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

It is main inner container footer text