[ad_1]

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

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

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

بدون سرور چیست؟

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

این ممکن است بسیار شبیه یک پلتفرم به عنوان یک سرویس (PaaS) باشد ، مانند Open Hat Shift یا Google App Engine ، اما به طور کلی ، اینها بیشتر محیط های توسعه دهنده سنتی هستند. توسعه دهنده کنترل بیشتری بر محیط استقرار در PaaS دارد ، از جمله نحوه مقیاس گذاری برنامه ، در حالی که در مقیاس گذاری بدون سرور تمایل به خودکار بودن دارد.

بنابراین اصطلاح “بدون سرور” می تواند برای طیف وسیعی از خدمات ، به ویژه AWS Lambda در ابر آمازون اعمال شود ، که می تواند به دلیل جلب توجه رایانه های بدون سرور به افکار عمومی در هنگام راه اندازی مجدد آن در سال 2014 ، اعتبار داشته باشد.

Lambda به توسعه دهندگان این امکان را می دهد تا کدی را ایجاد کنند که در پاسخ به برخی از رویدادها یا ماشه ها اجرا شود ، مانند اینکه یک شی جدید در سطل موجود در سرویس ذخیره سازی ساده آمازون (S3) بارگذاری می شود تا مثلاً عملکرد لازم را با آن انجام دهد. به همین دلیل ، از لامبدا اغلب به عنوان یک پلتفرم عملکرد به عنوان سرویس (FaaS) یاد می شود.

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

با این حال ، سرویسهای دیگر می توانند بدون سرور در نظر گرفته شوند که در صورت لزوم دارای معیارهای مقیاس گذاری خودکار باشند و کاربر نیازی به مدیریت زیرساخت های اساسی نداشته باشد. این شامل بسیاری از خدمات برنامه نویسی برنامه محور (API-محور) ارائه شده توسط سیستم عامل های اصلی ابر است ، و بنابراین آسان است که ببینیم چگونه می توان کل برنامه ها را با اتصال عناصر بدون سرور توسعه یافته توسط کاربر نهایی با توابع و خدمات ارائه شده توسط سیستم عامل ابر

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

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

ارزیابی موافقان و مخالفان بدون سرور

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

بر اساس گزارش IDC ، سیستم عامل های بدون سرور “یک مدل ساده برنامه نویسی ارائه می دهند که به طور کامل زیرساخت ها و برنامه های چرخه زندگی را تجزیه می کند تا تلاش توسعه دهندگان را در بهبود مستقیم نتایج کسب و کار متمرکز کند”. IDC پیش بینی کرد که استفاده از فاقد سرور می تواند منجر به بهره وری بالاتر و کاهش هزینه شود و متوسط ​​بازده سرمایه گذاری 409٪ طی پنج سال باشد.

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

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

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

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

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

Clive Longbottom ، تحلیلگر مستقل ، می گوید: “ما هنوز هم مشكل” بیش از هر بشكه “را داریم كه بدون سرور یك تامین كننده همان مشكل تهیه كننده دیگر نیست.

با این حال ، Longbottom اضافه می کند که ظروف و Kubernetes در حال شیوع بیشتر هستند و باید امیدوار بود که قابلیت حمل و نقل در محیط های بدون سرور در سطح بسیار عملکردی یا قابلیت های اضافی برای سیستم های ارکستراسیون وجود داشته باشد که می تواند بار کاری را متناسب کند این می تواند در یک محیط بدون سرور متفاوت با تغییر شکل کم یا احتمالاً در زمان واقعی و در صورت لزوم اجرا شود.

نگه داشتن برگه ها در استقرارهای بدون سرور

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

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

لانگ باتوم می گوید: “در جایی كه استفاده كلی از سرور صرفاً بر اساس استفاده از منابع است و مشخص نیست كه حجم كار از چه چیزی استفاده خواهد كرد ، پس هزینه حاصل از این كار ممكن است هنگام صدور صورتحساب تعجب آور باشد.”

با این حال ، اگر حجم کار به خوبی درک شده باشد و بدون سرور فقط برای سادگی استفاده شود ، دیگر نباید چنین شگفتی هایی وجود داشته باشد ، “او می گوید:” اگر ارائه دهنده بدون سرور اجازه تقسیم هزینه های منابع را بدهد ، این نیز می تواند راهی برای کنترل باشد – به خصوص اگر به کاربر اجازه دهند سقف را نیز در هزینه ها اعمال کند. “

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

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

Longbottom می گوید: “در مورد برنامه های مرکب ، نظارت و گزارش باید در کل جریان کار باشد ، که در حال حاضر دردناک است.”

“هوش مصنوعی [artificial intelligence] وی می تواند در اینجا ، مقابله با نتایج و استثنائات مورد انتظار و شناسایی هرگونه شکافی که در این راه اتفاق می افتد ، کمک کند – باز هم حلقه های بازخوردی را که برای حفظ یک محیط بهینه سازی شده بدون سرور لازم است ، فراهم می کند. “

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

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

[ad_2]

منبع: tadrisriazi-news.ir