امتیاز کلیدی

• چندین سال است که به ما قول داده شده است که محاسبات بدون سرور، عصر جدیدی را بدون سیستم‌عامل خاصی برای اجرای برنامه‌ها آغاز خواهد کرد. به ما گفته شد که این ساختار بسیاری از مشکلات مقیاس پذیری را حل می کند. در واقع همه چیز متفاوت است.
• در حالی که بسیاری بدون سرور را یک ایده جدید می‌دانند، ریشه‌های آن را می‌توان به سال 2006 با ظهور Zimki PaaS و Google App Engine که هر دو از معماری بدون سرور استفاده می‌کنند، جستجو کرد.
• چهار دلیل وجود دارد که انقلاب بدون سرور متوقف شده است، از پشتیبانی محدود زبان برنامه نویسی گرفته تا مشکلات عملکرد.
• محاسبات بدون سرور آنقدرها هم بی فایده نیست. اصلا. با این حال، آنها را نباید جایگزین مستقیمی برای سرورها در نظر گرفت. برای برخی از برنامه ها می توانند ابزار مفیدی باشند.

سرور مرده، زنده باد سرور!

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

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

برخی از وعده های مدل های بدون سرور قطعا محقق شده است، اما نه همه. همه نه.

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

چیزی که متخصصان محاسبات بدون سرور وعده داده بودند

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

برای کسانی که با این اصطلاح آشنا نیستند، در اینجا یک تعریف سریع وجود دارد. محاسبات بدون سرور، معماری را تعریف می‌کند که در آن برنامه‌ها (یا بخش‌هایی از برنامه‌ها) بر حسب تقاضا در محیط‌های زمان اجرا که معمولاً از راه دور میزبانی می‌شوند، اجرا می‌شوند. علاوه بر این، سیستم های بدون سرور را می توان در خانه میزبانی کرد. ایجاد سیستم‌های بدون سرور انعطاف‌پذیر یکی از دغدغه‌های اصلی مدیران سیستم و شرکت‌های SaaS در چند سال گذشته بوده است، زیرا (ادعا می‌شود) این معماری چندین مزیت کلیدی را نسبت به مدل مشتری-سرور «سنتی» ارائه می‌دهد:

1. مدل‌های بدون سرور به کاربران نیازی ندارند که سیستم‌عامل‌های خود را حفظ کنند یا حتی برنامه‌های سازگار با سیستم‌عامل‌های خاص ایجاد کنند. در عوض، توسعه‌دهندگان کد مشترک ایجاد می‌کنند، آن را در یک پلتفرم بدون سرور آپلود می‌کنند و اجرای آن را تماشا می‌کنند.
2. منابع در چارچوب‌های بدون سرور معمولاً در دقیقه (یا حتی ثانیه) صورت‌حساب می‌شوند. این بدان معناست که مشتریان فقط برای زمانی که کد را اجرا می کنند پرداخت می کنند. این به خوبی با یک ماشین مجازی ابری سنتی مقایسه می شود، که در آن دستگاه بیشتر اوقات بیکار است، اما شما باید هزینه آن را بپردازید.
3. مشکل مقیاس پذیری نیز حل شد. منابع در چارچوب‌های بدون سرور به‌صورت پویا تخصیص داده می‌شوند تا سیستم بتواند به راحتی با افزایش ناگهانی تقاضا کنار بیاید.

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

آیا این واقعا یک ایده جدید است؟

در واقع این ایده جدید نیست. مفهوم اجازه دادن به کاربران برای پرداخت فقط برای زمانی که کد در حال اجرا است، از زمان معرفی آن وجود داشته است Zimki PaaS در سال 2006، و تقریباً در همان زمان Google App Engine راه حل بسیار مشابهی را ارائه کرد.

در واقع، آنچه ما اکنون مدل «بدون سرور» می‌نامیم، قدیمی‌تر از بسیاری از فناوری‌هایی است که اکنون «بومی ابر» نامیده می‌شوند و تقریباً همان چیزها را ارائه می‌دهند. همانطور که اشاره شد، مدل‌های بدون سرور اساساً فقط توسعه‌ای از مدل کسب‌وکار SaaS هستند که برای دهه‌ها وجود داشته است.

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

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

مشکلات مدل های بدون سرور

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

از همین رو.

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

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

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

این یکی از مزایای کلیدی مدل بدون سرور را تضعیف می کند.

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

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

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

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

کارایی

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

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

البته راه های مختلفی برای حل این موضوع وجود دارد. یکی از آنها این است که ویژگی‌ها را برای هر زبان ابری که پلتفرم بدون سرور شما روی آن اجرا می‌کند، بهینه کنید، اما این تا حدودی این ادعا را که این پلتفرم‌ها «چابک» هستند، تضعیف می‌کند.

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

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

شما نمی توانید کل برنامه ها را اجرا کنید

در نهایت، شاید مهمترین دلیلی که چرا معماری های بدون سرور به این زودی جایگزین مدل های سنتی نمی شوند: آنها (معمولا) نمی توانند کل برنامه ها را اجرا کنند.

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

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

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

انقلاب پاینده باد؟

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

منبع: www.habr.com