اپلیکیشن های Cloud-Native به Cloud نیازی ندارند!

اپلیکیشن های Cloud-Native به Cloud نیازی ندارند!

قبل از هر چیزی لازم به ذکر است که کلود نیتیو (Cloud-Native)، بر خلاف نامش نیازی به کلود ندارد. این نام از یک رویکرد معماری ساخت اپلیکیشن گرفته شده که بر زیرساخت متکی بوده و حول مفهوم Cloud (انعطاف پذیری، مزیت مقیاس و محاسبات توزیع شده) طراحی شده است.

بدون شک Cloud-Native در دسته محاسبات ابری قرار می گیرد و این مفاهیم را در تمام ابعاد توزیع اپلیکیشن (از معماری اپلیکیشن تا اتوماسیون، از یکپارچه سازی مبتنی بر API تا زیرساخت) جای داده است. محاسبات ابری تحول عظیمی در نحوه توسعه، ساخت و پیاده سازی اپلیکیشن ها ایجاد کرده است. اپلیکیشن هایی که در کلود عمومی متولد شده اند وابستگی ها و مشخصات مشترک متعددی دارند. بنابراین ریشه این نام دقیقاً به سبک معماری آن برمی گردد.

علاوه بر این Cloud-Native و کانتینرها هم با یکدیگر مرتبط اند. همین مسئله به نوبه خود اپلیکیشن های ذاتی کلود که برای دستیابی به اهداف مشابه به ماشین های مجازی متکی اند را از سرویس های Cloud-Native متمایز می کند. Cloud-Native و کانتینرها شدیداً به هم وابسته اند چون ساده ترین و رایج ترین ابزارهای ایجاد ارتباط میان اپلیکیشن ها و زیرساختی که ملزم به فراهم سازی انعطاف پذیری و مزیت مقیاس مطلوب است، هماهنگ سازهای کانتینر (کوبرنتیز) هستند.

در اپلیکیشن Cloud-Native برای این که اجزا بتوانند به مزیت مقیاس (که گاهی هم به آن «صرفه جویی به مقیاس» می گویند) دست یابند، تجزیه شده اند. به همین دلیل است که Cloud-Native و کانتینر معنای مشابهی دارند. شما باید مقیاس قابلیت هایی را تغییر دهید که به آن ها نیاز است. این نوع قسمت بندی در اپلیکیشن ها از طریق معماری هایی قابل دستیابی است که به مسیریابی لایه 7 (HTTP) نیاز دارند و کلود نیتیو هم از این قاعده مستثنی نیست.

همین اصول برای این اپلیکیشن های مدرن هم صادق اند و معمولاً از یک کنترل ورودی (سرویس اپلیکیشن زیرساخت) استفاده می کنند که وظیفه مدیریت توزیع درخواست های ورودی به نمونه مبتنی بر کانتینر مناسب یک بخش از اپلیکیشن را برعهده دارد.

این قسمت بندی اغلب در سطح API انجام می شود. در این سطح، URL ها با فراخوانی های API که با سرویس های کانتینر خاص مطابقت دارند منطبق می شوند. کنترل ورودی، درخواست ها را به سرویس کانتینر مناسب هدایت نموده و همین سرویس هم به نوبه خود درخواست ها را میان مجموعه ای از نمونه های کامپوننت/اپلیکیشن توزیع می کند. در واقع مانند یک کیک دو لایه است که در آن کنترل لایه 7 (HTTP) کار توزیع به متعادل ساز بار قدیمی و ساده (POLB) را برای توزیع و اجرا انجام می دهد.

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

این ارتباط میان اجزا، سرویس ها، رجیستری سرویس ها، متعادل سازهای بار و کنترل ورودی نشان دهنده ذات اپلیکیشن های Cloud-Native است. اجزا و زیرساخت اپلیکیشن ذاتاً با هم در ارتباط اند، بدون این که به هم وابستگی داشته باشند.

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

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

در حال حاضر می توان کانتینرها را بر روی کلود خصوصی (زیرساخت داخلی) پیاده سازی کرد و پژوهش ما هم نشان می دهد که کلود خصوصی هنوز هم محبوب ترین مدل کلود مورد استفاده است. بیش از سه چهارم (79 درصد) شرکت کنندگان نظرسنجی State of Application Services ما در سال 2019 اپلیکیشن های خود را در کلود خصوصی قرار داده اند ولی این آمار برای کلود عمومی به حداکثر به 45 درصد می رسد.

اپلیکیشن Cloud-Native ، معماری رو به رشدی است که مطمئناً تا پنج سال دیگر به رشد خود ادامه خواهد داد. درک ارتباط (و وابستگی) آن ها با سرویس های زیرساخت اپلیکیشن، عامل بسیار مهمی در توزیع موفقیت آمیز و امن این اپلیکیشن های مدرن محسوب می شود.