CNCF یا Cloud Native Computing Foundation یک سازمان مستقل و عام المنفعه (non-profit) است که به عنوان یک خانه مشترک برای بسیاری از پرطرفدارترین و سریعترین پروژههای متنباز در حوزه فناوریهای ابری عمل میکند. این سازمان به هیچ شرکت یا فروشنده خاصی وابسته نیست و هدف اصلی آن ترویج و توسعهی فناوریهای بر پایه ابر است. پروژههای متنباز در حال رشد، از جمله Kubernetes، Prometheus و Envoy و Helm و .. بسیاری دیگر در ان قرار دارند . این پروژهها ستون فقرات زیرساخت فناوری جهانی را تشکیل میدهند که توسط بنیاد لینوکس (Linux Foundation) میزبانی می شوند .
تاریخچه CNCF
در سال ۲۰۱۴، گوگل یک پروژه داخلی به نام Borg را که برای ارکستراسیون کانتینرها استفاده میکرد، متنباز کرد. گوگل، بدون داشتن مکانی برای لانچ پروژه، با بنیاد لینوکس همکاری کرد تا بنیاد محاسبات بومی ابری (CNCF) را ایجاد کند، که توسعه و همکاری Kubernetes و سایر راهحلهای کلود نیتیو را تشویق میکرد. پیادهسازی Borg با استفاده از Go بازنویسی شد، به Kubernetes تغییر نام داد و به عنوان پروژه آغازین اهدا شد. از همان ابتدا مشخص شد که Kubernetes فقط آغاز است و یک دسته پروژه جدید به CNCF خواهند پیوست و عملکرد Kubernetes را گسترش میدهند.
برخی از پروژه های CNCF
ارکستراسیون (Orchestrations)
Kubernetes : کوبرنتیز بهطور خودکار استقرار، مقیاسبندی و مدیریت برنامههای کانتینریزه را انجام میدهد، با تأکید بر خودکارسازی و پیکربندی اعلامی. این به معنای helmsman در یونانی باستان است. Kubernetes کانتینرها را ارکستر میکند تا بستههای میکروسرویسهای قابل حمل و ماژولار شوند. Kubernetes یک لایه انتزاع اضافه میکند، کانتینرها را در پادها گروهبندی میکند. Kubernetes به مهندسان کمک میکند تا بار کاری را برنامهریزی کنند و به کانتینرها اجازه میدهد تا در محیطهای چند ابری در مقیاس استقرار یابند. با تایید شدن، Kubernetes به یک توده بحرانی از پذیرش رسیده است. در یک نظرسنجی اخیر CNCF، بیش از ۴۰٪ از پاسخدهندگان از شرکتهای سازمانی Kubernetes را در فراییند تولید نرم افزار اجرا میکنند.
توسعه نرم افزار
Helm : Helm یک مدیر بسته برنامه است که به کاربران اجازه میدهد تا برنامههای Kubernetes (که به عنوان نمودارها شناخته میشوند) را به راحتی پیدا کنند، به اشتراک بگذارند، نصب کنند و ارتقا دهند. این به کاربران نهایی کمک میکند تا برنامههای موجود (از جمله MySQL، Jenkins، Artifactory و غیره) را با استفاده از KubeApps Hub که نمودارها را از مخازن پایدار و انکوباتور نگهداری شده توسط جامعه Kubernetes نمایش میدهد، مستقر کنند. با Helm میتوانید تمام پروژههای دیگر CNCF را که روی Kubernetes اجرا میشوند نصب کنید. Helm همچنین میتواند به سازمانها اجازه دهد تا برنامههای سفارشی یا میکروسرویسها را برای Kubernetes ایجاد و سپس مستقر کنند. این شامل ایجاد فهرستهای YAML با مقادیر عددی نامناسب برای استقرار در محیطهای مختلف یا خطوط لوله CI/CD میشود. Helm نمودارهای منفردی ایجاد میکند که میتوانند بر اساس تغییرات برنامه یا پیکربندی نسخه بندی شوند، در محیطهای مختلف مستقر شوند و در بین سازمانها به اشتراک گذاشته شوند.
مانیتورینگ (Monitoring)
Prometheus (تایید شده) – پس از کوبرنتیز ، Prometheus دومین پروژه بود که به CNCF پیوست و دومین (و تاکنون آخرین) پروژهای بود که فارغالتحصیلی کرد. این یک راهحل نظارتی است که برای محیطهای ابری و کانتینری پویا مناسب است. این الهام گرفته از سیستم نظارت گوگل، Borgman بود. Prometheus یک سیستم مبتنی بر کشیدن است – پیکربندیهای آن تصمیم میگیرند که چه زمانی و چه چیزی را خراش دهند. این برخلاف سایر سیستمهای نظارتی با استفاده از رویکرد مبتنی بر فشار است که در آن عامل نظارت در گرهها اجرا میشود. Prometheus متریکهای خراشیده را در یک TSDB ذخیره میکند. Prometheus به شما امکان میدهد تا نمودارهای معنادار را در داخل داشبورد Grafana با زبانهای پرس و جو قدرتمند، مانند PromQL ایجاد کنید. همچنین میتوانید هشدارها را تولید و به مقصدهای مختلف، مانند Slack و ایمیل، با استفاده از مدیر هشدار داخلی ارسال کنید.
معماری Cloud Native چیست؟
معماری Cloud Native یک رویکرد نوآورانه در توسعه نرمافزار است که به طور کامل از مدل محاسبات ابری بهرهبرداری میکند. این رویکرد با ترکیب روشهای خدمات ابری، شیوههای مدیریت و اتوماسیون DevOps و اصول توسعه نرمافزار، تمامی لایههای فناوری اطلاعات را شامل شبکه، سرورها، مراکز داده، سیستمعاملها و فایروالها را انتزاع میکند.
این رویکرد به سازمانها اجازه میدهد تا برنامهها را به عنوان خدمات چندگانه با استفاده از معماری میکروسرویسها بسازند و آنها را بر روی پلتفرمهای پویا و هماهنگشده اجرا کنند. برنامههایی که بر اساس معماری برنامههای کلود نیتیو ساخته میشوند، قابل اعتماد، مقیاسپذیر، با عملکرد بالا و زمان عرضه سریع به بازار هستند.
کلود نیتیو معماری به طراحی برنامهها یا خدماتی اشاره دارد که به طور خاص برای وجود در ابر، به جای زیرساختهای سنتی درونمحلی، ساخته شدهاند. یک معماری کلود نیتیو موفق باید به راحتی قابل نگهداری و پشتیبانی توسط یک فضای ابری نسل بعد باشد، در حالی که همچنین مقرون به صرفه و خود ترمیم باشد. در مقایسه با سیستمهای قدیمی، معماریهای کلود نیتیو دارای سطح بالاتری از انعطافپذیری هستند، بدون اینکه به سرورهای فیزیکی متکی باشند.
اینجاست که میکروسرویسها و توابع بدون سرور میتوانند نقش بزرگ و مهمی ایفا کنند. میکروسرویسها هسته اصلی معماری برنامههای کلود نیتیو هستند و به یک ابزار کلیدی برای شرکتهایی تبدیل شدهاند که به سمت ابر حرکت میکنند. میکروسرویسها یک برنامه را به چندین سرویس مستقل تقسیم میکنند که هر کدام عملکرد خاصی را انجام میدهند. بسیاری از شرکتهای نرمافزاری از میکروسرویسها استفاده میکنند زیرا از DevOps پشتیبانی میکنند، انعطافپذیری را فعال میکنند، مقیاسپذیری را بهبود میبخشند و در عین حال هزینهها را کاهش میدهند. میکروسرویسهای کلود نیتیو با استفاده از APIها با یکدیگر ارتباط برقرار میکنند و از معماری مبتنی بر رویداد استفاده میکنند که به بهبود عملکرد کلی هر برنامه کمک میکند. سرویسهای کلود نیتیو Oracle از نقشه راه CNCF پیروی میکنند تا سفر را سادهتر کنند و برای شرکتها آسانتر کنند تا شروع به ساخت، استقرار و مدیریت برنامههای مدرن کلود نیتیو کنند.
از خدمات کلود نیتیو برای ارائه نرمافزار شگفتانگیز استفاده کنید
کشف کنید که چگونه میتوانید از پتانسیل کامل کلود نیتیو برای ساخت سریع و آسان برنامههای ابری مدرن مقاوم، قابل مدیریت و مقیاسپذیر بهرهبرداری کنید.
حرکت به سمت فناوریهای کلود نیتیو، توسعه نرمافزار و مدلهای تجاری را به طور دائمی تغییر داده است، زیرا امکان بهینهسازی تجربه مشتری در سراسر پلتفرم یک سازمان را فراهم میکند. مدتها پیش، زیرساخت فناوری اطلاعات بسیاری از سازمانها «دوستدار ابر» بود. تیمهای فناوری اطلاعاتی که به ابر مهاجرت میکنند، اگر سرمایهگذاری خود را با ایجاد برنامههای کلود نیتیو نیز به حداکثر نرسانند، خود را در معرض یک رقابت شدید قرار میدهند. برای اینکه شرکت شما هم زنده بماند و هم خود را از رقبای خود متمایز کند، تنظیم و تکرار سریع یک ضرورت تجاری است – و زیرساخت ابری دارای انعطافپذیری و قابلیتهای درخواستی برای انتقال هر کسب و کاری به کلود نیتیو است.
چرا باید به سراغ معماری کلود نیتیو (Cloud Native) برویم ؟
مزایای معماری کلود نیتیو عبارتاند از:
- هزینههای بهینهشده: کاهش هزینههای عملیاتی و زیرساخت.
- انتشار سریعتر: سرعت بخشیدن به فرآیند توسعه و استقرار برنامهها.
- مستقل از فروشنده: کاهش وابستگی به فروشندگان خاص و افزایش انعطافپذیری.
- فرهنگ DevOps: ترویج همکاری بین تیمهای توسعه و عملیات.
- مقیاسپذیری بالا: توانایی پاسخگویی به تغییرات در تقاضا.
- تجربه برتر مشتری: ارائه خدمات بهتر و سریعتر به مشتریان.
- تهیه خودکار: اتوماسیون فرآیندهای تهیه و پیکربندی.
- تسهیل تهیه فناوری اطلاعات: سادهسازی و تسریع فرآیندهای فناوری اطلاعات.
- بدون داون تایم : به لطف وجود ارکستریشن هایی مثل Kubernetes و کانتینیر ها فرایند دیلیور (Deliver ) کردن و به روزرسانی نرم افزار بدون وقفه انجام میشود .
چرخه عمر توسعه نرمافزار شتابگرفته (SDLC)
یک برنامه کلود نیتیو، یک محیط تحویل مداوم مبتنی بر DevOps را با خودکارسازی در سراسر چرخه عمر محصول تکمیل میکند، که سرعت و کیفیت را به جدول میآورد. تیمهای چندعملکردی، متشکل از اعضای طراحی، توسعه، آزمایش، عملیات و کسبوکار، در طول SDLC همکاری و کار یکپارچه میکنند.
با خطوط لوله CI/CD خودکار در بخش توسعه و زیرساخت مبتنی بر IaC یا Infrastructure as Code در بخش عملیات که به صورت هماهنگ کار میکنند، کنترل بهتری بر کل فرآیند وجود دارد که باعث میشود کل سیستم سریع، کارآمد و بدون خطا باشد. آنها همچنین شفافیت را در محیط حفظ میکنند. تمام این عناصر چرخه عمر توسعه نرمافزار را به طور قابل توجهی تسریع میکنند.
یک چرخه عمر توسعه نرمافزار (SDLC) به مراحل مختلف درگیر در توسعه یک محصول نرمافزاری اشاره دارد. یک SDLC معمولی شامل ۷ مرحله مختلف است.
۱. مرحله جمعآوری/برنامهریزی نیازها: جمعآوری اطلاعات در مورد مشکلات فعلی، نیازهای کسبوکار، درخواستهای مشتری و غیره.
۲. مرحله تحلیل: تعریف الزامات سیستم نمونه اولیه، تحقیق بازار برای نمونههای اولیه موجود، تجزیه و تحلیل نیازهای مشتری در مقابل نمونههای اولیه پیشنهادی و غیره.
۳. مرحله طراحی: تهیه طراحی محصول، اسناد مشخصات الزامات نرمافزار، خطوط راهنمای کدنویسی، پشته فناوری، فریمورکها و غیره.
۴. مرحله توسعه: نوشتن کد برای ساخت محصول طبق مشخصات و اسناد راهنما.
۵. مرحله آزمایش: آزمایش کد توسط توسعهدهندگان برای خطاها و باگها، ارزیابی کیفیت آن بر اساس سند SRS.
۶. مرحله استقرار: تهیه زیرساخت، استقرار نرمافزار در محیط تولید.
۷. مرحله عملیات و نگهداری: نگهداری محصول، رسیدگی به مسائل مشتری، نظارت بر عملکرد در مقابل معیارها و غیره.
تحویل و ارائه سریعتر به بازار
سرعت و کیفیت خدمات دو نیاز مهم در دنیای IT امروز که به سرعت در حال تکامل است، هستند. معماری برنامههای کلود نیتیو که با شیوههای DevOps تقویت شده است، به شما کمک میکند تا خطوط لوله تحویل مداوم را به راحتی بسازید و خودکار کنید تا نرمافزار را سریعتر و بهتر ارائه دهید. ابزارهای IaC امکان خودکارسازی تهیه زیرساخت در صورت تقاضا را فراهم میکنند، در حالی که به شما اجازه میدهند زیرساخت را در حال حرکت مقیاس کنید یا آن را پایین بیاورید. مدیریت ساده فناوری اطلاعات و کنترل بهتر بر کل چرخه عمر محصول، SDLC را تسریع میکند و به سازمانها امکان میدهد زمان سریعتری به بازار داشته باشند.
DevOps بر یک رویکرد مشتریمحور تمرکز دارد، جایی که تیمها مسئول کل چرخه عمر محصول هستند. در نتیجه، بهروزرسانیها و انتشارهای بعدی سریعتر و بهتر میشوند. کاهش زمان توسعه، تولید بیش از حد، مهندسی بیش از حد و بدهی فنی نیز میتواند هزینههای کلی توسعه را کاهش دهد. به طور مشابه، افزایش بهرهوری منجر به افزایش درآمد میشود.
در دسترس بودن بالا و انعطافپذیری
سیستمهای مدرن فناوری اطلاعات جایی برای خرابی ندارند. اگر محصول شما دچار خرابیهای مکرر شود، شما از کسبوکار خارج خواهید شد. با ترکیب معماری کلود نیتیو با میکروسرویسها و Kubernetes، میتوانید سیستمهای مقاوم و مقاوم در برابر خطا بسازید که خود ترمیم میشوند. در هنگام خرابی، برنامههای شما همچنان در دسترس خواهند بود زیرا میتوانید به سادگی سیستم معیوب را جدا کنید و برنامه را با چرخاندن خودکار سیستمهای دیگر اجرا کنید. در نتیجه، سازمانها میتوانند در دسترس بودن بالاتر، تجربه بهبودیافته مشتری و زمان فعالیت را به دست آورند.
هزینههای پایین
معماری برنامه کلود نیتیو با یک مدل پرداخت به ازای استفاده همراه است، به این معنی که سازمانهای درگیر فقط برای منابع استفاده شده هزینه میکنند در حالی که از اقتصاد مقیاس بهرهمند میشوند. با تبدیل CapEx به OpEx، کسبوکارها میتوانند سرمایهگذاریهای اولیه خود را برای کسب منابع توسعه تبدیل کنند. در مورد OpEx، محیط کلود نیتیو از فناوری کانتینریزه شدن مدیریت شده توسط نرمافزار متنباز Kubernetes استفاده میکند.
ابزارهای دیگر کلود نیتیو در بازار برای مدیریت کارآمد سیستم در دسترس هستند. با معماری بدون سرور، استانداردسازی زیرساخت، ابزارهای متنباز، هزینههای عملیاتی نیز کاهش مییابد که منجر به کاهش TCO میشود.
برنامههای خود را به API تبدیل کنید
امروزه، کسبوکارها نیاز دارند تا برنامههای جذاب برای مشتری ارائه دهند. محیطهای کلود نیتیو به شما امکان میدهند تا دادههای عظیم سازمانی را با برنامههای فرانتاند با استفاده از ادغام مبتنی بر API متصل کنید. از آنجایی که هر منبع فناوری اطلاعات در یک فضای ابری است و از API استفاده میکند، برنامه شما نیز به یک API تبدیل میشود. این نه تنها یک تجربه جذاب برای مشتری ارائه میدهد، بلکه به شما امکان میدهد از زیرساخت قدیمی خود استفاده کنید که آن را به عصر وب و موبایل برای برنامه کلود نیتیو خود گسترش میدهد.
مثال: فرض کنید یک فروشگاه آنلاین دارید. در معماری سنتی، ممکن است یک برنامه جداگانه برای مدیریت موجودی، یک برنامه دیگر برای پردازش سفارشات و برنامهای دیگر برای مدیریت مشتریان داشته باشید. با استفاده از معماری کلود نیتیو، میتوانید هر یک از این برنامهها را به عنوان یک سرویس مجزا (میکروسرویس) در نظر بگیرید و برای هر کدام یک API تعریف کنید. به این ترتیب، یک برنامه موبایل میتواند از طریق این APIها به اطلاعات موجودی دسترسی پیدا کند، سفارشات جدید ثبت کند و اطلاعات مشتری را بهروزرسانی کند.
به طور خلاصه، تبدیل برنامهها به API در معماری کلود نیتیو به شما امکان میدهد تا قابلیتهای خود را به صورت برنامهای در اختیار دیگران قرار دهید، به سرعت نوآوری کنید و به یک اکوسیستم بزرگتر از برنامهها و خدمات متصل شوید.
الگوهای معماری کلود نیتیو (Cloud Native)
به دلیل محبوبیت معماری برنامههای کلود نیتیو، چندین سازمان الگوهای طراحی و بهترین شیوههای مختلفی را برای تسهیل عملیات روانتر توسعه دادند. در اینجا الگوهای کلود نیتیو کلیدی برای نمودار معماری ابری آورده شده است:
پرداخت به ازای استفاده
در معماری ابری، منابع را به صورت مرکزی میزبانی کنید و آنها را از طریق اینترنت با استفاده از یک مدل پرداخت به ازای استفاده یا پرداخت به ازای مصرف ارائه دهید. مشتریان بر اساس استفاده از منابع خود هزینه پرداخت میکنند. این بدان معنی است که شما میتوانید منابع را در صورت نیاز مقیاس کنید، منابع را به هسته بهینه کنید. همچنین انعطافپذیری و انتخاب خدمات با نرخهای پرداخت مختلف را ارائه میدهد. به عنوان مثال، معماری بدون سرور به شما اجازه میدهد تا منابع را فقط زمانی که کد اجرا میشود، تهیه کنید، و اطمینان حاصل کنید که فقط زمانی پرداخت میکنید که برنامه شما فعال است.
زیرساخت خودسرویس
زیرساخت به عنوان یک سرویس (IaaS) یک ویژگی کلیدی معماری برنامه کلود نیتیو است.چه برنامهها را در یک محیط الاستیک، مجازی یا مشترک مستقر کنید، آنها به طور خودکار برای مطابقت با زیرساخت زیرین، مقیاس بالا و پایین برای تطبیق با بارهای کاری متغیر، تراز میشوند.
این بدان معنی است که شما نیازی به جستجو و دریافت مجوز از سرور، بار متوازن یا یک سیستم مدیریت مرکزی برای ایجاد، آزمایش یا استقرار منابع فناوری اطلاعات ندارید. در حالی که این زمان انتظار کاهش مییابد، مدیریت فناوری اطلاعات ساده میشود.
خدمات مدیریتشده
معماری ابری به شما امکان میدهد تا از خدمات مدیریتشده ابری به طور کامل بهرهبرداری کنید تا زیرساخت ابری را به طور کارآمد مدیریت کنید، درست از مهاجرت و پیکربندی تا مدیریت و نگهداری در حالی که زمان و هزینهها را به هسته بهینه میکنید. رفتار هر سرویس به عنوان یک چرخه عمر مستقل، مدیریت آنها را با استفاده از فرآیندهای چابک DevOps آسان میکند. میتوانید همزمان با چندین خط لوله CI/CD نیز کار کنید و آنها را به طور مستقل مدیریت کنید.
به عنوان مثال، AWS Fargate یک موتور محاسباتی بدون سرور است که به شما امکان میدهد برنامهها را بدون نیاز به مدیریت سرورها از طریق یک مدل پرداخت به ازای استفاده بسازید. Llambda یک ابزار دیگر برای همین منظور است. Amazon RDS به شما امکان میدهد پایگاههای داده رابطهای را در ابر بسازید، مقیاس کنید و مدیریت کنید. Cognito یک ابزار قدرتمند است که به شما کمک میکند احراز هویت، مجوزدهی و مدیریت کاربر را در تمام برنامههای ابری به طور ایمن مدیریت کنید. با کمک این ابزارها، میتوانید به راحتی یک محیط توسعه ابری را با حداقل هزینهها و تلاشها راهاندازی و مدیریت کنید.
متودولوژی ۱۲ فاکتوری (Factor 12-Methodology)
برای تسهیل همکاری بیدردسر بین توسعهدهندگان که روی همان برنامه کار میکنند و مدیریت کارآمد رشد ارگانیک پویای برنامه در طول زمان در حالی که هزینههای فرسایش نرمافزار را به حداقل میرسانند، توسعهدهندگان در Heroku یک متودولوژی ۱۲ فاکتوری را توسعه دادند که به سازمانها کمک میکند تا برنامهها را به راحتی در یک معماری برنامه کلود نیتیو بسازند و مستقر کنند.
نکات کلیدی این متودولوژی این است که برنامه باید از یک کد پایه واحد برای تمام استقرارها استفاده کند، با تمام وابستگیهای جدا شده از یکدیگر بستهبندی شود و کد پیکربندی ( یا فایل کانفیگ) از کد برنامه جدا شود.
فرآیندها باید بدون حالت باشند تا بتوانید آنها را به طور جداگانه اجرا، مقیاس و خاتمه دهید. به طور مشابه، باید خطوط لوله CI/CD خودکار را در حالی که فرآیندهای بدون حالت ساخت، انتشار و اجرا را به صورت جداگانه مدیریت میکنید، بسازید. یک توصیه کلیدی دیگر این است که برنامهها باید قابل دور ریختن باشند تا بتوانید هر منبع را به طور مستقل شروع، متوقف و مقیاس کنید.
متودولوژی ۱۲ فاکتوری کاملاً مناسب معماری ابری است. اصطلاح ضروری دیگر از متودولوژی ۱۲ فاکتوری این است که شما باید یک معماری معماری سرویسگرا ( ماژولار ) داشته باشید. و در نهایت، این است که محیط توسعه، آزمایش و تولید شما باید یکسان باشد. میتوانید از کانتینرها، Docker و میکروسرویسها استفاده کنید.
Description | Principle | ۱۲-factor Methodology |
Maintain a single codebase for each application that can be used to deploy multiple instances/versions of the same app and track it using a central version control system such as Git. | Codebase | ۱ |
As a best practice, define all the dependencies of the app, isolate them and package them within the app. Containerization helps here. | Dependencies | ۲ |
Build, Release, and Run are the three important components of a software development project. | Configurations | ۳ |
Log storage should be decoupled from the app. Segregation and compilation of these logs lie in the execution environment. | Backing Services | ۴ |
Build, Release and Run are the three important components of a software development project. | Build, Release, Run | ۵ |
Run all as a collection of stateless processes so that scaling becomes easy while unintended effects are eliminated. | Processes | ۶ |
While the app contains multiple processes, it is important to run all as a collection of stateless processes so that scaling becomes easy while unintended effects are eliminated. | Port-Binding | ۷ |
The app should gracefully dispose of broken resources and instantly replace them, ensuring a fast start-up and shutdown. | Concurrency | ۸ |
When applications built on a cloud-native application architecture go down, the app should gracefully dispose of broken resources and instantly replace them, ensuring a fast start-up and shutdown. | Disposability | ۹ |
Minimize differences between development and production environments. Building automated CI/CD pipelines, VCS, backing services and containerization will help you in this regard. | Dev / Prod Parity | ۱۰ |
Minimize differences between development and production environments. Building automated CI/CD pipelines, VCS, backing services, and containerization will help you achieve this. | Logs | ۱۱ |
Log storage should be decoupled from the app. Segregation and compilation of these logs lie in the execution environment. | Admin Processes | ۱۲ |
کلام اخر
اکوسیستم کلود نیتیو ( Cloud Native ) همچنان با سرعت زیادی در تمام دنیای IT در حال رشد است. پروژههای بیشتری در آینده نزدیک به Sandbox پذیرفته خواهند شد و به آنها فرصت میدهد تا توجه و آگاهی جامعه را جلب کنند. در حالی که CNCF پروژههای جدید را میپذیرد و یا پایان میدهد، داشتن یک مکانیسم کارآمد برای حذف پروژههایی که علاقه جامعه را از دست دادهاند زیرا دیگر ارزش ندارند یا با پروژههای دیگر مرتبطتر جایگزین میشوند، نیز مهم است.
سازمانهایی که از پروژههای CNCF استفاده میکنند، میتوانند از مزایای متعددی مانند افزایش سرعت توسعه، کاهش هزینهها، بهبود قابلیت اطمینان و مقیاسپذیری بهرهمند شوند. علاوه بر این، با مشارکت در جامعه CNCF، سازمانها میتوانند در شکلدهی آینده این فناوریها نقش فعالی داشته باشند
دانشجوی مهندسی نرم افزار و علاقه مند به دواپس 🙂