معماری Serverless چیست و چه کاربردی دارد؟

آیا تکنولوژی های serverless یا بدون سرور، درب های پیش روی ما هستند؟

اکثراً در زمینه serverless به خدمات و محصولات FaaS اشاره می کنند؛ اما این تنها بخش این تکنولوژی نیست...

دو ویژگی کلیدی این تکنولوژی زیرساخت های نامرئی با پیاده سازی Image های ماشین مجازی و صرف هزینه به ازای مصرف است ( بجای پرداخت های معمول به صورت ماهانه ).

البته به آن اندازه که تصور می کنید، پیچیده نیست؛ تمام سرویس های ابری عملاً بدون سرور هستند؛ مشکل شاید در نام گذاری آن باشد که توسعه دهندگان را به ترس می اندازد که آیا کدها بر روی سروری قرار نخواهند گرفت؟

چطور باید محیط را رصد کرده و مشکلات را debug کرد؟

آیا serverless یک نسخه پیشرفته تر و تکامل یافته ی PaaS یا پلتفرم به عنوان سرویس است؟

اما منظور عدم وجود سرور نیست! به هر جال کدها باید در جایی اجرا شوند.

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

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

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

در رویکرد سنتی، زمانی که توسعه دهنده خدمات یا عملکردهایی را ( فانکشن ها ) اجرا می کند که با یکدیگر و فضای خارجی در ارتباط هستند، این سرویس ها پس از نصب، راه اندازی و بروز رسانی، در پردازش هایی توزیع شده ترکیب می شوند.

این پردازش ها و فرآیندها بر روی ماشین های مجازی اجرا می شوند؛

اما در رویکرد serverless ارائه دهنده پلتفرم مسئول تمام فرآیندها از پردازش ها گرفته تا سیستم عامل های سرورها خواهد بود.

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

BaaS و FaaS

معماری بدون سرور معمولاً توسعه و تکامل پلتفرم به عنوان سرویس در نظر گرفته می شود؛ در واقع در معماری serverless، اپلیکیشن ها به خدمات ارائه دهندگان شخص ثالثی تحت عنوان Backend as a service یا BaaS تکیه می کنند؛ و یا توسعه دهندگان کدهای خود را  بر روی پلتفرم هایی پیشرفته به نام FaaS که به معنای فانکشن به عنوان سرویس است، اجرا می کنند.

• BaaS در رایانش ابری

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

• FaaS در رایانش ابری

AWS Lambda و Azure یکی از اولین پیشگامان در ارائه کارکردهای رایانش بدون سرور هستند. در این سرویس ها، تمام بخش ها و تکه های کدها می توانند بنا به درخواست ( on demand ) اجرا شوند. در اینجا توسعه دهنده بجای نوشتن کل اپلیکیشن، بخش هایی از آن را با قوانین رویداد ( event rukes ) که کدها را در زمان نیاز فراخوانی می کنند، اجرا می کند.

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

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

تفاوت PaaS و معماری Serverless

چیزی که PaaS را از Serverless متمایز می کند این است که ارائه دهندگان سرویس های Paas قابلیت مقایس پذیری خودکار را ارائه نمی دهند. پس باید قبل از هر چیز ابتدا میزان منابعی که اپلیکیشن تان لازم خواهد داشت را پیش بینی کنید.

البته می توان منابع اختصاص یافته به اپلیکیشن را به صورت دستی بالا و پایین آورد، اما موضوع این است که این حجم کاری توسعه دهنده را افزایش خواهد داد.

بعلاوه سرویس های PaaS برای اجرای اپلیکیشن های سرور-محور بلند مدت طراحی شده اند؛ پس با چنین طراحی ای، اپلیکیشن همیشه باید برای پاسخ دهی به درخواست ها فعال باشد. اما اگر اپلیکیشن را غیر فعال کنید، دیگر مسلماً به درخواست ها پاسخی داده نخواهد شد.

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

نحوه عملکرد معماری serverless

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

هر کدام از فانکشن ها یک وظیفه خاص را پس از فراخوانی توسط یک ایونت انجام خواهد داد؛ مثل یک ایمیل دریافتی یا درخواست HTTP.

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

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

این فرآیند پردازشی دور از چشمان توسعه دهنده صورت می گیرد، تا بتوانند بر نوشتن و راه اندازی کدهای خود بهتر تمرکز کنند.

چرا باید از معماری Serverless استفاده کرد؟

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

برای مثال تکنولوژی های ابری به شما کمک کرده اند تا دیگر برای راه اندازی اپلیکیشن های خود نگران سخت افزارها نباشید.

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

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

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

بارها ثابت شده که صرفه جویی در هزینه های زیرساختی برای توسعه دهندگان پس از استفاده از serverless چشم گیر بوده است. این موضوع به این دلیل رخ می دهد که در زمان های عدم استفاده از منابع این معماری، هزینه ای پرداخت نخواهید کرد.

کاربردهای معماری Serverless

امور تریگر-محور: هر اقدامی از سمت کاربر که یک رویداد یا ایونتی را فراخوانی کند، مثل ثبت نام کاربر در سایت و فراخوانی تغییری در دیتابیس، می تواند توسط فانکشن هایی که در زنجیره serverless تعریف شده، اجرا شود.

ساخت RESTful API: شما می توانید درگاه API آمازون را با فانکشن های سرور لس برای ساخت RESTful API ها به بهترین شکل استفاده کنید و در صورت نیاز آن را ارتقا دهید.

تست های امنیتی: زمانی که یک کانتینر جدید ایجاد می کنید، یک فانکشن می تواند برای آزمایش پیکربندی های اشتباه و یا نقاط ضعف امنیتی فراخوانی شود. فانکشن ها را می توان برای اعتبار سنجی SSH امن تر و دو عاملی نیز مورد استفاده قرار داد.

و بسیاری دیگر...

توصیه می کنیم مقاله مربوط به FaaS را مطالعه کنید.

معایب Serverless شدن

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

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

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

علاوه بر این به دسترسی پذیری و API های پلتفرم نیز وابسته خواهید شد؛ در همین راستا، هزینه ها نیز تغییر می کنند. خدمات شرکت های مختلف نیز ممکن است متفاوت باشد.

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

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

این می تواند یک مسئله امنیتی مهم برای کسب و کارهایی باشد که از داده های حساس برخوردار هستند.

راهکار میزبان کلود

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

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

جمع بندی

معماری بدون سرور یا serverless یک روش جدید نوشتن و راه اندازی اپلیکیشن های وب بوده و به توسعه دهنده کمک می کند تا بر توسعه اپلیکیشن خود بیشتر تمرکز داشته باشد؛  این رویکرد می تواند زمان ورود به بازار، هزینه های عملیاتی و پیچیدگی های سیستمی را کاهش دهد.

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