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

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

توسعه ابری چیست؟

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

مقیاس‌پذیری: برنامه‌های ابری بومی را می‌توان به راحتی برای پاسخگویی به تقاضای متغیر مقیاس‌بندی کرد.

انعطاف‌پذیری: برنامه‌های ابری بومی را می‌توان به سرعت و به آسانی برای برآورد نیازهای جدید توسعه و تغییر داد.

خودکارسازی: بسیاری از وظایف مربوط به مدیریت برنامه‌های ابری بومی را می‌توان خودکار کرد، که این امر باعث صرفه‌جویی در وقت و هزینه می‌شود.

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

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

معنای توسعه ابری نسل پنجم شبکه‌های ارتباطی برای معماران نرم‌افزار چیست؟

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

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

قابلیت اطمینان: ارائه دهندگان ابر عمومی به دلیل ارائه خدمات قابل اعتماد و فناوری‌های بازیابی فاجعه شناخته شده‌اند که می‌تواند انعطاف‌پذیری سیستم‌های ابری مبتنی بر نسل پنجم شبکه‌های ارتباطی را بهبود بخشد. معماران نسل پنجم شبکه‌های ارتباطی قادر هستند معماری‌های مبتنی بر استفاده از سرویس‌های ابری ایجاد می‌کنند تا نیازهای شرکت‌ها در راستای قابلیت اطمینان پاسخ دهند. به بیان دقیق‌تر، تضمین می‌دهند که در دسترس بودن در وضعیت 99.99999% قرار دارد.

انعطاف‌پذیری: توسعه‌دهندگان آزادی استفاده از سرویس‌های ابری، رابط‌های کاربری برنامه‌نویسی (API) و ابزارهای شخص ثالث را به دست می‌آورند که امکان توسعه سریع‌تر را فراهم می‌کند. البته، هر بار که توسعه‌دهندگان از برخی سرویس‌های یک ارائه‌دهنده خاص استفاده می‌کنند، همیشه به وابستگی به آن ارائه‌دهنده فکر می‌کنند (Cloud Lock-in).

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

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

پیامدهای راه‌حل‌های اختصاصی سخت‌افزاری نسل پنجم شبکه‌های ارتباطی برای معماران نرم‌افزار چیست؟

در زیر به برخی از چالش‌های کلیدی راه‌حل‌های 5G Core که برای سخت‌افزارهای اختصاصی توسعه یافته‌اند اشاره می‌کنیم:

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

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

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

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

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

اشتباهات رایج معماران نرم‌افزار در طراحی برنامه‌های ابری

هنگام طراحی شبکه‌های نسل پنجم شبکه‌های ارتباطی مبتنی بر ابر، برخی جنبه‌ها ممکن است مورد توجه کافی قرار نگیرند یا نادیده گرفته شوند:

بهینه‌سازی برنامه‌ها یا حجم کاری: محدودیت‌هایی در منابع مورد نیاز برای ارائه خدمات مرکزی نسل پنجم شبکه‌های ارتباطی وجود دارد. به طور معمول، اگر راه‌حلی به حافظه بیشتری نیاز داشته باشد، نمونه‌های جدیدی با حافظه بیشتر ایجاد می‌شود. اگر پردازنده مرکزی (CPU) بیشتری مورد نیاز باشد، نمونه‌های جدید اضافه می‌شوند یا پردازنده بیشتری به نمونه‌های موجود اضافه می‌شود. بنابراین، به طور موثر به جای بهینه‌سازی برنامه، منابع جدیدی برای رفع نیازها اضافه می‌شوند.

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

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

اشتباهات رایج معماران در طراحی برنامه‌های ابری

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

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

عملکرد: عملکرد ابعاد مختلفی دارد. یکی از آن‌ها عملکرد صفحه‌ی کنترل (control plane) و دیگری عملکرد صفحه‌ی کاربر (user plane) است. نکته قابل توجه این است که امکان بروز نوسانات عملکردی با ارائه‌دهندگان مختلف ابر و نوع استقرار انتخاب شده توسط اپراتورها وجود دارد. یک محیط ابری معمولی ممکن است دچار نوسانات در تاخیر شبکه، رقابت بر سر منابع و زیرساخت مشترک شود که می‌تواند بر عملکرد و قابلیت اطمینان شبکه مرکزی تاثیر بگذارد. در برخی موارد، سرویس‌ها ممکن است محدودیت‌هایی در استفاده داشته باشند و اگر نیاز به راه‌حلی در ارتباط با فراخوانی‌های API وجود داشته باشد، شاهد افت عملکرد و خرابی واسط‌های برنامه‌نویسی کاربردی باشیم.

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

 بهره‌برداری خاص از پروتکل: تابع صفحه‌ی کاربر (UPF) سرنام User Plane Function  و تابع مدیریت جلسه (SMF) سرنام Session Management Function از طریق رابط N4 با یکدیگر ارتباط برقرار می‌کنند. رابط N4 از پروتکل PFCP برای پیکربندی UPF استفاده می‌کند. نکته قابل توجه این است که PFCP روی پروتکل انتقال UDP کار می‌کند و هنگامی که UPF در یک سایت از راه دور قرار می‌گیرد، احتمال تاخیر قابل توجهی وجود دارد. همین مورد در ارتباط با gNodeB زمانی که در منطقه راه دور قرار گرفته باشد و تابع مدیریت دسترسی (AMF) سرنام Access Management Function  در ابر قرار داشته باشد، صادق است. بنابراین، تاخیر و گاهی اوقات ارسال مجدد بسته‌ها باید در نظر گرفته شود، اما اغلب نادیده گرفته می‌شود. در نظر گرفتن این عوامل در طول توسعه برنامه‌های ابری می‌تواند به توسعه‌دهندگان کمک کند تا راه‌حل‌های انعطاف‌پذیرتر، مقیاس‌پذیرتر و مقرون به صرفه‌تری بسازند که نیازهای در حال تکامل سازمان‌ها و کاربران نهایی آن‌ها را برآورده کند.

آنچه یک اپراتور قبل از استقرار نسل پنجم شبکه‌های ارتباطی مبتنی بر ابر باید بداند

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

سهولت استقرار: کل فرآیند استقرار باید بدون دخالت دستی (zero touch) انجام شود تا هزینه‌های عملیاتی کاهش یابد. استقرار نسل پنجم شبکه‌های ارتباطی مرکزی نباید به نقاط تماس متعدد نیاز داشته باشد. همچنین، انتخاب مدل استقرار با موقعیت‌یابی توابع شبکه و ظرفیت استقرار باید امکان‌پذیر باشد.

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

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

وابستگی به ارائه‌دهنده ابر: اپراتورها باید بررسی کنند که آیا راه‌حل نسل پنجم شبکه‌های ارتباطی ارائه شده را می‌توان با هر ارائه‌دهنده ابری دیگری مستقر کرد یا اینکه به یک ارائه‌دهنده خاص وابسته است.

کلام آخر

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

بخوانید : هر آن چیزی که باید درباره اترنت (Ethernet) بدانید