تنها چیزهای قطعی در زندگی مرگ، مالیات و قفل ابری است. بیایید به دلایل پشت واقعیت قفل و چرایی اجتناب از آن بسیار دشوار نگاه کنیم.
اعتراف میکنم که با این مقاله درباره “در آغوش گرفتن ناراحتی” با قفل شدن فروشنده ابری است. این واقعیتی است که من سالها بر آن تاکید کردهام، زیرا سازمانها به سمت استقرار تک و چند ابری حرکت میکنند. دیدگاه من نتیجه یکسری تحقیقات خارجی نیست، بلکه واقعیتی است که قفل کردن را به عنوان واقعیتی در بسیاری از استقرارهای ابری در گذشته و حال می بینیم.
به هر حال، قفل کردن یک مشکل بسیار قدیمی است. در آن زمان، ما سیستمعاملهای ۳۲ بیتی متعددی روی رایانههای شخصی داشتیم، از جمله بسیاری از یونیکسها، ویندوز و حتی OS/2. فراخوانی برای ساخت برنامههایی وجود داشت که میتوانستند در سراسر پلتفرمها کار کنند، که در نتیجه از قفل شدن فروشنده جلوگیری میکرد. بهعنوان کسی که ابزارهای توسعه و استقرار و همچنین سیستمهای عامل هدف را بررسی میکردم، خودم را تا زانو در یک معضل قفل دیدم.
من فورا متوجه شدم کسانی که سعی می کردند نرم افزاری بسازند که روی همه پلتفرم ها با استفاده از هر تعداد لایه ترجمه API و شبیه سازهای سیستم عامل اجرا شود، معمولاً به نرم افزاری می رسیدند که در همه پلتفرم ها ضعیف عمل می کرد. کسانی که برنامههایی را با استفاده از ویژگیهای بومی پلتفرم میساختند، نرمافزار بسیار بهتر و پاسخگوتری داشتند که ساخت آن زمان کمتری میبرد. این مبادله اساسی برای جلوگیری از قفل شدن فروشنده همچنان موضوع اصلی است.
مطمئن است، اکنون بازی با مخاطرات بالاتر کمی متفاوت است. بسیاری از ارائه دهندگان ابری سیستم عامل ها و گزینه های پردازنده، پایگاه های داده یکسان و حتی همان عملیات و ابزارهای امنیتی را ارائه می دهند. بنابراین، چرا قفل فروشنده همچنان یک معامله است؟
بهعلاوه، اگر به تازگی اعلام کردهاید که میخواهید سیستمهایی بسازید که کاملاً از قفل شدن فروشنده جلوگیری کند، برای شما آرزوی موفقیت میکنم. با این حال، مگر اینکه به طور مداوم برنامههای بیهوده بخواهید، باید از امنیت بومی، زیرساختهای بومی بهعنوان کد، سیستمهای بدون سرور و غیره استفاده کنید که معمولاً توسط ارائهدهندگان مختلف بهعنوان سرویسهای بومی ارائه میشوند، به همین دلیل است که در یک ابر عمومی هستید. در وهله اول.
اگر به سمت غنیترین پلتفرمهای ابری عمومی برویم، به این دلیل است که از ویژگیهای بومی آنها استفاده کنیم. اگر از ویژگیهای بومی آنها استفاده میکنید، خود را در آن ارائهدهنده ابر قفل میکنید—یا حتی خود را در یک زیرپلتفرم در آن ارائهدهنده ابر قفل میکنید. تا زمانی که جایگزینی وجود داشته باشد، بهتر است به قفل کردن عادت کنید.
متوجه شدم. Lock-in به معنای شرط بندی عمده بر روی ارائه دهندگان فناوری خاص، در این مورد، ارائه دهندگان ابری است. سناریوی کابوس بالقوه این است که قیمتهای یک فروشنده ممکن است در هر زمان به طور قابل توجهی افزایش یابد و بودجهها به شدت با هوسهای قیمتگذاری ارائهدهنده اصلی ابر عمومی همراه باشد. شرکتها میترسند که ارائهدهنده ابر عمومی تصمیم بگیرد که وارد بازار مشتریانشان شود (که اتفاق میافتد)، یا مشکلات قابلیت اطمینان داشته باشند، یا توسط یک شرکت رقیب خریداری شوند، یا ورشکست شوند، یا کاری دیگر برای ایجاد مشکلات انجام دهند.
بدیهی است که یک یا چند مورد از این موارد میتواند اتفاق بیفتد، اما برای اکثر شرکتها، خطر بسیار کم است. در بدترین حالت، شما یک طرح خروج را به کار می گیرید که من به همه توصیه می کنم در هر صورت داشته باشند. یک طرح خروج، پلتفرم های دیگری را که می توانید در صورت بروز بحران به آنها حرکت کنید و اینکه چگونه این حرکت را انجام دهید، مشخص می کند. بله، این کمی دردسر و پول است، اما اغلب ارزش آرامش خاطر را دارد. شما به طور پیشگیرانه خطرات را کاهش خواهید داد و درک واضح تری از خطر قفل شدن و چگونگی به حداقل رساندن اثرات احتمالی خواهید داشت.
آیا قفل کردن خوب است؟ نه، اما نمی توان به طور کامل از آن اجتناب کرد. تفکر خود را کمی تنظیم کنید و درک کنید که همه اینها به مدیریت ریسک ها و معاوضه ها مربوط می شود.
پست های مرتبط
به قفل شدن فروشنده ابری عادت کنید
به قفل شدن فروشنده ابری عادت کنید
به قفل شدن فروشنده ابری عادت کنید