پنج خطر انتقال پایگاه داده به فضای ابری

حرکت به سمت ابر خشم است. بر اساس یک IDC Survey Spotlight، تجربه در مهاجرت پایگاه داده به فضای ابری63 درصد از شرکت ها به طور فعال پایگاه داده های خود را به فضای ابری انتقال می دهند و 29 درصد دیگر نیز در نظر دارند این کار را طی سه سال آینده انجام دهند.

این مقاله برخی از خطراتی را که مشتریان ممکن است ناخواسته هنگام انتقال پایگاه داده خود به یک پایگاه داده به عنوان سرویس (DBaaS) در فضای ابری با آن مواجه شوند، مورد بحث قرار می دهد، به ویژه زمانی که DBaaS از نرم افزار پایگاه داده منبع باز مانند Apache Cassandra، MariaDB، MySQL، Postgres یا Redis استفاده می کند. . در EDB، ما این خطرات را به پنج دسته تقسیم می کنیم: پشتیبانی، خدمات، رکود فناوری، هزینه و قفل. حرکت به سمت فضای ابری بدون دقت کافی و کاهش ریسک می‌تواند منجر به افزایش قابل توجه هزینه‌ها و تاخیر در پروژه شود، و مهمتر از آن، ممکن است به این معنی باشد که شرکت‌ها مزایای تجاری مورد انتظار را از مهاجرت ابری به دست نمی‌آورند.

از آنجایی که EDB بر پایگاه داده Postgres تمرکز می کند، من جزئیات را از تجربیات خود در مورد خدمات Postgres می گیرم، اما نتایج به همان اندازه برای سایر سرویس های پایگاه داده منبع باز معتبر است.

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

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

مشتریان می‌توانند با بررسی یادداشت‌های انتشار نرم‌افزار منبع باز و شناسایی اعضای تیمی که فعالانه در پروژه شرکت می‌کنند، توانایی ارائه‌دهنده پایگاه داده ابری را برای پشتیبانی از مهاجرت ابری خود ارزیابی کنند. به عنوان مثال، برای Postgres، یادداشت‌های انتشار آزادانه در دسترس هستند و هر فردی را که ویژگی‌های جدید یا رفع اشکال را ارائه کرده است، نام می‌برد. سایر جوامع منبع باز از شیوه های مشابه پیروی می کنند.

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

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

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

ریسک رکود فناوری مدل مسئولیت مشترک جزء کلیدی یک DBaaS است. در حالی که کاربر تعریف طرح‌واره و تنظیم پرس و جو را انجام می‌دهد، ارائه‌دهنده پایگاه داده ابری به‌روزرسانی‌های نسخه جزئی و ارتقاهای نسخه اصلی را اعمال می‌کند. همه ارائه دهندگان متعهد به ارتقاء به موقع نیستند – و برخی ممکن است به طور قابل توجهی عقب بیفتند. در زمان نگارش این مقاله، یکی از ارائه دهندگان اصلی Postgres DBaaS تقریباً سه سال از جامعه منبع باز در استقرار نسخه های Postgres عقب افتاده است. در حالی که ارائه‌دهندگان DBaaS می‌توانند به‌طور انتخابی اصلاحات امنیتی را پشتیبان‌گیری کنند، استفاده با تأخیر از نسخه‌های جدید می‌تواند مشتریان را در موقعیتی قرار دهد که گاهی برای سال‌ها قابلیت‌های جدید پایگاه داده را از دست بدهند. مشتریان برای ارزیابی این مواجهه باید سوابق سابقه ارائه دهنده را در اعمال ارتقاها بررسی کنند.

زمانی که یک ارائه‌دهنده پایگاه داده ابری اختصاصی سعی می‌کند فورک یا نسخه‌ای از نرم‌افزار منبع باز معروف خود را ایجاد کند، خطر مشابهی معرفی می‌شود. گاهی اوقات این کار برای بهینه سازی نرم افزار برای محیط ابری یا رفع محدودیت های مجوز انجام می شود. نسخه های فورک شده می توانند به طور قابل توجهی از والد شناخته شده تر منحرف شوند یا از نسخه منبع باز عقب بمانند. نمونه های شناخته شده ای از این فورک ها یا نسخه های اختصاصی عبارتند از Aurora Postgres (مشتق شده Postgres)، Amazon DocumentDB (با سازگاری MongoDB) و Amazon OpenSearch Service (در اصل از Elasticsearch مشتق شده است).

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

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

کاربران ریسک هزینه را به دو روش کاهش می دهند: (1) نظارت دقیق بر افزایش IOPS، CPU و حافظه برای اطمینان از متعادل بودن آنها در برابر هزینه بهینه سازی برنامه. (2) بررسی مدل های هزینه ارائه دهندگان DBaaS برای شناسایی و اجتناب از فروشندگان با مدل های هزینه پیچیده و غیرقابل پیش بینی.

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

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

کاربران می توانند با اجتناب دقیق از استفاده از ابزارهای ابری اختصاصی و با اطمینان از اینکه آنها فقط از راه حل های DBaaS استفاده می کنند که از تکرار کارآمد داده ها به ابرهای دیگر پشتیبانی می کند، اثر قفل شدن ابر را کاهش دهند.

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

این محتوا توسط EDB تولید شده است. این توسط هیات تحریریه MIT Technology Review نوشته نشده است.