از آنجا که مشاغل به طور فزاینده ای به خدمات ابری متکی هستند ، یک چالش مهم پدیدار می شود: جلوگیری از قفل فروشنده. توانایی تغییر ارائه دهندگان ابر بدون تلاش گسترده چند ساله برای حفظ انعطاف پذیری و کنترل هزینه ها بسیار مهم است. در این مقاله ، ما چگونگی رسیدگی به این چالش ، به ویژه برای سیستم های بزرگ و یکپارچه میراث – را با صدها یا هزاران پرونده و صدها هزار خط کد بررسی می کنیم.
مشکلات قفل معمولی
-
وابستگی به خدمات ارائه دهنده: سیستم ها اغلب با عملکرد ارائه دهنده کاملاً محکم می شوند. حتی هنگامی که خدمات معادل در سایر ارائه دهندگان وجود دارد ، تفاوت های ظریف در API یا ویژگی ها می تواند مهاجرت را پیچیده و وقت گیر کند.
-
ادغام عمیق با API های شخص ثالث: بدون طراحی دقیق ، کلاس های شخص ثالث می توانند در سیستم شما عمیقاً گنجانیده شوند و باعث می شوند نسخه API نسخه یا استهلاک را به یک چالش مهم تبدیل کنند.
-
نسخه درگیری جهنم: چندین نسخه از همان کتابخانه فروشنده در یک سیستم یکپارچه می تواند منجر به بدنام “نسخه تعارض Hell Hell” بدنام شود ، مشکلی که بیشتر مهندسان در بعضی مواقع با آن روبرو می شوند.
تکنیک های کاهش قفل
خوشبختانه ، راهکارهایی برای کاهش این چالش ها و اطمینان از انعطاف پذیر و سازگاری سیستم های شما وجود دارد.
محاصره:
آنچه را که متفاوت است محاصره کنید (باند چهار 1995)
یک لایه انتزاعی ایجاد کنید که جزئیات اجرای خدمات ابری را از بقیه سیستم شما پنهان کند. این تضمین می کند که فقط کلاسهای خاص با SDK ارائه دهنده ابر تعامل دارند ، در حالی که بقیه پروژه شما همچنان ابر آگنوستیک است.
-
کد وابسته به ابر (که در زیر به رنگ قرمز برجسته شده است) رابط لایه انتزاع را پیاده سازی می کند و مستقیماً با SDK ارائه دهنده ابر تعامل دارد.
-
بقیه سیستم فقط با لایه انتزاع (کد ابر-آگنوستیک) در تعامل است و از انعطاف پذیری و کاهش خطر قفل فروشنده اطمینان حاصل می کند.
تزریق وابستگی با بسته بندی های رابط:
برنامه به یک رابط ، نه اجرای (باند چهار 1995)
-
این رویکرد شامل تعریف رابط های ارائه دهنده-آگنوستیک در پروژه شما و تزریق پیاده سازی های خاص از خارج از پروژه شما است. با اطمینان از اینکه کلاسهای شما فقط به رابط ها بستگی دارد ، می توان اجرای واقعی را در زمان اجرا ، به طور معمول از طریق تزریق وابستگی ارائه داد.
-
این راه حل ، جدایی دقیق بین رابط های ابر آگنوستیک و پیاده سازی های خاص ابر را تقویت می کند و سیستم شما را انعطاف پذیر ، قابل حفظ و قابل آزمایش تر می کند. همچنین به شما این امکان را می دهد تا یک اجرای یک سرویس ابری را با دیگری در زمان اجرا تغییر دهید ، قفل فروشنده را کاهش داده و سازگاری را ارائه دهید.
جدول محفظه در مقابل تبار وابستگی جدول تبادل
مانند هر تصمیم معماری ، هیچ راه حل کاملی وجود ندارد. با این حال ، درک معاملات می تواند به شما در انتخاب رویکرد مناسب برای سیستم خود کمک کند.
” loading=”lazy” width=”750″ height=”276″/>
پایان
کاهش قفل ارائه دهنده ابر برای حفظ انعطاف پذیری و جلوگیری از چالش های مهاجرت در آینده ضروری است. با اجرای تکنیک هایی مانند محصور سازی و تزریق وابستگی ، می توانید اطمینان حاصل کنید که سیستم های یکپارچه میراث شما در یک منظره ابری در حال تحول سازگار و انعطاف پذیر باقی می مانند.
به نظر من ، تزریق وابستگی در بیشتر موارد بهترین راه حل است. این کد COMPER-AGNOSTIC ، قابل آزمایش را نگه می دارد و جدایی روشنی بین خدمات عمومی شخص ثالث و منطق کسب و کار سفارشی شما را تضمین می کند. یک مزیت غالباً نادیده گرفته از این رویکرد فرصتی برای استفاده مجدد است – وقتی رابط های خدمات واقعاً عمومی هستند ، می توان در پروژه های مختلف مورد استفاده مجدد قرار گرفت و باعث صرفه جویی در وقت و تلاش می شود.
در مورد شما چطور؟ کدام راه حل را ترجیح می دهید؟ یا شاید شما تکنیک های دیگری پیدا کرده اید که بهتر کار می کنند؟ من دوست دارم افکار شما را بشنوم – دریغ نکنید که تجربیات خود را به اشتراک بگذارید!
این مقاله در LinkedIn نیز موجود است
