۲۹ شهریور ۱۴۰۳

Techboy

اخبار و اطلاعات روز تکنولوژی

برنامه های چند ابری فدرال شگفت انگیز

برنامه‌هایی که چندین ابر عمومی را در بر می‌گیرند، مخصوصاً با Kubernetes و کانتینرها محبوب‌تر می‌شوند، اما با دقت فکر کنید.

برنامه‌هایی که چندین ابر عمومی را در بر می‌گیرند، مخصوصاً با Kubernetes و کانتینرها محبوب‌تر می‌شوند، اما با دقت فکر کنید.

این روزها در مورد هدف اجرای برنامه های فدرال در سراسر ارائه دهندگان ابری چیزهای زیادی می شنوم. ما به دلایل زیادی می خواهیم این برنامه های چند ابری را بسازیم، از جمله:

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

نحوه اجرای برنامه های فدرال

اگرچه راه‌های زیادی برای استقرار فدرال برنامه‌ها وجود دارد، بیایید روی محبوب‌ترین آنها تمرکز کنیم: Kubernetes. شما معمولاً یک خوشه کانتینر Kubernetes راه‌اندازی می‌کنید که چندین ارائه‌دهنده ابر را در بر می‌گیرد. این چندین انتخاب ایجاد می کند.

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

مایکروسافت ابزار ارزیابی Azure Migrate را برای برنامه‌های NET منتشر کرد

برخی از ارائه دهندگان ابر خدمات Kubernetes مدیریت شده را ارائه می دهند، مانند Amazon Elastic Kubernetes Service (EKS)، Google Kubernetes Engine (GKE)، یا Azure Kubernetes Service (AKS). شما خوشه‌های Kubernetes را در هر ارائه‌دهنده ابری ارائه می‌کنید و بین آنها ارتباط برقرار می‌کنید. می‌توانید اینها را در محل اجرا کنید، اما این معمولاً ارزان‌ترین و آسان‌ترین مسیر نیست.

همچنین توصیه می‌شود راه‌حل‌های Kubernetes متقابل ابری (مانند Rancher) را کاوش کنید که به شما امکان می‌دهد خوشه‌ها را در میان ارائه‌دهندگان ابری مختلف از یک رابط یکپارچه مدیریت کنید. البته، راه‌های دیگری نیز وجود دارد که به همان اندازه قابل انجام است. Rancher فقط یکی است.

آیا استقرارهای فدرال ایده خوبی هستند؟

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

3 برنامه قاتل برای هوش مصنوعی مولد مبتنی بر ابر

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

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

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

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

Eclipse سازمانی جاوا بخار جمع می کند، MicroProfile می لغزد

الزامات برنامه خاص. همه برنامه‌ها از اجرای در ابرهای عمومی بهره نمی‌برند. برخی از برنامه‌ها ممکن است الزامات حاکمیت داده، بار کاری حساس به عملکرد، یا وابستگی به سرویس‌های ابری تخصصی داشته باشند که به راحتی در چندین ابر تکرار نمی‌شوند. در چنین شرایطی، یک مرکز داده خصوصی یا یک ارائه دهنده ابر واحد ممکن است گزینه های مناسب تری باشد. من شاهد ظهور بسیاری از این موارد نیستم زیرا اکثر معماران و توسعه دهندگان ابری تجربه کمی در ساخت برنامه های چند ابری فدرال دارند. علاوه بر این، بهترین روش‌ها کم است یا اصلاً وجود ندارد.

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