پاسخ به بازخورد شما در مورد “متاکلاد”

آخرین پست من در مورد “متا ابر” یا “ابر ابر” در حال ظهور اعصاب را به هم زد. در اینجا به دنبال نظرات و سوالات شما در مورد آینده سیستم های مبتنی بر ابر است.

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

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

برخی شرکت‌ها در حال فروش «متاکلود» هستند

این رایج ترین نظر بود. اول، باید اشاره کنم که ابر ابری که امروزه وجود دارد یک الگوی معماری است، نه یک محصول یا فناوری خاص. مسلماً، این روزها سردرگمی “متا” زیادی وجود دارد که به دلیل تغییر نام تجاری اخیر فیس بوک در پلتفرم ها و شرکت های بزرگ رسانه های اجتماعی محبوب خود (فیس بوک، اینستاگرام، واتس اپ و غیره) تحت یک چتر، Meta Platforms, Inc. ایجاد شده است. ابر ابری.

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

متاکلود به یک ارائه دهنده خدمات ابری اولیه نیاز دارد

اکثر ارائه دهندگان خدمات ابری (CSP) این دیدگاه را داشتند. نیمی از آنها درست است. به خاطر داشته باشید که ابر ابر، یا هر چیزی که می خواهید نام آن را بگذارید، لایه ای از فناوری است که به طور منطقی در بالای دو یا چند ارائه دهنده ابر عمومی عمل می کند. کلمه کلیدی در آنجا “منطقی” است. داشبورد متاکلود منطقاً می‌تواند امنیت بین ابری، عملیات متقابل ابری، حاکمیت میان ابری، سیستم‌های ذخیره‌سازی مشترک میان ابری و غیره را اجرا کند – هر چیزی که انتزاعی از خدمات ابری بومی یا اختصاصی را ارائه می‌کند که فقط در باغ‌های دیواری کار می‌کنند. ارائه دهندگان ابر خاص پشته معماری/فناوری ابر ابر ممکن است از نظر فیزیکی بر روی پلتفرم ارائه‌دهنده ابر خاص یا حتی در بسیاری از پلتفرم‌های ارائه‌دهندگان ابری مختلف قرار داشته باشد، در حالی که به‌طور «منطقی» سیستم‌ها را در بسیاری از پلت‌فرم‌های ارائه‌دهندگان ابری مختلف بدون هیچ مشکلی در مورد محل اجرا کنترل می‌کند. .

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

افزودن یک لایه در بالای استقرار چند ابری پیچیدگی را از بین نمی برد، فقط آن را پنهان می کند 

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

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

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

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

استفاده از لایه انتزاعی باعث تاخیر می شود

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

به عنوان مثال، فرض کنید یک شرکت از یک انتزاع رابط ذخیره سازی استفاده می کند که یک رابط مشترک برای همه سیستم های ذخیره سازی عمومی و بومی ابری فراهم می کند. توسعه دهندگان نیازی به نوشتن در هر یک API خاص و گاهی اختصاصی برای هر ارائه دهنده ابر عمومی ندارند، زیرا رابط به یک API/CLI انتزاعی می نویسد که از اتوماسیون برای مقابله با تفاوت ها استفاده می کند. بله، برخی معاوضه‌های تاخیر وجود دارد زیرا پردازش اضافی و I/O باید اتفاق بیفتد. در بیشتر موارد، توسعه‌دهندگان، آزمایش‌کنندگان یا کاربران متوجه آن نمی‌شوند.

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

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

بیشتر نظرات و سوالات در مورد مقاله metacloud من بر اساس منطق صحیح بود. مهم است که هر مفهوم جدیدی را زیر سوال ببریم و مزایا و معایب آن را بسنجیم. من از همه شما که به مقاله علاقه داشتید تشکر می کنم و از بازخوردتان قدردانی می کنم. بیایید بحث را ادامه دهیم.