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

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

باورهای غلط در مورد فناوری های بدون سرور

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

اصل اصلی بدون سرور این است که شما نیازی به نگرانی در مورد مدیریت یا افزایش زیرساخت خود ندارید، شما فقط برای آنچه استفاده می کنید هزینه می پردازید. بسیاری از سرویس ها با این معیارها مطابقت دارند - AWS DynamoDB، S3، SNS یا SQS، Graphcool، Auth0، Now، Netlify، Firebase و بسیاری دیگر. به طور کلی، بدون سرور به معنای استفاده از تمامی قابلیت های رایانش ابری بدون نیاز به مدیریت و بهینه سازی زیرساخت به منظور مقیاس بندی است. همچنین به این معنی است که امنیت در سطح زیرساخت دیگر مشکل شما نیست، که با توجه به دشواری و پیچیدگی رعایت استانداردهای امنیتی یک مزیت بزرگ است. در نهایت، نیازی به خرید زیرساخت های ارائه شده در اختیارتان نیست.

بدون سرور را می توان یک "وضعیت ذهن" در نظر گرفت: یک ذهنیت خاص در هنگام طراحی راه حل ها. از رویکردهایی که نیاز به نگهداری زیرساخت‌ها دارند اجتناب کنید. با رویکرد بدون سرور، ما زمان صرف حل مشکلاتی می کنیم که مستقیماً بر پروژه تأثیر می گذارد و برای کاربران ما ارزش ایجاد می کند: ایجاد منطق تجاری قوی، توسعه رابط های کاربر، و توسعه API های پاسخگو و قابل اعتماد.

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

برخی از افراد در هنگام توسعه برنامه های ابری با وابستگی به فروشنده گیج می شوند. همین امر در مورد فناوری های بدون سرور نیز صادق است و بعید است که این نتیجه یک تصور اشتباه باشد. در تجربه ما، ساخت برنامه‌های بدون سرور در AWS، همراه با توانایی AWS Lambda برای جمع‌آوری سایر سرویس‌های AWS، بخشی از چیزی است که معماری‌های بدون سرور را بسیار عالی می‌کند. این مثال خوبی از هم افزایی است، زمانی که نتیجه یک ترکیب بیشتر از مجموع اجزای آن باشد. تلاش برای جلوگیری از قفل شدن فروشنده می تواند منجر به مشکلات بیشتر شود. هنگام کار با کانتینرها، مدیریت لایه انتزاعی خود بین ارائه دهندگان ابر آسان تر است. اما وقتی صحبت از راه‌حل‌های بدون سرور به میان می‌آید، تلاش به ثمر نمی‌رسد، به خصوص اگر از همان ابتدا مقرون به صرفه بودن را در نظر بگیرید. مطمئن شوید که فروشندگان چگونه خدمات ارائه می دهند. برخی از خدمات تخصصی به نقاط ادغام با سایر فروشندگان متکی هستند و ممکن است اتصال plug-and-play خارج از جعبه را ارائه دهند. ارائه یک تماس Lambda از یک نقطه پایانی API دروازه آسان تر از پراکسی کردن درخواست به یک کانتینر یا نمونه EC2 است. Graphcool امکان پیکربندی آسان با استفاده از Auth0 را فراهم می کند، که آسان تر از استفاده از ابزارهای احراز هویت شخص ثالث است.

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

در نظر گرفتن:

• به چه خدماتی نیاز دارید و چرا.
• ارائه دهندگان ابری چه خدماتی ارائه می دهند و چگونه می توانید با استفاده از راه حل انتخابی FaaS آنها را ترکیب کنید.
• چه زبان های برنامه نویسی پشتیبانی می شوند (تایپ پویا یا ایستا، کامپایل یا تفسیر شده، معیارها چیست، عملکرد شروع سرد چگونه است، اکوسیستم منبع باز چیست و غیره).
• الزامات امنیتی شما چیست (SLA، 2FA، OAuth، HTTPS، SSL، و غیره).
• چگونه چرخه های توسعه CI/CD و نرم افزار خود را مدیریت کنید.
• از کدام راه حل های زیرساخت به عنوان کد می توانید استفاده کنید؟

اگر یک برنامه موجود را گسترش می دهید و عملکردهای بدون سرور را به صورت تدریجی اضافه می کنید، این ممکن است تا حدودی قابلیت های موجود را محدود کند. با این حال، تقریباً تمام فناوری‌های بدون سرور نوعی API (از طریق REST یا صف پیام) ارائه می‌کنند که به شما امکان می‌دهد برنامه‌های افزودنی مستقل از هسته برنامه و با ادغام آسان ایجاد کنید. به دنبال سرویس هایی با API های واضح، اسناد خوب و جامعه قوی باشید، و نمی توانید اشتباه کنید. سهولت ادغام اغلب می تواند یک معیار کلیدی باشد و احتمالا یکی از دلایل اصلی موفقیت AWS از زمان عرضه لامبدا در سال 2015 است.

چه زمانی بدون سرور مفید است؟

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

به لطف صرفه جویی در هزینه و سهولت مقیاس‌بندی، راه‌حل‌های بدون سرور به طور یکسان برای سیستم‌های داخلی و خارجی، تا یک برنامه وب با مخاطبان چند میلیون دلاری قابل استفاده هستند. حساب ها به جای یورو به سنت سنجیده می شوند. اجاره ساده ترین نمونه AWS EC2 (t1.micro) برای یک ماه 15 یورو هزینه خواهد داشت، حتی اگر کاری با آن انجام ندهید (چه کسی فراموش کرده است آن را خاموش کند؟!). در مقایسه، برای دستیابی به این سطح از هزینه در مدت زمان مشابه، باید یک لامبدا 512 مگابایتی را برای 1 ثانیه و تقریباً 3 میلیون بار اجرا کنید. و اگر از این ویژگی استفاده نکنید، هیچ هزینه ای پرداخت نمی کنید.

از آنجایی که بدون سرور اساساً رویداد محور است، افزودن زیرساخت بدون سرور به سیستم های قدیمی نسبتاً آسان است. به عنوان مثال، با استفاده از AWS S3، Lambda، و Kinesis، می توانید یک سرویس تجزیه و تحلیل برای یک سیستم خرده فروشی قدیمی ایجاد کنید که می تواند داده ها را از طریق API دریافت کند.

اکثر پلتفرم های بدون سرور از چندین زبان پشتیبانی می کنند. اغلب اینها Python، JavaScript، C#، Java و Go هستند. به طور معمول، همه زبان ها هیچ محدودیتی در استفاده از کتابخانه ها ندارند، بنابراین می توانید از کتابخانه های منبع باز مورد علاقه خود استفاده کنید. با این حال، توصیه می‌شود از وابستگی‌ها بیش از حد استفاده نکنید تا عملکردهای شما بهینه انجام شود و مزایای مقیاس‌پذیری عظیم برنامه‌های بدون سرور شما را از بین نبرد. هر چه تعداد بسته های بیشتری در ظرف بارگیری شود، شروع سرد بیشتر طول می کشد.

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

اگرچه AWS منتشر شد پایگاه داده SQL بدون سرور Aurora بدون سروربا این حال، پایگاه‌های داده SQL برای این نوع استفاده ایده‌آل نیستند زیرا برای انجام تراکنش‌ها به اتصالات تکیه می‌کنند، که وقتی ترافیک زیادی در AWS Lambda وجود دارد، می‌تواند به سرعت به یک گلوگاه تبدیل شود. بله، توسعه دهندگان مدام در حال بهبود شفق سرور بدون سرور هستند و شما باید آن را آزمایش کنید، اما امروزه راه حل های NoSQL مانند DynamoDB. با این حال، شکی نیست که این وضعیت خیلی زود تغییر خواهد کرد.

این جعبه ابزار همچنین محدودیت های زیادی را اعمال می کند، به خصوص در زمینه آزمایش محلی. اگرچه راه‌حل‌هایی مانند Docker-Lambda، DynamoDB Local و LocalStack وجود دارد، اما نیاز به کار پر زحمت و مقدار قابل توجهی پیکربندی دارند. با این حال، همه این پروژه ها به طور فعال در حال توسعه هستند، بنابراین فقط زمان زیادی است که ابزارها به سطح مورد نیاز ما برسند.

تاثیر فناوری های بدون سرور بر چرخه توسعه

از آنجایی که زیرساخت شما به سادگی پیکربندی است، می‌توانید کد را با استفاده از اسکریپت‌ها، مانند اسکریپت‌های پوسته، تعریف و اجرا کنید. یا می توانید به راه حل های کلاس پیکربندی به عنوان کد مانند AWS CloudFormation. اگرچه این سرویس پیکربندی را برای همه مناطق ارائه نمی دهد، اما به شما امکان می دهد منابع خاصی را برای استفاده به عنوان توابع Lambda تعریف کنید. یعنی در جایی که CloudFormation شما را از کار می اندازد، می توانید منبع خود (تابع لامبدا) را بنویسید که این شکاف را برطرف می کند. به این ترتیب می توانید هر کاری انجام دهید، حتی وابستگی ها را خارج از محیط AWS خود پیکربندی کنید.

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

DevOps کمتر نگران آن هستند زیرا آنها فقط باید مطمئن شوند که توسعه دهندگان پیکربندی صحیح را دارند. دیگر خبری از نمونه‌های مدیریتی، متعادل‌کننده‌ها یا گروه‌های امنیتی نیست. بنابراین، اصطلاح NoOps به طور فزاینده‌ای مورد استفاده قرار می‌گیرد، اگرچه هنوز مهم است که بتوان زیرساخت را پیکربندی کرد، به خصوص وقتی صحبت از پیکربندی IAM و بهینه‌سازی منابع ابری می‌شود.

ابزارهای نظارت و دید بسیار قدرتمندی مانند Epsagon، Thundra، Dashbird و IOPipe وجود دارد. آنها به شما امکان می دهند وضعیت فعلی برنامه های بدون سرور را نظارت کنید، گزارش ها و ردیابی ها را ارائه دهید، معیارهای عملکرد و تنگناهای معماری را ثبت کنید، تجزیه و تحلیل و پیش بینی هزینه را انجام دهید و موارد دیگر. آنها نه تنها به مهندسان، توسعه دهندگان و معماران DevOps یک دید جامع از عملکرد برنامه ارائه می دهند، بلکه مدیران را قادر می سازند تا در زمان واقعی، ثانیه به ثانیه هزینه منابع و پیش بینی هزینه را مشاهده کنند. سازماندهی این امر با یک زیرساخت مدیریت شده بسیار دشوارتر است.

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

در حالی که ابزارسازی می‌تواند بهتر باشد (هر روز در حال بهبود است)، توسعه‌دهندگان می‌توانند روی پیاده‌سازی منطق کسب‌وکار و چگونگی توزیع بهترین پیچیدگی برنامه در میان سرویس‌های مختلف در معماری تمرکز کنند. مدیریت برنامه های بدون سرور مبتنی بر رویداد و توسط ارائه دهنده ابر انتزاعی می شود (به عنوان مثال، رویدادهای SQS، S3 یا جریان های DynamoDB). بنابراین، توسعه‌دهندگان برای واکنش به رویدادهای خاص فقط باید منطق تجاری بنویسند، و لازم نیست نگران بهترین نحوه پیاده‌سازی پایگاه‌های داده و صف‌های پیام یا نحوه کار بهینه با داده‌ها در حافظه‌های سخت‌افزاری خاص باشند.

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

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

هیچ راه خاصی برای ساخت برنامه های بدون سرور وجود ندارد. و همچنین مجموعه ای از خدمات برای این کار. پیشرو در میان راه حل های قدرتمند بدون سرور امروزه AWS است، اما به آن توجه کنید Google Cloud, زمان и آتش نشانی. اگر از AWS استفاده می‌کنید، می‌توانیم به عنوان رویکردی برای جمع‌آوری برنامه‌ها توصیه کنیم مدل برنامه بدون سرور (SAM)، به خصوص هنگام استفاده از سی شارپ، زیرا ویژوال استودیو ابزارهای عالی دارد. SAM CLI می‌تواند تمام کارهایی که ویژوال استودیو انجام دهد را انجام دهد، بنابراین اگر به یک IDE یا ویرایشگر متن دیگری بروید، چیزی از دست نخواهید داد. البته SAM با زبان های دیگر نیز کار می کند.

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

برای آزمایش محلی، ابزارهای منبع باز Docker-Lambda، Serverless Local، DynamoDB Local و LocalStack مناسب هستند. فناوری‌های بدون سرور همچنان در مراحل اولیه توسعه هستند، بنابراین باید هنگام تنظیم سناریوهای آزمایش پیچیده سخت کار کنید. با این حال، به سادگی استقرار پشته در محیط و آزمایش آن در آنجا بسیار ارزان است. و نیازی نیست که یک کپی محلی دقیق از محیط های ابری خود تهیه کنید.

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

از زبان های برنامه نویسی مناسب برای کارهای خاص استفاده کنید. زبان های مختلف مزایا و معایب خاص خود را دارند. معیارهای زیادی وجود دارد، اما جاوا اسکریپت، پایتون و سی شارپ (.NET Core 2.1+) از نظر عملکرد AWS Lambda پیشتاز هستند. AWS Lambda اخیراً یک Runtime API معرفی کرده است که به شما امکان می دهد زبان و محیط زمان اجرا مورد نظر خود را مشخص کنید، بنابراین آزمایش کنید.

اندازه بسته های استقرار را کوچک نگه دارید. هرچه کوچکتر باشند، سریعتر بارگذاری می شوند. از استفاده از کتابخانه های بزرگ خودداری کنید، به خصوص اگر از چند ویژگی از آنها استفاده می کنید. اگر در جاوا اسکریپت برنامه نویسی می کنید، از ابزارهای ساخت مانند Webpack برای بهینه سازی ساخت خود استفاده کنید و فقط مواردی را که واقعاً نیاز دارید را در آن گنجانده باشید. NET Core 3.0 شامل QuickJit و Tiered Compilation است که عملکرد را بهبود می بخشد و به شروع سرد کمک زیادی می کند.

وابستگی توابع بدون سرور به رویدادها می تواند در ابتدا هماهنگی منطق تجاری را دشوار کند. صف های پیام و ماشین های حالت می توانند در این زمینه فوق العاده مفید باشند. توابع لامبدا می توانند یکدیگر را فراخوانی کنند، اما این کار را فقط در صورتی انجام دهید که انتظار پاسخ ("آتش و فراموش کردن") را نداشته باشید - نمی خواهید برای منتظر ماندن برای تکمیل عملکرد دیگر صورتحساب دریافت کنید. صف های پیام برای جداسازی قطعات منطق تجاری، مدیریت تنگناهای برنامه و پردازش تراکنش ها (با استفاده از صف های FIFO) مفید هستند. توابع AWS Lambda را می‌توان به صف‌های SQS به‌عنوان صف‌های پیام گیر کرده که پیام‌های ناموفق را برای تجزیه و تحلیل بعدی ردیابی می‌کند، اختصاص داد. توابع مرحله ای AWS (ماشین های حالت) برای مدیریت فرآیندهای پیچیده ای که نیاز به زنجیره توابع دارند بسیار مفید هستند. به جای اینکه یک تابع Lambda تابع دیگری را فراخوانی کند، توابع Step می توانند انتقال حالت ها را هماهنگ کنند، داده ها را بین توابع ارسال کنند و وضعیت جهانی توابع را مدیریت کنند. این به شما امکان می دهد شرایط امتحان مجدد را تعریف کنید، یا در صورت بروز یک خطای خاص چه کاری انجام دهید - ابزاری بسیار قدرتمند در شرایط خاص.

نتیجه

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

منبع: www.habr.com