خانه / DevOps / معماری های Serverless

معماری های Serverless

معماری های Serverless

مقدمه: دنیای نرم افزار اکنون در حال پشت سر گذاشتن یکی از دوره های رنسانس خود است. بطوریکه طی همین چند سال اخیر شاهد تغییرات اساسی در نحوه ی طراحی و معماری نرم افزار ها و تغییر مایندست قدیمی تر نسبت به توسعه سیستم؛ تغییرات قابل توجه در نحوه ی انتشار برنامه ها در محیط عملیاتی و… به عنوان گوشه ای از این تغییرات و دگرگونی های اساسی و جذاب بودیم. مایکروسرویس ها؛داکریسم و کانتینرتها برخی از  ترندهای جذاب این چند سال گذشته بودند. معماری های Serverless یکی از جدیدترین ترندها در دنیای نرم افزار است که رویکردهای و مدل های ذهنی سنتی نسبت به توسعه برنامه ها بخصوص در بخش back end اپلیکیشن ها را بسیار تحت تاثیر قرار داد. مجددا اما باید این داستان تلخ را  یادآوری کرد ؛ که عدم وجود تعریف روشن، واضح و مشخص از این اصطلاح منجر به برداشت های غلط و اشتباهی از این سبک معماری شده و البته اسم انتخاب شده برای این سبک معماری بسیار بر این برداشت های غلط کمک کرده است. مقالات و نوشته های بسیار زیادی در مورد Serverless نوشته شده و وجود دارد که یکی از مقالات جامع و البته بی طرفانه و بدون منافع تجاری رو Mike Roberts نوشته که در اون بصورت مفصل ضمن بیان جنبه های مختلف این سبک معماری در مورد برداشت های غلط آن نیز اطلاعات بسیار مفیدی ارائه داده و در نهایت به جنبه های مثبت و منفی و مزایا و معایب Serverless نیز بصورت تقریبا کاملی نگاه انداخته. متن اصلی مقاله توسط Martin Fowler در اینجا منتشر شده؛ که در ادامه برگرداندن فارسی این مقاله ارزشمند توسط بنده، آورده شده است. 

آقای Martin Fowler در مقاله اصلی ذیل بخش Translations لینکی به این برگدان فارسی نیز اضافه کرده اند.

 

————————————————————————————————-

معماری های Serverless اشاره به اپلیکشن هایی دارد که به سرویس های شخص ثالث (که به Backend as a Services یا “BaaS” معروف هستند) یا کدهای سفارشی که بر روی کانتینرهای کوتاه مدت(Function as a Service “FaaS”) که در حال حاضر معروفترین فروشنده هاست  AWS Lambdaمی باشد؛ اجرا می شوند بشدت وابسته هستند. با استفاده از این ایده ها؛ و با انتقال رفتارهای بیشتر به front end؛ معماری های Serverless نیاز سنتی به سیستم های سرور “همیشه روشن و فعال” پشت برنامه را حذف می کند. بسته به شرایط؛ چنین سیستم هایی می توانند به شدت هزینه های عملیاتی و پیچیدگی را با هزینه ی وابستگی های فروشنده و)همزمان(کمبودهای سرویس های  پشتیبانی کاهش دهند.

Serverless یک موضوع داغ در دنیای معماری نرم افزار است. ما قبلا کتابها؛ فریمورک های اپن سورس؛ تعداد زیادی محصول فروشنده؛ و حتی یک کنفرانس اختصاص داده شده به این موضوع را مشاهده کردیم. اما Serverless چیست و چرا بررسی آن مهم و ارزشمند است(یا نیست)؟ به کمک انتشار این مقاله امیدوارم کمی از این دست سوالات شما را پاسخ بدهم.

برای شروع ما به “چیستی” Serverless نگاه می کنیم که من تلاش می کنم تا جای ممکن نسبت به مزایا و معایب این رویکرد بی طرفانه باشم- به این موضوعات بعدا نگاه می کنیم.

—————————————–

Serverless چیست؟

شبیه بیشتر موضوعات داغ در نرم افزار دید روشن و واضحی از اینکه “Serverless” چیست وجود ندارد و خیلی به تعریف آن کمک نکرد و این اصطلاح با دو معنی کاملا متفاوت از دوناحیه جدا ولی همپوشان ارائه شده:

  1. Serverless اولین بار جهت توصیف برنامه هایی که کاملا یا به میزان زیادی به برنامه ها/سرویس هادر (“cloud”) جهت مدیریت حالت و منطق سمت سرور وابسته بودند استفاده شد. این برنامه ها غالبا شامل برنامه های”rich client” (به عنوان مثال برنامه های وب تک صفحه ای یا اپلیکیشن های موبایل) که از اکوسیستم گسترده ای از پایگاه های موجود در cloud(شبیه Parse و Firebase) سرویس های احراز هویت(از جمله Auth 0, AWS Cognito)و …استفاده می کند بودند. این سرویس قبلا به عنوان “(Mobile) Backend as a Service“ تعریف شدند. و من از “BaaS” به عنوان فرم کوتاه شده ی این عبارت در ادامه این مقاله استفاده می کنم.
  2. Serverless همچنین به معنی برنامه هایی است که مقداری از عملیات منطق سمت سرور توسط توسعه دهنده ی برنامه نوشته می شود اما بر خلاف معماری های سنتی؛ بر روی کانتینرهای محاسباتی بدون حالت که کاملا event-triggere و کوتاه مدت هستند (ممکن فقط برای یک فراخوانی بطول بیانجامد) و کاملا توسط شخص سوم (3rd party) مدیریت می شود؛ اجرا می شود. (از ThoughtWorks بخاطر تعریفش در نمودار رادار اخیر تشکر می کنم). یک روش برای فکر کردن در مورد این “Function as a Service/FaaS” است AWS Lambda. در حال حاضر یکی از متداولترین پیاده سازی های FaaS است؛ اما سایرین هم هستند. من از “FaaS” به عنوان شکل کوتاه شده این معنی Serverless در ادامه این مقاله استفاده می کنم.

از اونجایی که تعریف دوم جدیدتر است؛  و تفاوت قابل توجهی در مورد اینکه معمولا ما به چه صورت در مورد معماری سنتی فکر می کنیم دارد و باعث میزان زیادی اعتیاد اطراف Serverless شده؛ بیشتر در مورد نواحی دوم صحبت می کنم.

با این وجود این مفاهیم بهم مرتبط و همگرا هستند. یک مثال خوب Auth0 است-اونها ابتدا بصورت BaaS”Authentication as a Service”  شروع کردند, اما با Auth0 Webstack وارد فضای FaaS شدند.

علاوه بر این در بسیاری از موارد بهنگام توسعه یک برنامه”BaaS شکل”؛ بخصوص هنگام توسعه یک برنامه وب غنی در مقابل یک برنامه موبایل؛ شما همچنان نیاز به مقداری عملیات سمت سرور سفارشی دارید. توابع FaaS ؛ بخصوص اگه با برخی از سرویس های BaaS که در حال استفاده هستید یکپارچه باشند می تواند یک راه حل خوب برای این مورد باشد.  مثال هایی از این عملیات شامل اعتبار سنجی داده ها(مراقبت در مقابل کلاینت بد)و فرآیند های محاسبه-شدید(به عنوان مثال دستکاری ویدئو و تصاویر) می باشد.

ارائه چند مثال

برنامه های UI-driven

بیاید در مورد یک سیستم کلاینت-محور 3 لایه سنتی با منطق سمت سرور فکر کنیم. یک مثال خوب یک برنامه ی تجارت الکترونیک متداول هست(با جرات می توانم بگم یک فروشگاه حیوانات خانگی آنلاین؟)

بصورت متداول و سنتی معماری این سیستم چیزی شبیه به زیر خواهد شد, و اجازه دهید فرض کنیم که سمت سرور با جاوا پیاده سازی شده است، و سمت کلاینت با HTML/Javascript پیاده شده است:

 


با این معماری؛ کلاینت تا حدودی می تواند غیر هوشمند باشد؛ و بیشتر منطق سیستم-احراز هویت, ناوبری صفحات, جستجو کردن, تراکنش ها- توسط برنامه ی سرور پیاده سازی شده است.
با یک معماری Serverless این برنامه  بیشتر ممکن است چیزی شبیه تصویر زیر شود:

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

  1. ما منطق اعتبار سنجی را از برنامه ی اصلی حذف و آنرا با یک سرویس BaaS شخص ثالث جایگزین کردیم.
  2. به عنوان مثال دیگری از استفاده از BaaS، به کلاینت اجازه دادیم که به بخشی از دیتابیس ما دسترسی داشته باشد(برای لیست محصولات)؛ که بصورت کامل توسط شخص ثالث هاست شده است(به عنوان مثال AWS Dynamo.) ممکن است در این روش پروفایل امنیتی متفاوتی برای دسترسی کلاینت به دیتابیس نسبت به سایر منابع سرور که ممکن است انها هم دسترسی به سرور داشته باشند داشته باشیم.
  3. دو مورد بالا اشاره به یک نکته ی سوم مهمی دارد- برخی از منطق هایی که در سرور Pet Store بودند حالا در کلاینت هستند؛ به عنوان نمونه پیگیری عملیات Session های کاربر؛ درک ساختار UX برنامه)به عنوان مثال ناوبری صفحه(؛ خواندن از دیتابیس و ترجمه آن به یک ویو قابل استفاده و غیره. کلاینت به واقع در حال تبدیل شدن به یک برنامه ی تک صفحه ای است.
  4. برخی از عملیات مرتبط با UX را ممکن است بخواهیم در سمت سرور نگه داریم، به عنوان نمونه؛ اگر محاسبات آن سنگین باشد یا نیاز به دسترسی به میزان زیادی از داده داشته باشد. یک مثال در اینجا “جستجو” می باشد. برای ویژگی جستجو بجای داشتن یک سرور همیشه در حال اجرا می توانیم یک تابع FaaS که از طریق یک API Getaway(بعدا توضیح داده می شه) به درخواست های http پاسخ می دهد استفاده کنیم. همچنین می تونیم هم کلاینت و سهم سرور؛ که هر دوشون از یک دیتابیس یکسان برای داده های محصول اطلاعات را می خوانند ؛ رو نیز داشته باشیم.

از انجایی که سرور اصلی با جاوا پیاده سازی شده است؛ و AWS Lambda(یا ارائه دهندهFaaS در این نمونه) از توابع پیاده سازی شده در جاوا پشتیبانی می کنند؛ می توانیم کد جستجو را از سمت سرور Pet Store به تابع Pet Store Search بدون نیاز به نوشتن مجدد کامل؛ انتقال بدیم.

  1. در آخر ممکن است عملیات “خرید” را با تابع FaaS دیگری جایگزین کنیم و بجای پیاده سازی مجدد آن در سمت کلاینت؛ تصمیم بگیریم آنرا به دلایل امنیتی در سمت سرور نگه داریم. این مورد نیز توسط API Getaway ارائه شده است.

برنامه های Message-Driven

یک مثال متفاوت سرویس پردازش دیتا بک اند است. فرض کنید یک برنامه ی کاربر-محور که نیازمند پاسخ سریع  به درخواست هایUI دارد را می نویسید؛ اما همزمان میخواهید تمام فعالیت هایی که انجام می شود را نیز ثبت کنید.  اجازه دهید در مورد یک سیستم تبلیغاتی آنلاین فکر کنیم، هنگامی که کاربری بر روی لینکی کلیک می کند؛ می خواهید خیلی سریع کاربر را به مقصد تبلیغ هدایت کنید، اما همزمان می خواهید که این واقعیت که لینک کلیک شده است را نیز ثبت کنید تا بتوانید تبلیغ کننده را نیز شارژ کنید. (این مثال یک فرض نیست- تیم قبلی من در Intent Media اخیرا به این صورت طراحی مجدد شده است.)

بطور سنتی، معماری ممکن است به این شکل باشد.  “Ad Server” بصورت همزمان به کاربر پاسخ می دهد- در مورد تعاملات و فعل و انفعالات برای این برنامه نگران نمی باشیم- اما این  سرور همچنین یک message  به یک کانال که می تونه بصورت همزمان با یک برنامه “click processor” که دیتابیس را بروز رسانی می کند ارسال کند؛ به عنوان مثال جهت کاهش بودجه ی تبلیغ کننده.


در دنیای Serverless این مثال شبیه به شکل می باشد:


این یک تفاوت کوچک در معماری در مقایسه با مثال اول ما است. ما برنامه استفاده کننده با زمان طولانی را با تابع FaaS که با کانتکست event driven که توسط ارائه دهنده ارائه شده اجرا می شود را جایگزین کردیم. توجه کنید که ارائه دهنده هم Message Broker و هم محیط FaaS را مهیا کرده است-هر دو سیستم خیلی به یکدیگر وابسته هستند.

محیط FaaS با ایجاد چندین کپی از کد تابع ممکن است چندین کلیک را بصورت همزمان و موازی پردازش کند-بسته به اینکه به چه صورت فرآیند اصلی را نوشته باشیم این مورد ممکن است مفهوم جدیدی باشد که نیاز به بررسی آن را داشته باشیم.

جعبه گشایی  Functions as s Service

ما از ایده ی FaaS قبلا خیلی استفاده کردیم و  الان وقت آن است که بیشتر بررسی کنیم و ببینیم که این واژه واقعا به چه معنی است. برای اینکار اجازه دهید به توضیحات باز محصول Amazon”s Lambdaنگاه کنیم. من یکسری نشانه به آن اضافه کردم که بعدا آنها را باز خواهم کرد.

AWS Lambdaبدون ارائه یا مدیریت سرورها اجازه اجرای کد را می دهد. (1)…  با Lambda، شما می توانید بطور افقی برای هر نوع برنامه یا سرویس بک اند کد اجرا کنید(2)- تمام اینها با کمترین میزان مدیریت. فقط کد خود را آپلود کنید و Lambdaتمامی مواردی که برای اجرای کدها نیاز هست را کنترل می کند(3) و با دسترس پذیری بالا کد شما را مقیاس می کند(4). شما می توانید کد خود را بصورتی تنظیم کنید که با سایر سرویس های AWA بصورت اتوماتیک تریگر شود(5) یا اینکه بصورت مستقیم آن را از هر برنامه وب یا موبایل صدا بزنید(6).

  1. اساسا FaaS در مورد اجرای کد بک اند بدون مدیریت سیستم های سرور یا برنامه های سرورمون است. عبارت دوم-برنامه های سرور– یک تفاوت اساسی بهنگام مقایسه با سایر موضوعات داغ معماری مدرن شبیه کانتینرها و PaaS(Platform as a Service) می باشد.

اگر به مثال پردازش کلیک خود برگردیم؛ کاری که FaaS انجام می دهد جایگزینی فرآیند کلیک سمت سرور (احتمالا یک ماشین فیزیکی؛ اما مطمئنا یک برنامه مشخص است) با چیزی که نیاز به مهیا کردن سرور یا برنامه ای که همیشه در حال اجرا باشد است.

 

  1. پیشنهاد FaaS عدم نیاز به کد نویسی بر روی یک فریمورک خاص یا استفاده از لایبرری خاص است. توابع FaaS هنگامی که به زبان و محیط وارد می شوند برنامه های منظم هستند. به عنوان مثال توابع AWS Lambdaمی توانند بصورت “first class” در جاوا اسکریپت؛ پایتون و هر زبان JVM (Java, Clojure, Scala و غیره) پیاده سازی شوند. با این وجود توابع Lambdaشما می توانند هر فرآیند دیگری که درون artifact هایتان دیپلوی شده اند را نیز اجرا کنند؛ در نتیجه شما می توانید هر زبانی که بتواند به فرآیند یونیکس کامپایل شود را استفاده کنید(بعدا به Apex نگاه بیندازید). توابع FaaS دارای محدودیت معماری بسیار زیادی هستند؛ بخصوص هنگامی که به زمان اجرا و حالت وارد می شوند؛ و بعدا به این محدودیت ها خواهیم رسید.

اجازه دهید مثال پردازش کلیک خود را مجددا بررسی کنیم- تنها کدی که نیاز به تغییر هنگام رفتن به FaaS را دارد کد “main method/startup” است؛ که در آن حذف شده است؛ و احتمالا کدی که هندلر message ها سطح بالا است(پیاده سازی “message listener interface”)؛ اما این مورد ممکن است فقط تغییر در signature متد باشد. سایر بخش های کد( به عبارتی کدی که درون دیتابیس می نویسد) در دنیای FaaS هیچ تفاوتی ندارد.

  1. از آنجایی که ما هیچ برنامه ی سروری جهت دیپلوی نداریم؛ نسبت به سیستم های سنتی بسیار متفاوت می باشد- ما کد رو درون پروایدر FaaS آپلود می کنیم؛ و پروایدر تمام کارها را انجام می دهد. در حال حاضر عموما به معنی آپلود تغییرات جدید کد( به عنوان مثال درون یک فایل zip یا JAR)؛ و سپس فراخوانی یک API مناسب جهت شروع بروزرسانی می باشد.
  2. مقیاس پذیر کردن افقی کاملا اتوماتیک می باشد و توسط پروایدر مدیریت می شود. اگر سیستم شما نیاز به پردازش 100 درخواست بصورت همزمان داشته باشد؛ پروایدر بدون هیچ کانفیگ اضافه ای در بخش کد شما آن را کنترل می کند. “کانتینرهای محاسباتی” که کد شما رو اجرا می کنند با ارائه دهنده FaaS زودگذر (ephemeral) هست و بهنگام نیاز در زمان اجرا ارائه و تخریب (destroy) می شوند.

اجازه دهید به مثال پردازش کلیک خودمان برگردیم. فرض کنید ما یک روز خوب داشتیم و مشتریان بر روی هر تبلیغ بصورت معمول 10 بار کلیک کردند. آیا برنامه پردازش کلیک ما توانایی پاسخ گویی به این مقدار بار را دارد؟ به عنوان مثال آیا ما طوری کد زدیم که بتواند چندین پیام  را بصورت همزمان پردازش کند؟ حتی در صورتی که فقط یه instance از برنامه را در حال اجرا داشتیم آیا برای کنترل کردن این حجم از بار کافی بود؟ در صورتی که بتوانیم چندین فرآیند را همزمان اجرا کنیم؛ آیا مقیاس کردن بصورت اتوماتیک انجام می شود یا نیاز می باشد که مجدد آنرا بصورت دستی کانفیگ کنیم؟ با FaaS قبل از فرض موازی  شدن؛ نیاز است که شما توابع را بنویسید؛ اما هنگام موازی شدن پروایدر FaaS بصورت اتوماتیک تمام نیازهای مقیاس پذیر کردن را کنترل می کند.

  1. توابع در FaaS با انواع event هایی که توسط پروایدر تعریف شده اند تریگر می شوند. با Amazon AWS این محرک ها شامل بروزرسانی های S3(فایل)؛ زمان(تسک های زمان بندی شده)و پیام های اضافه شده به یک message bus(مثلا Kinesis) می باشد. تابع شما سپس باید پارامترهای لازم برای منبع event ای که به آن وابسته است را مهیا کند. در مثال پردازش کلیک ما این فرض که قبلا از message broker ای که از FaaS پشتیبانی می کند استفاده می کنیم؛ را بنا نهادیم. در غیر اینصورت نیاز داریم به یکی از آنها سوئیچ کنیم؛ و در اینصورت نیاز می باشد که در تولید کننده پیام(message producer) نیز تغییر ایجاد کنیم.
  2. بیشتر پروایدرها به توابع اجازه می دهند با پاسخ گویی به درخواست های http ورودی نیز ؛ عموما در برخی از انواع API getaway ها؛ تریگر شوند.(به عنوان مثال AWS API Getaway و Webstack). ما از این نوع در مثال Pet Stor برای توابع “خرید” و “جستجو” استفاده کردیم.

حالت

توابع FaaS وقتی که به حالت لوکال)محدوده ی ماشین/نمونه(instance)) وارد می شوند دارای محدودیت بسیار زیادی هستند. بصورت خلاصه شما باید فرض کنید که همه ی  فراخوانی های توابع که در فرآیند یا حالت هاست جاری که ایجاد کردید نیست ، باید برای تمام فراخوانی های بعدی آن تابع  نیز در دسترس باشد. این مورد شامل حالت در RAM و حالتی که ممکن است بر روی دیسک لوکال نوشته باشید می باشد. به عبارت دیگر از دیدگاه واحد-توسعه توابع FaaS بدون حالت هستند.

این مورد اگر نه تاثیر منحصر بفرد؛ اما یک تاثیر شگرف و زیاد بر روی معماری برنامه می باشد- مفهوم -Twelve-Factor App- دقیقا دارای همین محدودیت می باشد.

با توجه به این محدودیت ها چه راه های جایگزینی وجود دارد؟ بصورت معمول این  موضوع به این معنی است که توابع FaaS بصورت طبیعی بدون حالت هستند- به عبارت دیگر آنها تبدیل ورودی های خود به توابع خالص را ارائه می دهند- یا شاید آنها از دیتابیس؛ یک کش چند برنامه ای(مثل Redis)؛ یا دخیره فایل شبکه ای (مثل S3) برای ذخیره حالت میان درخواست ها یا برای ورودی های بعدی برای کنترل یک درخواست؛ استفاده کنند.

زمان اجرا

توابع FaaS عموما توسط اینکه هر فراخوانی چه مدت زمانی اجازه اجرا دارد محدود هستند. در حال حاظر توابع AWS Lambdaاجازه ندارند بیش از 5 دقیقه اجرا می باشد؛ و اگر بیشتر شود آنها پایان می پذیرند.

این بدین معنی است که کلاس های خاص تسک های طولانی مدت بدون معماری مجدد برای توابع FaaS مناسب نیستند؛ به عبارت دیگر ممکن است نیاز به چندین هماهنگ کننده ی متفاوت توابع FaaS در محیط های سنتی که ممکن است شما یک تسک زمان طولانی داشته باشید که هر دو کار اجرا و هماهنگی را انجام می دهد؛ داشته باشید.

تاخیر شروع کار

در حال حاضر مدت زمانی که طول می کشد تابع FaaS شما به یک درخواست پاسخ دهد به تعداد زیادی فاکتور بستگی دارد؛ و ممکن است بین 10 میلی ثانیه تا 2 دقیقه باشد. این ظاهرا بد است؛ اما اجازه دهید یک مثال مشخص؛ استفاده از AWS Lambdaبه عنوان مثال را بررسی کنیم.

اگر توابع شما با جاوا اسکریپت یا پایتون پیاده سازی شده باشد و زیاد بزرگ نباشند(به عبارتی کمتر از صدها خط کد) در نتیجه سربار اجرا نباید بیشتر از 10-100 میلی ثانیه باشد. توابع بزرگتر ممکن است گاها زمان بیشتری بطول بیانجامند.

اگر توابع Lambdaشما درون JVM پیاده شده باشند؛ زمان پاسخ طولانی تر ی ( به عبارتی بیش از 100 میلی ثانیه) در حالی که JVM بالا آمده باشد. مشاهده می کنید. با این وجود این اتفاق بطور قابل توجهی با سناریوهای زیر همراه است:

  • توابع شما به ندرت event ها را پردازش می کند؛ حدودا بیش از 10 دقیقه بین فراخوانی ها.
  • شما در ترافیک بسیار ناگهانی هستید؛ به عنوان مثال بصورت معمول 10 درخواست در ثانیه را پردازش می کنید؛ اما در کتر از 10 ثانیه این عدد به 100 درخواست در ثانیه می رسد.

مورد اولی از موارد بالا می تواند در مواقع خاص؛ با هر 5 دقیقه شبیه سازی کردن صدا زدن توابع خود جهت زنده نگه داشتن توابع از بین برود.

آیا این مسائل یک نگرانی هستند؟ بستگی به شیوه و نوع ترافیک برنامه شما دارد. تیم قبلی من یک app پردازش پیام Lambdaداشتند  که با جاوا نوشته شده بود و صدها میلیون پیام در روز را پردازش می کرد؛ و آنها نگرانی از بابت تاخیر شروع کار ندارند. باید گفت در صورتی که شما در حال نوشتن یک برنامه تجاری با تاخیر زمانی کم هستید صرفنظر از زبانی که برای پیاده سازی استفاده می کنید؛ ممکن در این زمان نخواهید از سیستم های FaaS استفاده کنید.

چه شما تصور کنید که app شما با مشکلات اینچنین مواجه می شوند یا خیر؛ باید حتما عملکرد را با بار شبیه محیط عملیاتی  تست کنید و ببینید چه عملکردی را مشاهده می کنید. اگر مورد استفاده شما الان کار نمی کند ممکن است بخواهید چند ماه دیگر امتحان کنید؛ چون این یک ناحیه بزرگ از توسعه توسط ارائه دهنده های FaaS می باشد.

API Getaway

یکی از جنبه های FaaS که قبلا به آن اشاره شد “API Getaway” بود.  API Getaway یک سرور HTTP است که در آن route/ endpointها درون فایل های کانفیگ تعریف می شوند و هر مسیر به یک تابع    FaaS  تخصیص داده می شود. وقتی که API Getaway یک در خواست را دریافت می کند پیکربندی مسیریابی مطابق با درخواست را پیدا می کند و سپس تابع FaaS مرتبط را صدا می زند. عموما API  Getaway نگاشت بین پارامترهای درخواست http و آرگومان های ورودی تابع FaaS را نیز انجام می دهد. API Getaway نتیجه صدا زدن تابع FaaS را به یک پاسخ http انجام داده و نتیجه را به صدا زننده ی اصلی بر می گرداند.

وب سرویس های Amazon دارای API Getaway مخصوص خود هستند و ارائه دهندگان دیگر نیز توانمندی های مشابهی را پیشنهاد می دهند.

ورای مسیریابی درخواست ها API Getaway ممکن است احراز هویت؛ اعتبار سنجی داده ها؛ نگاشت کد پاسخ(response code mapping) و غیره را نیز انجام دهد. اگر حس ششم شما که همیشه نسبت به خطرها همیشه فعال است درگیر این موضوع است که آیا این واقعا یک فکر خوب و مناسبی هست یا خیر؟ درگیر هست این فکرت رو نگه دار- ما این موارد را بعدا بررسی می کنیم.

یک استفاده  API Getaway + FaaS برای ایجاد کردن یک مایکروسرویس http-fronted بروش Serverless  بهمراه تمام مزیت هایی که همراه با توابع FaaS می آید شامل مقیاس پذیر کردن؛ مدیریت و سایر مزیت  ها است.

ابزار فعلی برای API Getaway ها نابالغ هستند و در نتیجه در حالیکه تعریف برنامه ها با API Getaway ها امکان پذیر می باشد؛ قطعا برای افراد غیر شجاع و محتاط نیست.

ابزار

توضیح بالا در مورد ابزار API Getaway که واقعا بی تجربه و نابالغ هستند ؛ در کل در مورد Serverless FaaS نیز بصورت عمومی وجود دارد. با این وجود استثناهایی نیز وجود دارد- یک مثال Auth0 Webstack  است که اولویت بسیار زیادی بر روی UX توسعه دهنده در ابزار خود قرار داده است. Tomsz Janckuz در کنفرانس Serverless اخیر این مورد را بخوبی نشان داده است.

اشکال زدایی و مانیتور کردن بصورت عمومی در برنامه های Serverless پیچیده است- در بخش های بعدی این مقاله به این موضوع خواهیم پرداخت.

اپن سورس

یکی از مزیت های برنامه های Serverless FaaS ارائه شفاف زمان production است و در نتیجه اپن سورس در حال حاضر شبیه به Docker و کانتینرها زیاد مرتبط با این دنیا نیست. در آینده ممکن است پیاده سازی پلت فرم های FaaS/API Getaway معروف رو ببینیم که بصورت “on premise” یا بر روی سیستم توسعه دهنده اجرا شوند. IBM OpenWhisk مثالی از این پیاده سازی است دیدن اینکه این مثال ؛ یا یک پیاده سازی های جایگزین یک پذیرش را بر می گزیند جالب است.

جدای از پیاده سازی زمان اجرا(Runtime) ابزارهای و فریمورک ها اپن سورس دیگری که در تعریف؛ انتشار و کمک در زمان اجراکمک کننده هستند از قبل وجود داشت. به عنوان نمونه Serverless Framework  استفاده از API Getaway + Lambdaرا بصورت چشم گیری نسبت به استفاده از اصول اولیه مهیا شده با AWS را آسان تر کرد. این فریمورک یک جاوا اسکریپت سنگین است اما اگر برنامه های JS API Getaway را می نویسید قطعا ارزش نگاه کردن را دارد.

مثال دیگر Apex -یک پروژه برای بیلد؛ دیپلوی و مدیریت توابع AWS Lambdaبصورت ساده” است. یکی از جنبه های بخصوص Apex این است که اجازه می دهد توابع Lambdaرا با سایر زبانهایی که مستقیما توسط Amazon پشتیبانی نمی شود از جمله Go بنویسید.

چه چیزی Serverless نیست؟

تا به اینجای مقاله من “Serverless” را به معنی مجموعه ای از چند ایده ی دیگر تعریف کردم- “Backend as a Service” و “Fucntion as a Service”. من همچنین وارد جزئیات مورد دوم شدم.

قبل از شروع به نگاه کردن به یکی از مهمترین بخش های مزیت ها و چالش ها ؛ می خواهم زمان بیشتری بر روی تعریف صرف کنم؛ یا اینکه تعریف کنم که چه چیزی Serverless نیست. من افرادی را مشاهده کردم(شامل خود من تا چند وقت پیش)که در مورد این موارد دچار سردرگمی بودند و فکر می کنم به جهت روشن تر کردن بحث پرداختن به آنها ارزشمند باشد.

مقایسه با  PaaS

با توجه به اینکه توابع FaaS بسیار شبیه به برنامه های 12-Factor هستند؛ آیا در حقیقت آنها تنها شکل دیگری از “Platform as a Service” (PaaS) از جمله Heroku نیستند؟ برای یک پاسخ مختصر من به تعریف Adrian Cockcroft اشاره می کنم

اگر PaaS شما بتواند بصورت موثری نمونه هایی را در 20 میلی ثانیه شروع کند که این نمونه ها بتوانند برای نیم ثانیه در حال اجرا باشند؛ می توان به انها Serverless گفت.  —Adrian Cockcroft

به عبارت دیگر بیشتر برنامه های PaaS برای بالا و پائین بردن کل برنامه ها به ازای هر درخواست نیستند؛ در حالیکه پلت فرم های FaaS دقیقا همین کار را می کنند.

اما اگر من یک توسعه دهنده خوب برنامه 12-Factor باشم چه تفاوتی در اینکه من چگونه کد می زنم وجود دارد؟ درست است؛ اما یک تفاوت بزرگ در اینکه به چه صورت برنامه خود را اجرا می کنید وجود دارد. از آنجایی که همه ی ما مهندسان خوب DevOps هستیم ما در مورد عملیات(operations) بسیار بیشتر از توسعه(development) فکر می کنیم؛ درست است؟

تفاوت کلیدی و اساسی عملیاتی میان FaaS و PaaS مقیاس پذیری است. به همراه بیشتر PaaS ها شما هنوز نیاز است که در مورد مقیاس کردن فکر کنید؛ به عنوان مثال, با Heroku چه تعداد Dynos را نیاز دارید که اجرا  کنید. با برنامه FaaS مقیاس پذیری کاملا شفاف می باشد. حتی در صورتی که شما برنامه PaaS خود را بصورتی برپا کرده باشید که بصورت اتوماتیک مقیاس شود نمی توانید این مورد را در سطح تک تک درخواست انجام دهید(مگر اینکه پروفایل ترافیک به شکل خیلی خاص داشته باشید), و بنابراین وقتی بحث هزینه در میان می باشد؛ برنامه های FaaS بسیار موثرتر هستند.

با وجود این مزیت؛ چرا باید هنوز از PaaS استفاده کنید؟ چندین دلیل وجود دارد؛ اما ابزارها و بالغ بودن API Getaway  ها ممکن است مهمترین آنها باشند. بعلاوه برنامه های 12-Factor پیاده سازی شده با PaaS ممکن است از یک کش فقط خواندنی درون برنامه برای بهبود عملکرد استفاده کند که در مورد توابع FaaS همچین انتخابی وجود ندارد.

مقایسه با کانتینرها

یکی از دلایل استفاده از Serverless FaaSها دوری از مجبور بودن به مدیریت فرآیند های رقابتی در سطح سیستم عامل یا سطح پایین تر است. انتخاب دیگر Plaftorm as a Service (از جمله Heroku) که در بالا توضیح داده شد که  PaaSها به چه صورت با Serverless FaaS ها متفاوت هستند, می باشد. یکی دیگر از انتزاع های فرآیندها کانتینرها؛ که Docker یکی از قابل روئت ترین نمونه های این تکنولوژی ها است می باشد. ما همچنین مشاهده کردیم که محبوبیت سیستم های هاستینگ کانتینر از جمله Mesos و Kubernetes که برنامه های مشخص را از سطح سیستم عامل انتزاع می کند؛ در حال افزایش است.  و حتی بیشتر از این, پلت فرم های کانتینر cloud-hosting شامل Amazon ECS و Google Container Engine  نیز وجود دارد, که همانند Serverless FaaS به تیم ها اجازه می دهد بطور کامل از مدیریت سیستم های سرور خود آزاد شوند. با توجه به این همه حرکت و جهش در حوزه ی کانتینرها آیا بررسی Serverless FaaS ها هنوز هم مفید است؟

اساسا بحثی که برای PaaS کردم در مورد کانتینرها هنوز صادق است- برای Serverless FaaS مقیاس پذیری ؛ شفاف و ریز دانه(fine grained)  است و بصورت اتوماتیک مدیریت می شود. پلت فرم های کانتینر هنوز چنین راه حلی را پیشنهاد نداده اند.

بعلاوه تکنولوژی های کانتینر با وجود اینکه در سال های اخیر بسیار محبوب شده اند ولی هنوز بالغ نشده اند. این بدین معنی نیست که Serverless FaaS ها بالغ هستند؛ اما انتخاب اینکه شما کدام لبه را دوست دارید هنوز بحث روز است.

با این وجود اعتراف می کنم که هر دوی این استدلال ها ممکن است در طول زمان ناپدید شوند. در حالی که مقیاس پذیری اتوماتیک بدون مدیریت صحیح در پلت فرم های کانتینر هنوز در سطح Serverless FaaS ها نیست؛ ما بخش هایی شامل “Horizontal Pod Autoscaling“ مربوط به Kubernetes را می بینیم که گرایش های زیادی به سمت آن وجود دارد. من می توانم  تصور کنم الگوهای تحلیلی هوشمند ترافیک زیادی به این ویژگی ها؛ و همچنین معیارهای بار-احتمالی لود معرفی می شوند. علاوه بر این سرعت رشد و بلوغ Kubernetes ممکن است منجر شود که یک پلت فرم پایدار؛ساده و بسیار عالی در مدت نه چندان طولانی بدهد.

اگر فاصله مدیریت و مقایس پذیر کردن میان Serverless FaaS و کانتیرنتهای هاست شده را کوچک ببینیم ممکن است انتخاب میان آنها فقط به سبک و نوع برنامه بستگی داشته باشد. به عنوان مثال ممکن است به نظر برسد که FaaS انتخاب بهتری برای سبک event driven با تعداد کمی event بر اساس کامپوننت های برنامه باشد؛ و کانتینرها گزینه ی بهتر و مناسب تری برای کامپوننت های synchronous-request با تعداد زیادی نقاط ورودی باشد.  در 5 سال انتظار دارم که بسیاری برنامه ها و تیم ها از هر دو سبک استفاده کنند و دیدن الگوهای استفاده از این پدیده می تواند جذاب باشد.

#NoOps

Serverless به معنی “No Ops” نیست. Serverless به معنی “No internal Sys Admin” بسته به اینکه خرگوش Serverless شما تا چه اندازه به گودال رفته است می باشد. در اینجا دو مورد مهم برای بررسی وجود دارد.

اولین آن “Ops” بسیار بیشتر از صرفا مدیریت سرور است. این عبارت حداقل به معنی مانیتورینگ؛ دیپلوی؛ امنیت؛ شبکه و همچنین مقداری اشکال زدایی محیط عملیاتی و مقیاس پذیر کردن سیستم می باشد.  این مشکلات همچنان با برنامه های Serverless وجود دارد و شما همچنان نیاز به استراتژی برای مواجه با آنها هستید. در برخی روش ها Ops سخت تر از دنیای Serverles است چون بسیاری از آنها بسیار تازه هستند.

دوم حتی Sys Admin ممکن است اتفاق بیافتد- وقتی آنرا با Serverless اوت سورس کردید. و این لزوما چیز بدی نیست-ما خیلی چیزها را اوت سورس کردیم. اما بسته به آن چیزی که شما دقیقا سعی در انجام آنرا دارید؛ این مورد می تواند یک چیز خوب یا بد باشد؛ و هر دوی این راه ها و انتخاب ها ممکن است در برخی نقاط انتزاع نشوند و باید بدانید که نیروهای انسانی Sys Adminها در برخی جاها برنامه ی شما را پشتیبانی می کنند.

Charity Majors  در کنفرانس اخیر Serverless یک تاک مفید در این باره داشت و توصیه می کنم هر وقت بصورت آنلاین در دسترس بود آن را چک کنید. تا آن موقع می توانید نوشته های او را از اینجا و اینجا بخوانید.

Stored Procedures as a Service

من نگران هستم که سرویس های Serverless به چیزی شبیه Stored Procedure ها؛ ایده ی خوبی که به سرعت به بدهی های فنی بزرگ بدل می شوند؛ تبدیل شوندCamille Fournier

موضوع دیگری که دیدم این بود که Serverless FaaS یعنی “Stored Procuderues as a Service” است. من فکر می کنم که این موضوع از این حقیقت ناشی می شود که بسیاری از مثال ها توابع FaaS(شامل برخی مثال هایی که در این مقاله نیز استفاده شد)بخش های کوچکی هستند که دسترسی به دیتابیس ها را پنهان می کند. در صورتی که همه مواردی که برای آنها FaaS استفاده کنیم به همین شکل باشد؛ فکر می کنم این اسم مفید می باشد اما در واقع این فقط بخشی از توانایی FaaS می باشد در نتیجه فکر کردن به این روش در مورد FaaS یک محدودیت غیر معتبر و غیر قابل قبول است.

باید گفت که بررسی اینکه آیا FaaS با برخی از مشکلات stored procuderues ؛ شامل برخی مشکلات تکنیکال که در توئیت رفرنس شده ی Camille اشاره شد،  همراه هست یا خیر مفید است. درسهای زیادی وجود دارد که از استفاده از store procs می آیند و در کانتکست FaaS ارزش مرور کردن دارند و ببینیم که آیا آنها اعمال می شوند. برخی از آنها که store procedures هستند:

  1. اغلب نیاز به زبان مخصوص فروشنده یا حداقل افزونه ها/فریمورک های مخصوص فروشنده به یک زبان
  2. تست کردن آنها مشکل است چون آنها نیاز به اجرا در کانتکست یک دیتابیس دارند
  3. کنترل ورژن/رفتار کردن به عنوان برنامه first class مشکل است

بخاطر داشته باشید تمام اینها ممکن است به تمام پیاده سازی های store procs اعمال نشود؛ اما آنها مطمئنا مشکلاتی هستند که من در زمان خودم با آنها مواجه بودم. اجازه دهید ببینیم اگر آنها باید به FaaS  اعمال شوند:

(1) تا جایی که تا الان دیدم مطمئنا یک نگرانی برای پیاده سازی های FaaS نیست؛ بنابراین می توانیم آن را از فهرست خارج کنیم.

برای (2) از آنجایی که با  تست واحد “just code”  سروکار داریم؛ طبیعتا به آسانی سایر کدها است. تست های جامعیت(ومشروع) یک موضوع دیگر است که بعدا آنرا بررسی می کنیم.

برای (3)؛ مجددا از آنجایی که توابع FaaS، “just code”  است، در نتیجه کنترل ورژن هم اوکی است. اما برای پکیچ کردن برنامه ها هنوز الگوهای بالغ وجود ندارد. فریمورک Serverless که قبلا اشاره کردم شکل های مخصوص به خود را ارائه می دهد؛ و AWS در کنفرانس اخیر Serverless در می 2016 اعلام کرد که آنها بر روی چیزی برای پکیچ کردن نیز کار می کنند(“Flourish”)؛ اما در حال حاضر این یک نگرانی مشروع دیگر است.

————————————————————-

مزیت ها

تا به اینجا بیشتر من سعی کردم فقط بپردازم به تعریف و توضیح اینکه معماری های Serverless چه چیزی هستند.  حالا تصمیم دارم در مورد برخی از مزیت ها و معایب این روش طراحی و انتشار برنامه ها بحث کنم.

مهم هست که بدانیم که برخی از این تکنولوژی ها بسیار جدید هستند.  AWS Lambda-یکی از پیشروهای پیاده سازی کننده ی FaaS- در زمان نگارش این مقاله بیش از 2 سال سن ندارد. به همین دلیل؛ ممکن است برخی از این مزیت ها دو سال بعد که به عقب بر می گردیم چیز های کم اهمیتی باشند؛ و در عوض برخی از معایب و مشکلاتی که اینجا ذکر می شوند خوشبختانه رفع شده باشند.

از آنجایی که Serverless یک مفهوم به تثبیت نرسیده است؛ در مقیاس بزرگ شما نباید به هیچ وجه بدون بررسی کامل و کافی تصمیم به استفاده از Serverless بگیرید. امیدوارم این لیست مزیت ها و معایب در گرفتن این تصمیم کمک کند.

ما تصمیم داریم در سرزمین رنگین کمان و تک شاخ ها(land of rainbows and unicorns ) شروع کنیم و به مزایای Serverless نگاهی بیاندازیم.

کاهش هزینه های عملیاتی

Serverless در ساده ترین حالت؛ یک راه حل برون سپاری است. Serverlss اجازه می دهد که کس دیگری را برای مدیریت سرورها؛ دیتابیس ها و حتی منطق برنامه که قبلا ممکن بود خود شما آنها را مدیریت کنید انتخاب کنید. از آنجایی که شما از سرویس های تعریف شده ای استفاده می کنید که خیلی افراد دیگر قبلا از آن استفاده کرده اند؛ ما یک تاثیر Economy of Scale را می بینیم- شما هزینه ی کمتری برای مدیریت دیتابیس خود می پردازید چون یک فروشنده صدها مورد از یک دیتابیس مشابه را اجرا می کند.

شما در مجموع با دو جنبه ی هزینه ی کاهش یافته مواجه هستید-هزینه های زیر ساخت و هزینه های افراد(عملیاتی/توسعه). در حالیکه برخی از دستاوردهای هزینه صرفا با اشتراک گذاری زیر ساخت(سخت افزار؛ شبکه)با سایر افراد بدست می آید؛ انتظار این است نسبت به توسعه برنامه و هاست توسط خودمان،  بیشتر اوقات زمان کمتری از وقت خود را(و بنابراین کاهش هزینه های عملیاتی) با برون سپاری سیستم Serverless صرف کنیم.

این مزیت؛ با این وجود؛ نسبت به چیزی که با Infrastrcture as a Code(IaaS) یا Platform as a Service(PaaS) بدست می آورید چندان متفاوت نیست. اما می توانیم این مزیت را به دو روش کلیدی گسترش بدهیم؛ یکی برای هر کدام از Serverless BaaS و Serverles FaaS.

BaaSکاهش هزینه ی توسعه

IaaS و PaaS هر دو بر اساس این فرضیه که مدیریت سیستم عامل و سرور می توانند بسته بندی شوند هستند.  Serverless Backend as a Service از طرف دیگر نتیجه ای از کالا بندی کردن همه ی کامپوننت های برنامه است.

اعتبار سنجی یک مثال خوب است. بیشتر برنامه ها عملیات احراز هویت خود را که غالبا شامل ویژگی های ثبت نام؛ ورود؛ مدیریت رمز عبور؛ یکپارچگی با سایر پروایدرهای اعتبار سنجی و غیره کد نویسی می کنند. در کل این منطق در بین بسیاری از برنامه های متداول و مشابه است؛  و در نتیجه سرویس هایی مثل Auth0 ایجاد شده اند تا به ما امکان دهند که با عملیات اعتبار سنجی آماده را بدون اینکه مجبور باشیم آنرا خودمان توسعه دهیم یکپارچه شویم.

در طرف مقابل دیتابیس های BaaS شبیه سرویس دیتابیس Firebase است. برخی تیم های توسعه برنامه های موبایل دریافتند که داشتن کلاینتی که مستقیما با دیتابیس سمت سرور ارتباط داشته باشد؛  می تواند مفید باشد. یک دیتابیس BaaS بسیاری از سربارهای مدیریت دیتابیس را از بین می برد؛ بعلاوه اینکه عموما مکانیزمی نیز آماده می کند جهت اعتبار سنجی مناسب و متناسب برای انواع متفاوت کاربران با الگوهای مورد انتظار برنامه های  Serverless.

بسته به نوع زمینه شما؛ ممکن است هر دوی این ایده ها را بدرخشید(بنا بر دلایلی که در بخش معایب آنها را ارائه می دهیم – نگران نباشید!) اما انکاری در مورد تعداد شرکت های موفق که قادر به تولید محصولات محتاطانه با سختی کدهای سمت سرور خود بودند نیست. Joe Emison چند نمونه از این مثال ها را در کنفرانس Serverless اخیر ارائه داد.

FaaSهزینه های مقیاس پذیری

یکی از شادی های Serverless FaaS همانطور که قبلا هم در این مقاله ذکر کردم؛ این می باشد:”مقیاس پذیری افقی کاملا اتوماتیک؛ روشن و مدیریت شده توسط پروایدر می باشد”. چندین مزیت در این مورد است اما در مورد زیرساخت  های اولیه بزرگترین مزیت این است که شما فقط برای میزان محاسبات و اندازه گیری که نیاز دارید هزینه می پردازید؛ در مثال AWS Lambdaبه محدود ی 100 میلی ثانیه می باشد. بسته به مقیاس و شکل ترافیک شما؛ این مورد می تواند یک برد اقتصادی بزرگ برای شما باشد.

مثالدرخواست های گاه به گاه

به عنوان مثال فرض کنید شما یک برنامه سرور را اجرا کردید که فقط یک درخواست در هر دقیقه را پردازش می کند؛ که 50 میلی ثانیه برای پردازش هر درخواست زمان می برد و میزان استفاده از CPU در هر ساعت 0.1% است. از یک دیدگاه این بسیار غیر موثر است- اگر 1000 برنامه ی دیگر بتوانند CPU شما را به اشتراک بگذرند شما می توانید کار خود رو در یک ماشین مشابه انجام دهید.

Serverless FaaS فاقد این ناکارآمدی است؛ و در کاهش هزینه به شما کمک می کند. در این سناریو شما فقط برای 100 میلی ثانیه محاسبه در هر دقیقه را پرداخت می کنید؛ که 15% زمان کلی است.

این مورد باعث مزیت های زیادی می شود:

  • برای مایکروسرویس ها که نیاز به بار کمی دارند شکستن کامپوننت ها بر اساس منطق/دامنه را نیز پشتیبانی می کند حتی اگر هزینه های عملیاتی این خوشه بندی ممکن باشد که گران باشد.
  • این مزیت های هزینه ای یک دمکراتیزه کردن مناسب، است. همانطور که شرکت ها و تیم ها بخواهند چیز جدیدی را آزمایش کنند آنها مطمئنا هزینه های عملیاتی بسیار کمی با “انداختن عروسک خود در آب” هنگامی که از FaaS برای نیازهای محاسباتی خود استفاده می کنند می پردازند. در حقیقت اگر بار کلی شما کاملا کوچک باشد(اما نه کاملا نامناسب) ممکن است مجبور نباشید برای هر محاسباتی در به دلیل “رفاه آزاد(free tier)” ارائه شده توسط برخی از ارائه دهنده های FaaS هزینه بپردازید.

مثال- ترافیک غیر پایدار

اجازه دهید نگاهی به مثال دیگری بیاندازیم. فرض کنید پروفایل ترافیک شما خیلی “spikey” است- شاید ترافیک پایه شما 20 درخواست در ثانیه باشد؛ اما در هر 5 دقیقه به مدت 10 ثانیه 200 درخواست در ثانیه(بصورت معمول 10 بار) را دریافت کنید. همچنین فرض کنید بخاطر این مثال؛ حداکثر عملکرد پایه ترافیک سرور را بیشینه می کند؛ و شما نمی خواهید در حین اوج ترافیک زمان پاسختان کاهش یابد. به چه صورت این مورد را حل می کنید؟
در یک محیط سنتی شما ممکن است نیاز داشته باشید که مجموع توانایی سخت افزار خود را با مضرب 10 برای کنترل کردن زمان اوج افزایش دهید؛ حتی اگر این میزان فقط برای کمتر از 4% کل زمان ماشین باشد. مقیاس پذیری اتوماتیک احتمالا به این دلیل که نمونه های سرور جدید چه میزان طول می کشد تا بالا بیایند؛ گزینه مناسب نباشد-با گذشت زمان نمونه های جدیدتان در مرحله اوج بوت می شوند.

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

مشخصا من بصورت عمد مثال های انتخاب کردم که در آنها Serverless FaaS صرفه جویی هزینه ای زیادی به شما می دهد، اما نکنه نشان دادن این مورد است که مگر در صورتیکه شما درای یک شکل ترافیکی بسیار پایدار باشید که بصورت مداوم از تمام سیستم های سرور استفاده می کند می توانید با استفاده از FaaS صرفه جویی زیادی از نقطه نظر هزینه کنید.

یک هشدار در مورد مطلب بالا-اگر ترافیک یکدست باشد و بصورت مداوم استفاده ی خوبی از یک سرور در حال اجرا کنید؛ ممکن این مزایای هزینه ای برای شما زیاد قابل مشاهده نباشد و در واقع با استفاده FaaS ممکن است هزینه ی بیشتری صرف و خرج شود. شما باید هزینه های پروایدرهای فعلی در مقایسه با تجهیزات سروهایی که تمام وقت در حال اجرا هستند را باهم مقایسه کنید و ببینید که هزینه ی کدام یک قابل پذیرش تر است.

ریشه برخی از صرفه جویی ها در هزینه؛ بهینه سازی است

یک جنبه ی جذاب دیگر در مورد هزینه های FaaS وجود دارد- هر بهینه سازی عملکرد که شما در کد خود ایجاد می کنید نه تنها سرعت برنامه شما را بالا می برد؛ بلکه ممکن است ارتباط مستقیم و یکباره ای با کاهش هزینه های عملیاتی با توجه به جزئیات طرح شارژ ارائه دهندگان شما؛ داشته باشد.  به عنوان مثال اگر هر کدام از افراد عملیاتی شما بصورت متداول 1 ثانیه برای اجرا زمان بگیرند و شما آنرا به 200 میلی ثانیه کاهش دهید به یکباره 80% صرفه جویی در هزینه های محاسباتی بدون هرگونه تغییر زیر ساخت را مشاهده می کنید.

مدیریت عملیات ساده تر

این قسمت با یک ستاره بزرگ همراه است- برخی از جنبه های عملیاتی هنوز برای Serverless زمخت و سخت هستند؛ اما در حال حاضر ما با دوستان جدید رنگین کمان خود چسبیده ایم…

در بخش  Serverless BaaS اینکه چرامدیریت عملیاتی نسبت به سایر معماری ها ساده است بسیار مشخص و واضح است: تعداد کامپوننت های کم که باید پشتیبانی کنید برابر است با میزان کار کم.

در قسمت FaaS چند جنبه در بازی وجود دارد؛ و من می خواهم برخی از آنها را با جزئیات بیشتری بپردازم.

مزیت های مقیاس پذیری FaaS بدور از هزینه

در حالیکه مقیاس پذیری در ذهن ما از بخش قبلی تازه است؛ ارزشمند است که اشاره کنیم که مقیاس پذیری عملیات FaaS نه تنها هزینه محاسباتی را کاهش می دهد؛ بلکه همچنین هزینه ی مدیریت عملیاتی را به دلیل اینکه مقیاس پذیری بصورت اتواماتیک انجام می شود کاهش می دهد.

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

حتی در موردی که شما از “مقیاس پذیری اتوماتیک” در معماری غیر FaaS خود استفاده می کنید؛ اما هنوز شما نیاز به بالا آوردن و نگه داری(سرورها) دارید- این موارد با FaaS اصلا نیازی نیست.

بطور مشابه از آنجایی که مقیاس پذیری در هر درخواست/رویداد توسط پروایدر انجام می شود؛ قبل از اینکه با کمبود حافظه یا خطای های بیش از حد عملکردی برخورد کنید شما دیگه حتی نیازی به اینکه در مورد این سوال که چه تعداد درخواست های موازی را می توانید کنترل کنید ندارید؛ حداقل با کامپوننت های که توسط FaaS هاست شده اند این نیاز وجود ندارد. پایگاه داده های پایین دست و کامپوننت های غیر FaaS باید در حالت افزایش بیش از حد بار آنها؛ مجدد بازبینی شود.

پیچیدگی کاهش یافته ی پکیچ سازی  و انتشار

در حالیکه API Getawayها در حال حاضر ساده نیستند؛ در مقایسه با دیپلوی کل سرور فرآیند بسته بندی و انتشار یک تابع FaaS به مراتب ساده و سر راست است. تمام مواردی که شما نیاز دارید کامپایل کردن و سپس zip/jar کردن کدتان و بعد از اون آپلود کردن این فایل ها است. نه puppet/chef؛ نه اسکریپت شل start/stop؛ نه تصمیمی درباره اینکه انتشار یک یا تعدادی از کانتینرهای روی یک ماشین به چه صورت استف هیچکدام وجود ندارد. اگر شما تازه شروع کرده باشید؛ حتی نیازی به پکیچ کردن هیچ چیزی ندارید-شما حتی ممکن است کد خود رو بر روی کنسول ارائه دهنده نیز بنویسید(این مورد؛ قطعا برای کد عملیاتی پیشنهاد نمی شود!)

توضیح این زمان زیادی نمی برد اما در برخی تیم ها این مزیت ها ممکن است کاملا بزرگ باشد- یک راه حل کامل Serverless به هیچ مدیریت سیستم(zero system administration) نیاز ندارد.

راه حل های Platfrorm-as-a-Service(PaaS) دارای مزیت های دیپلوی مشابهی هستند اما بهنگام مقایسه PaaS با FaaS دیدیم که مزیت های مقایس پذیر کردن منحصر به FaaS است.

زمان بازار/امتحان

“مدیریت ساده تر عملیات” مزیتی است که ما به عنوان مهندس متوجه شدیم؛ اما برای بیزینس ما این مورد چه معنی ای می دهد؟

مورد مشخص هزینه است: زمان کم در عملیات=افراد کم مورد نیاز برای عملیات. اما مهمترین مورد از نظر من “زمان بازار“ است. همانطور که تیم ها و محصولات ما با فرآیندهای چابک و لن خو گرفتند ما می خواهیم که بطور مداوم چیزهای جدید را امتحان کنیم و به سرعت سیستم های فعلی را بروز رسانی کنیم. در حالیکه انتشار مجدد ساده؛ اجازه تکرارهای ساده پروژه های ساده ره بصورت سریع می دهند؛ داشتن ایده ی جدید برای شروع انتشار خوب به ما اجازه می دهد که تجربه های جدید را با اصطکاک و کمترین هزینه آزمایش کنیم.

داستان ایده-جدید-برای-شروع-انتشار برای FaaS در برخی موارد عالی هستند؛ بخصوص برای توابع ساده که با event های بالغ-تعریف شده که در اکوسیستم ارائه دهنده تریگر می شوند. به عنوان مثال فرض کنید سازمان شما از AWS Kinesis استفاده می کند، یک سیستم مسیجینگ شبیه کفکا، برای برودکست کردن انواع مختلفی از event های run time در میان زیرساخت های شما. با AWS Lambda می توانید یک event listener جدید را با استریم Kinesis در چند دقیقه توسعه و دیپلوی کنید-می توانید چندین تجربه ی مختلف و متفاوت را در یک روز امتحان کنید!

برای API های مبتنی بر وب بصورت مشابه در اکثر موارد هنور نمی توان کاملا گفت اما تعدادی پروژه ی اوپن سورس و پیاده سازی کوچک تر منتهی به راه حل می شوند. ما این مورد را بعد بررسی می کنیم.

محاسبات “سبزتر”؟

در دو دهه اخیر در تعداد دیتا سنترها و مصرف انرژی مرتبط با آنها به همراه سایر منابع فیزیکی مورد نیاز برای ایجاد سرورهای زیاد؛ سوئیچ  های شبکه و …ما شاهد یک انفجار بودیم. Apple، Google و موارد مشابه در مورد میزبانی برخی مراکز داده نزدیک منابع انرژی تجدید پذیر جهت کاهش مصرف سوخت های فصیلی در چنین سایت هایی صحبت کرده اند.

بخشی از دلایل برای این افزایش بیش از حد مصرف انرژی؛ تعداد سرورهایی است که بیکار هستند ولی با این وجود روشن هستند.

سرورهای معمولی  در دیتا سنترهای سازمانی و تجاری بین 5 تا 15  درصد از حداکثر توان محاسباتی خود را بطور میانگین در سال انتقال می دهند.

Forbes

این مورد به شدت ناکارآمد است و بر روی محیط زیست تاثیر بسیار زیادی دارد.

از یک سو این احتمال وجود دارد که زیر ساخت ها به این دلیل که شرکت ها می توانند بجای اینکه تمام سرورهای احتمالی ضروری را به مدت طولانی بصورت پیشرفته ارائه دهند؛ در صورت نیاز و بر اساس تقاضا سرورهای بیشتری “بخرند” کمک کرده باشد. با این وجود می توان ادعا کرد که سهولت در ارائه سرورها می تواند موقعیت را حتی بدتر کند اگر تعداد زیادی از این سرورها بدون مدیریت ظرفیت مناسب(adequate capacity management) به سر برند.

چه ما از راه حل self-hosted استفاده کنیم چه از زیرساخت IaaS یا  PaaSاستفاده کنیم هنوز در تصمیم های ظرفیت در مورد برنامه هایمان که ممکن است ماه ها یا سال ها گذشته باشد را خودمان می گیریم. معمولا ما محتاط هستیم و در نتیجه در مورد مدیریت ظرفیت و ارائه بیش از حد منجر به تصمیمات نادرستی که در بالا تشریح شد می شود. با رویکرد Serverless دیگه نیازی نیست که خودمان این تصمیمات ظرفیت را بگیریم – ما به فروشنده Serverless اجازه می دهیم که فقط به اندازه ی کافی برای نیازهای محاسباتی ما در زمان واقعی ارائه دهد. فروشنده در نتیجه می تواند بر اساس مجموع مشتریهایش تصمیمات ظرفیت را بگیرد.

این تغییر باید منجر به استفاده کارآمدتر از منابع ما در بین دیتا سنترها شود و بهمین دلیل نسبت به رویکردهای مدیریت ظرفیت سنتی تاثیرات محیطی را کاهش می دهد.

————————————-

مشکلات

خوب؛ خواننده ی عزیز؛ امیدوارم از زمان خود در سرزمین رنگین کمان و تک شاخ  ها لذت برده باشید؛ چون داریم وارد بخش بد می شویم همانطور که ما از ماهی مرطوب از واقعیت در اطراف چهره می بینیم.

چیز زیادی در مورد معماری های Serverless وجود دارد و در صورتی که فکر نمی کردم که نویدهایی زیادی در مورد آنها وجود دارد؛ وقت زیادی را برای نوشتن در مورد انها صرف نمی کردم، البه این نوید ها و امیدها با سبک و سنگین کردن زیاد همراه هستند. برخی از اینها با مفهوم ها اقتباص می شوند – آنها نمی توانند بطور کامل با پیشرفت (و گذر زمان) ثابت شوند و همیشه باید مورد توجه قرار گیرند. سایر موارد به پیاده سازی فعلی نزدیک می شوند و با گذشت زمان می توان انتظار داشت که مرتفع شوند.

معایب ذاتی

کنترل ارائه دهنده

با هر استراتژی اوت سورسی شما ممکن است کنترل قسمت هایی از سیستم را به فروشنده شخص ثالث بدهید. این عدم کنترل ممکن است با آشکارایی خاموش بودن سیستم؛ محدودیت های غیر قابل انتظار؛ تغییرات هزینه؛ از دست دادن عملکرد؛ بروز رسانیهای API فورس شده و موارد بیشتر باشد. Charity Majors که قبلا به وی اشاره داشتم؛ این مورد را با جزئیات بیشتر در بخش Tradeoffs از این مقاله توضیح داده:

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

Charity Majors

مشکلات چند مستاجری(Multitenancy)

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

این مشکلات البته مختص به سیستم های Serverless نیست- این مشکلات در بسیاری سرویس ها دیگر که استفاده از چند مستاجری را پیشنهاد می کنند نیز وجود دارد – اما از آنجایی که بسیاری از سیستم های Serverless جدید هستند؛ انتظار می رود که در حال حاضر نسبت به زمانی که این سیستم ها به بلوغ برسند مشکلات بیشتری را شاهد باشیم.

انحصار فروشنده

اینجا مشکلات مرتبط با فروشندگان Serverless می آید- انحصار. احتمال اینکه ویژگی های Serverless که در حال استفاده از آن از یک فروشنده هستید نسبت به فروشنده دیگر بصورت متفاوت تری پیاده سازی شده باشد زیاد است. در صورتی که بخواهید فروشنده را عوض کنید تقریبا قطعا نیاز دارید که ابزارهای عملیاتی(دیپلوی؛ مانیتورینگ و …) را بروزرسانی کنید؛ و همچنین احتمالا نیاز داشته باشید که کد خودتان را نیز تغییر دهید(به عنوان مثال جهت اینکه FaaS interface متفاوت تری را پیاده سازی کنید)، و در صورتی که نحوه ی محاسبه فروشندگان رفتار پیاده سازی متفاوتی داشته باشید حتی نیازمند این هستید که طراحی یا معماری خود را نیز تغییر دهید.

حتی در صورتی که این را مدیریت کرده باشید که بتوانید اینکار را برای بخشی از اکوسیستم خود انجام دهید؛ ممکن است توسط کامپوننت معماری دیگری دستتان بسته شود. به عنوان نمونه فرض کنید در حال استفاده از AWS Lambdaجهت پاسخگویی به event هایی که روی مسیج باس AWS Kinesis می باشد هستید تفاوت بین AWS Lambda، Google Cloud Functions و Microsoft Azure Functions تقریبا کوچک باشد؛ اما با این وجود در صورتی که بخواهید از پیاده سازی های فروشندگان دو مورد آخری مستقیما به استریم های AWS Kinesis بروید نمی توانید اینکار را انجام دهید. این بدین معنی است که انتقال یا بردن؛ کد شما از یک راه حل به دیگری بدون تغییر بقیه بخش های زیر ساخت نیز؛ امکان پذیر نخواهد بود.

و در آخر حتی در صورتی که روشی را ایجاد کنید که سیستم خود را با توانایی های فروشنده ی دیگر مجدد پیاده سازی کنید؛ باز هم نیازمند فرآیند مهاجرت بسته به چیزی که فروشنده به شما پیشنهاد می دهد هستید. به عنوان مثال اگر در حال تغییر از یک دیتابیس BaaS به دیگری هستید؛ آیا ویژگهای خروجی گرفتن و ورودی(export و import) BaaS اصلی با چیزی که شما می خواهید یکی است؟

یک احتمال مهاجرت به برخی از این cloud ها ایجاد یک انتزاع عمومی در حال رشد(emerging) بر روی چندین فروشنده Serverless است و این مورد را بعدا توضیح خواهیم داد.

نگرانی های امنیتی

این مورد واقعا نیازمند یک مقاله درخور و مناسب برای خودش است؛ اما استفاده از یک رویکرد Serverless شما را به سوال های امنیتی بسیاری می کشاند. دوتا از این سوالات در زیر آمده اند؛ اما سوالات بسیار دیگری نیز هستند که باید آنها را بررسی کنید.

  • هر فروشنده ی Serverless که از آن استفاده می کنید تعداد پیاده سازی های امنیتی متفاوتی که اکوسیستم شما از آن استفاده می کند را افزایش می دهد. این مورد باعث افزایش سطح ناحیه شما برای اهداف مخرب و احتمال حمله موفقیت آمیز را افزایش می دهد.
  • اگر مستقیما از یک دیتابیس BaaS از پلت فرم های موبایل استفاده می کنید شما در حال از دست دادن محافظت های امنیتی که در برنامه های سنتی فراهم می شد هستید. در حالیکه این مورد عامل برهم زدن استفاده از این راه حل ها نیست ولی نیازمند توجه بیشتر در طراحی و توسعه برنامه هایتان می باشد.

تکرار منطق در بین پلت فرم های کلاینت

با یک معماری “کاملا BaaS” هیچ منطق سفارشی در سمت سرور نوشته نمی شود – تمام اینها در سمت کلاینت هستند. این مورد ممکن است برای اولین پلت فرم کلاینت شما مناسب باشد اما به محض اینکه نیازمند پلت فرم کلاینت دوم خود شدید و نتیجه نیاز پیدا می کنید که پیاده سازی بخشی از منطق خود را مجدد پیاده سازی کنید؛ کاری که در معماری های سنتی تر قبلا نیاز نداشتید انجام بدهید. به عنوان مثالی؛ اگر از یک دیتابیس BaaS استفاده می کنید در این نوع از اکوسیستم تمام اپلیکشنهای موبایل شما(احتمالا وب؛ native iOS و native Android) مجددا نیاز دارند که با دیتابیس فروشنده ارتباط برقرار کنند؛ و در نتیجه نیاز دارند که متوجه شوند که به چه صورت شمای دیتابیس را به منطق برنامه نگاشت کنند.

علاوه بر این در صورتی که در هر نقطه بخواهید به دیتابیس جدیدی مهاجرت کنید نیاز دارید آن تغییرات کد/هماهنگی را بین تمام کلاینت های متفاوت تکرار کنید.

از دست دادن بهینه سازی سرور

مجددا با یک معماری “کاملا BaaS” موقعیت و شرایطی برای بهینه سازی طراحی سرور جهت عملکرد و کارایی کلاینت وجود ندارد. الگوی “Backend For Frontend” جهت انتزاع کردن بعضی از جنبه های خاص از کل سیستم در سرور بوجود آمد؛ که تا حدودی باعث می شود کلاینت بتواند عملیات را خیلی سریعتر انجام دهد و در مورد اپلیکشن های موبایل از توان باتری کمتری استفاده کند. چنین الگویی برای “BaaS کامل” وجود ندارد.

این مورد را به این صورت شفاف می کنم که مشکل بالا و مشکل قبلی هر دو برای معماری های “BaaS کامل” که تمام منطق در کلاینت است و تنها سرویس بک اند توسط فروشنده ارائه شده؛ وجود دارد. یک راه کاهش هر دوی این موارد مطمئنا استفاده از FaaS یا برخی از انواع الگوی سمت سرور سبک وزن جهت انتقال منطق های خاص به سرور است.

برای Serverless FaaS هیچ حالت در سروری وجود ندارد – No in-server state for Serverless

بعد از برشمردن تعدادی از مشکلات BaaS اجازه دهید برای دقایقی در مورد FaaS صحبت کنیم. جلوتر گفتم:

توابع FaaS وقتی که به حالت لوکال)محدوده ی ماشین/نمونه(instance)) وارد می شوند دارای محدودیت بسیار زیادی هستند. بصورت خلاصه شما باید فرض کنید که همه ی  فراخوانی های توابع که در فرآیند یا حالت هاست جاری که ایجاد کردید نیست ، باید برای تمام فراخوانی های بعدی آن تابع  نیز در دسترس باشد.

همچنین گفتم که یک راه حل جایگزین برای این مورد دنبال کردن عامل شماره 6 از “Twelve Factor App” که این محدودیت زیاد را در بر می گیرد می باشد:

فرآیندهای Twelve-factor بدون حالت هستند و هیچ چیزی را به اشتراک نمی گذارند. هر دیتایی که نیاز هست ذخیره شود باید در یک سرویس بک اند؛ عموما یک دیتابیس ذخیره شود.

The Twelve-Factor App

Heroku این روش فکر کردن را پیشنهاد می کند اما وقتی در حال استفاده و اجرا از PaaS هستید می توانید این قاعده را نادیده بگیرید. با FaaS دیگه نادیده گرفتن این قاعده وجود ندارد.

خب در نتیجه وقتی که شما نمی توانید حالت را در حافظه نگه دارید با FaaS حالت های برنامه شما کجا نگه داشته می شوند. سخن بالا اشاره به استفاده از دیتابیس و در بسیاری از موارد دیتابیس های سریع NoSQL به غیر از کش های خارج از فرآیند(از جمله Redis) یا یک ذخیره سازی فایل خارجی(مثل S3) به عنوان برخی از انتخاب های شما دارد. اما تمام این موارد نسبت به ذخیره کردن درون ماشین یا درون حافظه کندتر هستند. شما باید بررسی کنید که ببینید آیا برنامه ی شما با این راه حل ها اوکی هست.

نگرانی دیگر در این مورد کش های درون حافظه هست. بسیاری از برنامه ها که در حال استفاده از یک دیتا ست های بزرگ که بصورت گسترده ذخیره شده اند هستند از کش در حافظه به عنوان بخشی از دیتا ست استفاده می کنند. شما ممکن است از جدول های “reference data” در یک دیتابیس استفاده کنید و از چیزی شبیه Ehcache استفاده کنید. همچنین ممکن است از یک http service که هدرهای کش را مشخص می کند در موردی که in-memory http client شما می تواند کش لوکال را نیز مهیا کند استفاده کنید. با یک پیاده سازی FaaS می توانید این کد را درون app خود داشته باشید اما کش را هرگز؛ حتی اگر خیلی هم سودمند باشد. به محض اینکه کش شما در اولین پیاده سازی قرار گرفت ممکن است به محض اینکه FaaS پائین آمد دور ریخته شود.

یک راه برای کم کردن این مورد این است که در مورد کش های درون فرآیند هیچ فرضی نکنیم و همچنین از کش های خارجی با کمترین تاخیر از جمله Redis و Memcached استفاده کنیم؛ اما این مورد (a) نیازمند کار اضافی است و (b) ممکن است بسته به مورد شما فوق العاده کند باشد.

مشکلات پیاده سازی

مشکلات که در بخش قبل توضیح داده شد تقریبا همیشه با Serverlss وجود دارند. ما برخی بهبودها را راه حل های کاهش دیدیم؛ اما این مشکلات همیشه وجود دارند.

سایر مشکلات؛ با اینحال به وضعیت فعلی هنر بستگی دارند. با تمایل و سرمایه گذاری در بخشی از فروشندگان و/یا کامیونیتی بی باک و قهرمان(heroic) این مشکلات می تواند مرتفع شوند. اما در حال حاضر یک مشت از این مشکلات وجود دارد…

پیکربندی(Configuration)

توابع AWS Lambdaهیچ گونه پیکربندی را پیشنهاد نمی کنند. توجه داشته باشید حتی متغیرهای محیطی را. به چه صورت می تواند artifactهای دیپلوی مشابه را با ویژگی های متفاوت بر اساس طبیعت محیط  اجرا کنید؟ شما نمی توانید. نیاز دارید که artifact های دیپلوی خود را مجدد تعریف کنید؛ شاید با فایل های پیکربندی متفاوت. این یک هک بد است. Serverless framework می تواند این هک را برای شما انتزاع کند؛ با این وجود این مورد هنوز یک هک است.

من دلایلی دارم که معتقدم Amazon این مورد را رفع می کند(یا بزودی بهتر می کند) و نمی دانم که آیا سایر فروشندگان هم مشکل مشابهی دارند یا خیر؛ اما در بالا به عنوان یک مثال ذکر کردم که چرا بسیاری از اینها در حال حاضر بر لبه ی خونین هستند.

خودتان را از سرویس منع کنید

یک مثال سرگرم کننده ی دیگر این است که چرا Caveat Emptor وقتی که در حال استفاده از FaaS هستید؛ یک عبارت کلیدی است. AWS Lambdaدر حال حاضر در مود تعداد اجراهای همزمان که می توانید Lambda های خود اجرا کنید؛ شما را محدود می کنند. فرض کنید این محدودیت 100 باشد؛ این بدین معنی است که در هر لحظه شما فقط اجازه دارید که  1000 تا از توابع را اجرا کنید. اگر اتفاقی بیافتد که مجبور شوید از این حد بالاتر بروید ممکن است شروع به خطا خوردن بخورید؛ صف بندی بکنید و/یا بصورت کلی کند شوید.

مشکل در اینجا این است که این محدودیت بر روی تمام حساب AWS شما وجود دارد. برخی سازمانها از یک حساب AWS مشابه برای هر دو محیط عملیاتی و آزمایشی استفاده می کنند. و این بدین معنی است که در صورتی که کسی؛ جایی در سازمان بخواهد نوع جدیدی از تست بار را امتحان کند و بخواهد 1000 تابع Lambdaهمزمان را اجرا کند؛ شما تصادفا برنامه عملیاتی خود را DoS می کنید. Oops.

حتی اگر از حساب های AWS متفاوتی برای محیط عملیاتی و توسعه استفاده کنید یک بار زیادی عملیاتی Lambda(به عنوان مثال یک آپلود دسته ای از مشتری) می تواند منجر شود که API عملیاتی Lambda-backed زمان واقعی که از محیط تست شما جدا می باشد نیز غیر فعال شود.

سایر انواع منابع AWS می توانند توسط کانتکست محیط و ناحیه برنامه توسط برخی مفاهیم دیواره ی آتش و امنیتی از هم تفکیک شوند. Lambdaنیازمند چیز مشابهی است؛ و شک ندارم که در زمان غیر طولانی اتفاق می افتد.  اما در حال حاضر مجددا محتاط باشید.

زمان اجرا

جلوتر در مقاله ذکر کردم که توابع AWS Lambdaاگر بیش از 5 دقیقه در حال اجرا باشند، قطع می شوند. و این محدودیتی است که انتظار دارم بعدا مرتفع شود، اما جالب خواهد بود که ببینیم AWS در این مورد چه رویکردی دارد.

تاخیر راه اندازی

نگرانی دیگر که قبلا ذکر کردم این است که چه مقدار زمان می برد تا یک تابع FaaS پاسخ بدهد؛ که بخصوص گاهی با استفاده از توابع پیاده سازی شده در JVM برای AWS جای نگرانی است. اگر چنین تابع Lambda ای داشته باشید بطور معمول 10 ثانیه طول می کشد تا راه اندازی شود.

انتظار دارم که AWS کاهش های متفاوتی را با گذشت زمان پیاده سازی کند؛ اما الان ممکن است در برخی از موارد استفاده از JVM Lambda یک فاکتور منع کننده باشد.

خب؛ دلایل کافی وجود دارد که AWS Lambda را بطور خاص انتخاب کنیم. مطمئن هستم که سایر فروشنده ها نیز ساختار بسیار بدی در نزدیکی خود دارند.

تست کردن

تست واحد کردن برنامه های Serverless بدلایلی که قبلا صحبت کردم بسیار ساده است – هر کد شما می نویسید “فقط کد” است و برای بیشتر بخش ها؛ یک مجموعه لایبرری های شخصی یا اینترفیس هایی که باید پیاده سازی شوند وجود ندارد.

تست های جامعیت برنامه های Serverless از طرف دیگر مشکل هستند. در دنیای BaaS شما عمدا وابسته به سیستم هایی که بصورت خارجی مهیا شده اند نسبت به اینکه(به عنوان مثال) دیتابیس خود را داشته باشید هستید. در نتیجه آیا تست های جامعیت شما باید از سیستم های خارجی نیز استفاده کند؟ اگر بله، چگونه این سیستم ها برای سناریوهای تست کردن امن می شوند؟ آیا می توانید به آسانی حالت را خاموش/روشن کنید؟ آیا فروشنده شما صورتحسات استراتژی متفاوتی برای تست های لود می دهد؟

در دنیای FaaS مشکلات مشابهی نیز وجود درد. در حال حاضر بیشتر فروشندگان پیاده سازی لوکال که بتوانید از آن استفاده کنید را مهیا نمی کنند و در نتیجه شما مجبور به استفاده از پیاده سازی های عملیاتی معمول هستید. اما این بدین معنی است که انتشار از راه دور و تست کردن، بصورت ریموت از سیستم ها برای تست های پذیرش/جامعیت استفاده می کنند. حتی نوع بدتر مشکلات که توضیح دادم(نبود پیکربندی؛ محدودیت های اجرای چند حسابی) نیز بر روی تست شما تاثیر گذار هستد.

بخشی از دلیل اینکه این یک معامله ی بزرگ است این است که بخش های جامعیت با Serverless FaaS( به عنوان مثال تابع) نسبت به سایر معماری ها بسیار کوچکتر هستند و بنابراین ما در تست های جامعیت نسبت به سایر سبک های معماری بیشتر وابسته هستیم.

Tim Wanger (مدیر کل AWS Lambda) در کنفرانس Serverless اخیر توضیحات مختصری داد که آنها در حال بررسی تست کردن هستند؛ اما بنظر می رسید که قرار است تا حد زیادی بر روی تست کردن در cloud تکیه کنند. این احتمالا فقط یک دنیای شجاع جدید است؛ اما من نمی توانم که سیستمم را بصورت کامل از لپ تاپم و بصورت آفلاین تست کنم.

دیپلوی کردن/پکیچ کردن/ورژن بندی

این مشکل مرتبط با FaaS است. در حال حاضر ما الگوهای خوبی برای باندل کردن دسته ای از توابع درون یک برنامه نداریم. به چند دلیل این مورد یک مشکل است:

  • ممکن است که نیاز داشته باشید که FaaS artifact را بصورت جداگانه برای هر تابع در کل منطق برنامه خود دیپلوی کنید. اگر(فرضا) برنامه ی شما بر روی JVM پیاده شده باشد و شما 20 تابع FaaS داشته باشید این به معنی 20 بار دیپلوی JAR های شما است.
  • این مورد همچنین بدین معنی است که شما نمی توانید بصورت اتوماتیک گروهی از توابع را دیپلوی کنید. ممکن است نیاز داشته باشید که event source هایی که توابع را تریگر می کنند خاموش کنید؛ کل گروه را دیپلوی کنید و مجدد event source را روشن کنید. این روش برای برنامه های zero-downtime یک مشکل است.
  • و نهایتا این مورد بدین معنی است که مفهوم برنامه های ورژن شده وجود ندارد و در نتیجه رول بک اتوماتیک به عنوان یک گزینه وجود ندارد.

مجددا یک سری راه حل اوپن سورس برای کمک به برخی از این مشکلات وجود دارد؛ اگرچه اینها فقط توسط پشتیبانی فروشنده قابل حل هستند. AWS برای حل کردن برخی از این نگرانی ها در کنفرانس اخیر Serverless؛ از یک ابتکار جدید به نام “Flourish” خبر داد اما تا به اینجا هیچ جزئیات قابل توجهی منتشر نشده.

کشف (Discovery)

مشابه نکات پیکربندی و پکیچ سازی هیچ الگوی خوش-تعریفی برای discovery میان توابع FaaS وجود ندارد. هرچند برخی از این مشکلات مختص FaaS نیستند؛ اما این مشکلات، با طبیعت خوشه بندی توابع FaaS و عدم تعریف برنامه/ورژن بندی؛ تشدید می شوند.

مانیتورینگ / خطایابی

در حال حاظر شما به بخش مانیتورینگ و خطایابی توسط چیزی که فروشنده به شما می دهد گیر کرده اید. البته این مورد می تواند در برخی موارد خوب باشد؛ اما برای AWS Lambda حداقل مانیتورینگ و خطایابی در کمترین سطح هستند. چیزی که در این سطح واقعا نیاز داریم وجود یک open API و همچنین توانایی سرویس های شخص ثالث برای کمک است.

تعریف API Getaway، و API Getaway های بیش از حد بلند پروازانه

اخیرا ThouhtWorks Technology Radar در مورد API Getaway های بیش از حد بلند پروازانه بحث کرد. در حالیکه لینک اشاره به API Getaway ها بصورت کلی دارد اما مطمئنا می تواند در مورد FaaS API Getaway ها همانطور که قبلا هم اشاره کردم؛ نیز اعمال شود مشکل این است که API Getaway ها موقعیت هایی را برای انجام بیشتر منطق های خاص برنامه در کانفیگ/تعریف دامنه خود ارائه می دهند. تست کردن؛ کنترل ورژن، و حتی تعریف زمان ها در این منطق ها عموما سخت است. بسیار بهتر است که این منطق ها شبیه سایر بخش های برنامه در کد برنامه باقی بمانند.

در حال حاضر با API Getaway مربوط به Amazon؛ شما مجبور به استفاده از بسیاری از مفاهیم و نواحی پیکربندی مختص به Getaway برای بیشتر برنامه های ساده هستید. اینها بخشی از دلایلی هستند که به چه دلیل پروژه های اوپن سورسی مثل Serverless framework و Claudia.js وجود دارند؛ تا توسعه دهنده را از مفهوم های مختص به پیاده سازی انتزاع کنند و به آنها اجازه دهند که از کدهای معمول استفاده کنند.

در حالیکه این احتمال وجود دارد که همیشه موقعیت هایی برای پیچیده شدن بیش از حد API Getaway شما بوجود بیاید؛ در عین حال انتظار داریم که ابزارهایی ببینیم تا مجبور نباشیم که آنرا انجام دهیم و الگوهایی توصیه شده برای اجتناب از این چنین مشکلات بوجود بیاید.

تعویق عملیات

جلوتر اشاره کردم که Serverless به معنی “No Ops” نیست- هنوز یک مشت کار از جمله مانیتورینگ؛ مقیاس کردن معماری؛ امنیت؛ شبکه و … برای انجام دادن وجود دارد. اما این حقیقت که برخی افراد(آه، احتمالا من، mea culpa) Serverless را به عنوان “No Ops” تعریف کردند به این دلیل است که وقتی که شما شروع می کنید بسیار آسان و راحت است که عملیات را بیخیال شوید “به من توجه کن – نه سیستم عامل!” در اینجا این خطر وجود دارد که احساس نادرستی در مورد امنیت دست بدهد. ممکن است شما برنامه خودتون را داشته باشید و در حال اجرا باشد اما بصورت غیر منتظره ای با خبر هکرهای مواجه می شوید؛ و بطور ناگهانی شما 10 برابر میزان ترافیک مواجه می شوید که باید با آن روبرو شوید و Oops – شما به یکباره DoS می شوید و ایده و فکری ندارید که به چه صورت باید با آن مقابله کنید.

حل این مشکل همانند نکته ی API Getaway بالا؛ آموزش است. تیم هایی که از سیستم های Serverless استفاده می کنند نیاز است که زودتر فعالیت های عملیاتی را بررسی کنند و این بر عهده ی فروشنده ها و کامیونیتی است که آموزش لازم را جهت ایکه آنها این موارد را یاد بگیرند آماده کنند.

 

آینده ی Serverless

ما به انتهای این سفر در دنیای معماری های Serverless رسیدیم. برای پایان دادن می خواهم برخی نواحی هایی که فکر می کنم دنیای Serverlss در ماه ها یا سال های آینده توسعه می دهند وارد شوم.

کاهش معایب

همانطور که چندین بار گفتم Serverless جدید است. و هرچند که قسمت قبلی درباره ی معایب گسترده بود و من حتی نتوانستم همه موارد که می توانستم را بطور پوشش دهم. مهمترین توسعه Serverless کم کردن معایب ذاتی و حذف یا حداقل بهبود معایب پیاده سازی است.

ابزار

بزرگترین مشکل Serverless FaaS در ذهن من در حال حاضر ابزار است. باندل کردن برنامه/دیپلوی؛ پیکربندی؛ مانیتورینگ/لاگینگ؛ و خطایابی نیازمند کار جدی هستند.

پروژه خبر داده شده ی Amazon و البته هنوز مشخص نشده ی Flourish می توانند در مورد برخی از اینها کمک کننده باشد. بخش مثبت دیگر این خبر این است که این پروژه اوپن سورس خواهد بود و فرصت را برای قابل حمل بودن برنامه هابین فروشندگان را می دهد. من انتظار دارم در یک یا دو سال بعد در دنیای اوپن سورس چیزی شبیه به این ببینیم حتی اگر این چیز Flourish نباشد.

مانیتورینگ؛ ثبت لاگ و خطایابی همگی بخشی از پیاده سازی های فروشنده هستند و ما بهبودهایی هم در BaaS و هم در FaaS را مشاهده می کنیم. لاگ انداختن در AWS Lambda حداقل در حال حاضر به نسبت برنامه های سنتی که از ELK یا موارد مشابه استفاده می کنند؛ بسیار بد است. ما در روزهای ابتدایی یکسری تلاش های اوپن سورس و تجاری شخص ثالث در این زمنیه مشاهده کردیم(به عنوان مثال IOPipe و trace-aws-sdk) اما در فاصله ی بسیار دوری از مواردی شبیه حوزه ی New Relic هستیم. امیدواری من این است که جدای از AWS یک را حل بهتر برای لاگینگ برای FaaS که بتونه به آسانی به درون سرویس های لاگینک درست شبیه به روشی که Heroku و سایرین انجام می دهند اضافه شود مهیا شود.

ابزارهای API Getaway همچنین نیازمند بهبودهای بسیار زیادی هستند؛ و مجدد برخی از آنها ممکن است با Flourish یا نمونه های پیشرفته تر در Serverless Framework یا موارد مشابه بیایند.

مدیریت حالت

عدم وجود حالت در سرور برای FaaS برای تعدادی از برنامه ها خوب است و برای بسیاری دیگر یک مانع و خطر می شود. به عنوان مثال بسیاری از برنامه های مایکروسرویس ها، از مقداری حالت کش شده ی in-process جهت بهبود تاخیر استفاده می کنند. بصورت مشابه connection pool ها(چه در دیتابیس ها یا http connection پایدار به سرویس های دیگر) هم شکلی از حالت هستند.

یک راه حل برای برنامه های با عملکرد بالا می تواند توسط فروشندگان از طریق بالا نگه داشتن نمونه های توابع برای مدت طولانی تر باشد و در نتیجه به رویکردهای کش in-process اجازه داد که وظیفه ی خود را انجام دهند. این مورد البته در 100% زمان کار نمی کند زیرا کش برای تمام درخواست مهم نیست؛ اما این یک نگرانی است که قبلا برای برنامه های دیپلوی شده سنتی در استفاده از مقیاس پذیر کردن اتوماتیک داشتند.

یک راه حل بهتر می تواند دسترسی با تاخیر کم به دیتاهای خارج از فرآیند داشته باشد؛ مثلا قادر باشد که به دیتابیس Redis با سربار شبکه خیلی کم کوئری بزند . بنظر می رسد بیش از حد کشش که این حقیقت که Amazon قبلا یک راه حل Redis هاست شده در محصول Elasticache خود را پیشنهاد داده است، و اینکه آنها قبلا  تا حدودی اجازه دادند که نمونه های EC2(ُسرور) با استفاده از Placement Groupها را بتوان محل یابی کرد.

به احتمال بیشتر چیزی که فکر می کنم خواهیم دید نوع متفاوت تری از معماری های برنامه  است جهت دست یابی و استفاده از محدودیت عدم-وجود-حالت-در-فرآیند. به عنوان مثال برای برنامه های با تاخیر کم ممکن است یک سرور معمولی را مشاهده کنید که یک درخواست اولیه را کنترل می کند؛ و تمام کانتکست مورد نیاز را برای پردازش آن درخواست از حالت لوکال و خارجی اش جمع می کند؛ و سپس درخواست کاملا-متنی(fully-contextualized) به یک مزرعه از توابع  FaaS ( a farm of FaaS functions)ارسال می کند، که خودشان نیازی به جستجو در دیتاهای خاراجی ندارند.

بهبودهای پلت فرم

برخی از اشکالات به Serverless FaaS در حال حاضر به روشی که پلت فرم های پیاده سازی شده اند بر می گردند. زمان اجرا؛ تاخیر شروع بکار؛ محدودیت های عدم جداسازی اجرا سه مورد قبلی هستند. این ها احتمالا یا توسط راه حل های جدید یا توسط راه حل های داده شده با هزینه های اضافی ممکن؛ حل می شوند. به عنوان مثال می توانم تصور کنم که با اجازه دادن به مشتری که بتواند دو نمونه از یک تابع FaaS که همیشه در تاخیر کم در دسترس هستند را درخواست بدهد، می توان مشکل تاخیر شروع بکار را حل کرد، و اینکه مشتری برای این در دسترس بودن هزینه پرداخت کند.

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

آموزش

خیلی از مشکلات ذاتی مختص فروشندگان با Serverless از طریق آموزش کاهش پیدا می کند. هرکسی که از چنین پلت فرم هایی استفاده می کند باید بصورت صحیح و دقیق درباره اینکه، بخش زیادی از اکوسیستم هایشان توسط یک یا تعدادی از فروشندگان برنامه ها میزبانی می شود؛ به چه معنی است فکر کنند. یکی از سوال هایی که نیازمند این هست بررسی شوند این است “آیا نیاز داریم که راه حل های موازی برای فروشندگان مختلف را در مواقعی که یکی از آنها در دسترس نیستند را بررسی کنیم؟ چگونه می توان به شکل مناسب در مواقعی که یک اختلال جزیی بوجود می آید برنامه ها را کم کرد؟”

عملیات تکنیکالی یکی دیگر از نواحی آموزش هستند. بسیاری از تیم ها امروزه نسبت به چیزی که قبلا استفاده می کردند تعداد “Sys Admins” کمتری دارند؛ و Serverless می تواند این تغییر را شتاب دهد. اما Sys Adminها کارهای بیشتری نسبت به کانفیگ کردن باکس های Unix و نوشتن اسکریپت های chef انجام می دهند – آنها هم چنین افراد در خط مقدم پشتیبانی؛ شبکه؛ امنیت و موارد مشابه هستند.

یک فرهنگ صحیح DevOps در دنیای Serverless اهمیتش بشتر می شود زیرا سایر فعالیت های غیر Sys Admin نیز نیاز است که به انجام برسد و اغلب اوقات توسعه دهنده هایشان هستند که این مسئولیت را بر عهده دارند. این فعالیت ها ممکن است بطور معمول به خیلی از توسعه دهنده ها و رهبران فنی وارد نشود؛ در نتیجه آموزش و ارتباط مستقیم با افراد عملیاتی از اهمیت زیادی برخوردار خواهد شد.

افزایش شفافیت/انتظارات از فروشندگان

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

ضرورت الگوها

جدای از سادگی پلت فرم ها؛ درک ما از چگونگی و زمان استفاده از معماری های Serverless هنوز بسیار کم و ناچیز است. در حال حاضر تیم ها تمام ایده ها در پلت فرم Serverless را گرفته اند ,و چه چیزهایی می بینند. خدا رو شکر بخاطر وجود پیشروها.

اما در برخی مواقع، قصد داریم که الگوهای توصیه شده از  رفتارهای پدیدآر(emerge) را مشاهده کنیم.

برخی از این الگوها در معماری برنامه هستند. به عنوان نمونه توابع FaaS قبل از اینکه خیلی سنگین شوند تا چه اندازه می توانند بزرگ شوند؟ فرض کنید ما می توانیم بصورت اتوماتیک گروهی از توابع FaaS را دیپلوی کنیم بهترین راه ها برای ایجاد این گروه بندی چیست؟ – آیا آنها مستقیما شبیه روشی که ما منطق را درون مایکروسرویس ها دسته بندی می کنیم نگاشت می شوند یا تفاوت در معماری ما را به مسیر جداگانه ای می برد؟

گسترش بیشتر این مسئله، راه های مناسب برای ایجاد معماری های ترکیبی میان کامپوننت های FaaS و سرورهای ذخیره سازی “همیشه روشن” چیست؟ راه های مناسب معرفی BaaS درون یک اکوسیستم موجود چیست؟ و بصورت برعکس، علائم های هشدار که سیستم  های کامل-یا-حدودا BaaS نیاز به شروع استفاده بیشتر از کدهای سمت سرور سفارشی دارند چیست؟

ما همچنین شاهد الگوهای استفاده ی پدیدآر بیشتر خواهیم بود. یکی از مثال های استاندارد برای FaaS تغییر رسانه است: ” وقتی که یک فایل مدیا بزرگ درون یک S3 bucket ذخیره می شود بصورت اتوماتیک فرآیندهایی برای ایجاد نسخه های کوچکتر درون bucket دیگر اجرا می شود.” اما ما نیاز به الگوهای استفاده بیشتری که باید فهرست بندی شوند داریم تا ببینیم آیا موارد استفاده خاص ما برای یک رویکرد Serverless مناسب است یا خیر؟

ورای معماری برنامه، الگوهای عملیاتی توصیه شده را با بهبود ابزارها مشاهده می کنیم. به چه صورت ما بصورت منطقی لاگ های یک معماری ترکیبی FaaS، BaaS و سرورهای سنتی را تجمیع می کنیم؟ ایده های خوب و مناسب برای اکتشاف(discovery) چیست؟ Canary release ها را به چه صورت برای API-Getaway که در جلوی برنامه های وب FaaS قرار داده شده انجام می دهیم؟ چگونه به موثرترین شکل توابع FaaS را خطایابی می کنیم؟

ورای “FaaSification

بیشترین استفاده از FaaS که تا بحال دیدم بیشتر در مورد گرفتن ایده های کد/طراحی موجود و سپس “FaaSifying” کردن آ ن بود – تبدیل آن به مجموعه ای از توابع بدون حالت. این مورد قدرتمند است، اما علاوه بر این انتظار دارم که انتزاع بیشتر و احتمالا زبانهای استفاده کننده از FaaS به عنوان پیاده سازیهایی که به توسعه دهنده ها مزایای FaaS را بدون اینکه واقعا به این موضوع که برنامه ی آنها مجموعه ای از توابع جدا از هم هستند فکر کنند، بدهد را مشاهده کنیم.

به عنوان مثال نمی دانم که آیا Google از یک پیاده سازی FaaS برای محصول Dataflow خود استفاده می کند یا خیر، اما می توانم تصور کنم که کسی محصول یا پروژه ی اوپن سورسی که چیز مشابهی انجام می دهد را ایجاد می کند، و از FaaS به عنوان یک پیاده سازی استفاده می کند. یک مقایسه اینجا چیزی شبیه Apache Spark است. Spark ابزاری برای پردازش دیتا با مقیاس بزرگ است که انتزاع خیلی زیادی پیشنهاد می کند که می تواند از Amazon EMR / Hadoop به عنوان پلت فرم استفاده کند.

تست کردن

همانطور که در بخش “معایب” عنوان کردم برای سیستم های Serverless کارهای زیادی در ناحیه ی تست جامعیت و پذیرش برای انجام دادن وجود دارد. خواهیم دید که فروشندگان با پیشنهادهای خود می آیند، که احتمالا بر اساس Cloud است، و سپس انتظار دارم که برای افراد کم طاقتی مثل من که می خواهند همه چیز را در ماشین توسعه خود بتونند تست کند انتخاب های دیگری را ببینیم. من انتظار دارم که ده ها راه حل برای هم تست آنلاین و هم آفلاین را شاهد باشیم؛ اما این مورد می تواند چند سالی طول بکشد.

پیاده سازی های قابل جابجایی

در حال حاضر پیاده سازی های متداول Serverless دیپلوی را توسط یک سیستم فروشنده شخص ثالث در cloud در نظر می گیرند. که یکی از مزیت های Serverless است – تکنولوژی کمتری را باید نگهداری کنیم. اما اینجا یک مشکل وجود دارد اگر یک شرکت بخواهد از این تکنولوژی ها استفاده کند و آنرا بر روی سیستم های خود اجرا کند و آن را به عنوان یک سرویس داخلی پیشنهاد دهد.

بصورت مشابه تمام پیاده سازی ها تمایلات خاص خود در تجمیع نقاط توسعه، پیکربندی، و اینترفیس تابع و … را دارند. اینها باعث مشکلات انحصار فروشنده که قبلا ذکر کردم می شوند.

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

انتزاع بر روی پیاده سازی های مشتری

ما قبلا چیزی شبیه پروژه های اوپن سورس از جمله Serverless Framework و Lambda Frmework مشاهده کردیم. ایده در اینجا این است که اگر بتوانیم که برنامه های Serverless خودمان را با مرحله توسعه صرفنظر از اینکه کجا و چگونه دیپلوی می شوند، کد نویسی و سپس دیپلوی کنیم بسیار خوب خواهد بود. و خیلی خوب می شود اگر بتوان به آسانی بین AWS API Getaway + Lambda و Auth0 webstack بر اساس توانایی های عملیاتی هر کدام از پلت فرم ها جابجا شد.

تا وقتی که شاهد بسته بندی بیشتر محصولات نباشیم؛ انتظار ندارم که این انتزاع سازی تکمیل شود؛ اما خبر خوب این است که این ایده می تواند بصورت افزایشی پیاده سازی شود. ما ممکن است با چیزی شبیه ابزارهای توسعه چند-مشتری شروع کنیم – که حتی می تواند پروژه ی Flourish مربوط AWS که قبلا گفتم باشد – و ویژگی های بیشتری را بعدا از اینجایی که شروع کردیم ایجاد کنیم.

یک بخش قابل بحث به این نوع مدل کرد FaaS انتزاع شده، کد زدن اینترفیس ها بدون برخی از ایده های استاندارد سازی است؛ اما انتظار دارم که ابتدا پیشرفت در FaaS غیر اختصاصی و وابسته به شخص خاص؛ اتفاق بیافتد. به عنوان نمونه من انتظار دارم که یک انتزاع از درخواست های وب و زمان Lambda های بندی شده(“corn”) را قبل از اینکه انتزاع را بر روی مواردی شبی AWS S3 یا  Kinesis Lambda ها ببینیم را مشاهده کنیم.

پیاده سازی های قابل جابجایی

پیشنهاد استفاده از تکنیک های Serverless بدون استفاده از پروایدرهای شخص ثالث عجیب و غریب به نظر می رسد؛ اما این فکرها را بررسی کن:

  • شاید ما یک سازمان بزرگ تکنیکال باشیم و استفاده از تجربه ی دیتابیس های شبیه Firebase را به تیم های توسعه برنامه خود را پیشنهاد کنیم؛ اما می خواهیم که از معماری های دیتابیس فعلی خود به عنوان بک اند استفاده کنیم.
  • ما تمایل داریم که از سبک معماری FaaS برای برخی از پروژه هایمان استفاده کنیم؛ اما بخاطر دلایل انطباق/ قانون/غیره نیاز داریم که برنامه های خود را بصورت “on permise” اجرا کنیم.

در هر کدام از این موارد هنوز مزیت های زیادی در استفاده از رویکردهای Serverless بدون اینکه آنها توسط فروشنده هاست شوند وجود دارد. یک نمونه اینجا وجود دارد – Platform-as-Sevice(PaaS) را بررسی کنید. تمام PaaS های محبوب اولیه مبتنی بر cloud بودند(به عنوان مثال Heroku)، اما متاسفانه افراد خیلی زودتر مزیت اجرای یک محیط FaaS بر روی سیستم های خود را فهمیدند – چیزی که “Private PaaS” بهش گفته می شد (مثل Cloud Foundry).

می توانم تصور کنم؛ همانند پیاده سازی های private PaaS؛ پیاده سازی های تجاری و اوپن سورس مفاهیم BaaS و FaaS متداول می شوند. Google Fog یک مثال از پروژه ی اوپن سورس اولیه در این زمینه است؛ که شامل پیاده سازی FaaS مخصوص بخود است. مشابه نکته ی من درباره ی انتزاع فروشنده ها که در بالا آمد ممکن است که یک رویکرد افزایشی را اینجا نیز مشاهده کنیم. به عنوان مثال پروژه ی Kong یک پیاده سازی API Getaway است. در زمان نوشتن این مقاله هنوز با AWS Lambda یکپارچه نشده بود(اگر بر روی آن دارد کار می شود) اما اگر بتواند این یک رویکرد ترکیبی جالب خواهد بود.

کامیونیتی

من کاملا انتظار دارم که یک پیشرفت بزرگ در کامیونیتی Seerverless را شاهد باشیم. در حال حاضر یک کنفرانس و تعداد زیادی گردهم آیی در سراسر دنیا را وجود دارد. من انتظار دارم چیزی بیشتر از کامیونیتی بزرگ و گسترده ی که برای Docker و Spring وجود دارد را ببینیم – کنفرانس های زیاد؛ کامیونیتی های بیشتر و fora های آنلاین بیشتر که شما احتمالا می توانید پیگیری کنید.

– – — – – – –

نتیجه گیری

Serverless، برخلاف اسم گیچ کننده اش؛ سبکی از معماری است که ما در آن نسبت به اجرای سیستم های سمت سرو خودمان به عنوان بخشی از برنامه کمتر متکی هستیم. ما این معماری را به دو شکل انجام می دهیم – Backend as a Service(BaaS)، که ما کاملا سرویس برنامه ریموت شخص ثالث را درون بخش front-end برنامه هایمان یکپارچه می کنیم، و Functions as a Service(FaaS) که کدهای سمت سرور را از یک کامپوننت با زمان حیات طولانی به نمونه توابع کوتاه مدت تبدیل می شود.

بعید به نظر می رسد که Serverless یک راه حل مناسب برای تمام مشکلات باشد. پس مراقب هر کسی که ادعا می کند که Serverless تمام معماری های ما را جایگزین می کند باشید. هم چنین اگر به یکباره در سیستم های فعلی Serverless غوطه ور شدید؛ بخصوص منطقه ی FaaS. در حالی که ثروت و دارایی زیادی(مقیاس پذیری و تلاش دیپلوی ذخیره شده) برای غارت و چپاول وجود دارد؛ اژدهایی (خطا یابی و مانیتورینگ) درست در گوشه ی بعدی در کمین است.

این مزیت ها البته نباید به سرعت حذف شود؛ در حالیکه جنبه های مثبت قابل توجهی در معماری Serverless وجود دارد؛ شامل کاهش هزینه های توسعه و عملیات؛ مدیریت آسانتر عملیات و کاهش تاثیرات محیطی. از نظر من مهمترین مزیت کاهش چرخه های فیدبک از ایجاد کامپوننت های برنامه های جدید است – من یکی از طرفداران شدید رویکردهای “lean” هستم؛ بیشتر به این دلیل که فکر می کنم در قرار دادن تکنولوژی در مقابل کاربر نهایی در اسرع وقت جهت گرفتن بازخوردهای سریعتر ارزش بسیار زیادی وجود دارد؛ و زمان بازار کاهش یافته که Serverless دقیقا با این فلسفه سازگار است.

سیستم های Serverless در دوران کودکی خود هنوز به سر می برند. سال های پیش رو پیشرفت های زیادی در این زمینه خواهد داشت و جذاب خواهد بود که ببینیم چگونه آنها این پیشرفت ها در جعبه ابزار معماری ما جا خواهد گرفت.

 

درباره ی masoud@admin

همچنین ببینید

اسید و بازها و چالش سازگاری در سیستم های توزیع شده

اسید و بازها و چالش سازگاری در سیستم های توزیع شده بدون شک سازگاری یکی …

Serverless Architecture for an IoT solution xconf eu 2017

Serverless Architectures معماری Serverless که به عنوان یکی از Deployment Strategy های مورد در استفاده …

پاسخ دهید

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

در تلگرام هم همراه شما هستم

اگر علاقمند به معماری نرم افزار و مبحث محبوب مایکروسرویس هستید؛ در کانال با ما همراه باشید. اطلاعات مفید زیادی در این کانال انتظار شما را می کشند. فقط کافیست دکمه ی پیوستن را بفشارید.

پیوستن بستن