بهترین روش‌های جدید از تعریف راه‌حل‌های ابری از بیرون برای بهره‌گیری از نقاط قوت رایانش ابری پشتیبانی می‌کنند.
این سه هفته آخر یک پروژه معماری ابری ۲۲ ماهه است. شما پیکربندی را تعریف و طراحی کردید که بسیاری از منابع رایانش ابری را تعریف می‌کند: پایگاه‌های داده، موتورهای هوش مصنوعی، پلتفرم‌های توسعه برنامه‌ها، زنجیره‌های ابزار توسعه‌دهنده، ابزارهای cloudops، و همچنین امنیت و حاکمیت.
امروز متوجه شدید که تعدادی از پایگاه‌های داده اطلاعات را به روشی که برنامه‌ها نیاز دارند ذخیره نمی‌کنند، موتور هوش مصنوعی با راه‌حل امنیتی که انتخاب کرده‌اید کار نمی‌کند، و هزینه ابزارهای cloudops 10 برابر مقدار بودجه است. چرا این اتفاقات افتاد؟ آیا تقصیر شماست؟
گاهی اوقات در مرحله طراحی راه‌حل ابری متوجه این اشتباهات می‌شویم، فرقی نمی‌کند این یک سیستم جدید باشد یا مهاجرت از پلتفرم‌های سنتی. متأسفانه، این مشکلات و مشکلات مشابه همیشه به وجود می آیند، حتی اگر معماری ابر باید این نوع خطاها را به حداقل برساند.
چیزی که مرا آزار می‌دهد این است که بسیاری از این اشتباهات تا زمان اجرا یا حتی بعداً مورد توجه قرار نمی‌گیرند. راه‌حل ممکن است کارساز باشد، اما مشکلات اساسی همچنان بر کسب‌وکار تأثیر منفی خواهند گذاشت، زیرا راه‌حل‌ها به‌شدت بهینه نشده‌اند. هزینه های عملیاتی بیشتر و مزایای کمتری برای کسب و کار وجود خواهد داشت.
به عنوان مثال، فرض کنید موتور هوش مصنوعی اشتباهی را برای پشتیبانی از سیستم تشخیص تقلب انتخاب کرده اید. اگر سیستم از یک موتور هوش مصنوعی بهینه استفاده کند، ممکن است فقط یک سوم از مشکلاتی را که سیستم می‌تواند به آن مبتلا کند، متوجه شوید. هیچ کس متوجه نمی شود زیرا سیستم در حال شکار چیزهایی است، اما باعث می شود شرکت در پشت صحنه در درآمد از دست رفته خشک شود.
همانطور که با راه‌حل‌های رایانش ابری در مسیر پیش‌تر پیش می‌رویم، متوجه می‌شویم که معماران ابری بیشتر اشتباهات بزرگی را از نظر تأثیر منفی بر تجارت مرتکب می‌شوند. هیچ کس کامل نیست، اما برخی از معماران بیشتر کارها را درست انجام می دهند تا تعداد خطاهای موجود در راه حل های ابری خود را، چه کوچک و چه بزرگ، به حداقل برسانند. آن معماران به درستی چه کار می کنند؟
به خاطر داشته باشید که هنگام پیکربندی راه‌حل ابری یا انتخاب بهینه‌ترین روش‌ها، هیچ راه بی‌خطری برای جلوگیری از هر اشتباهی وجود ندارد. با این حال، وقتی با معماران جدید کار می‌کنم، سریع به این نکته اشاره می‌کنم که می‌توانید معماری ابری را از داخل به بیرون یا از بیرون به داخل انجام دهید. هر روش مزایای متفاوتی دارد.
داخل بیرون
رویکرد درون به بیرون، معماری را از ابتدایی ترین مفاهیم و اجزای فناوری، مانند ذخیره سازی، محاسبات، پایگاه های داده، شبکه، عملیات و غیره در نظر می گیرد. سپس به سمت بیرون کار می کنید تا نیازمندی های دقیق تر را تعریف کنید: مدل های پایگاه داده، مدیریت عملکرد، الزامات پلتفرم خاص، و فناوری فعال مانند کانتینرها و ارکستراسیون کانتینر (به عنوان مثال، Kubernetes).
به عبارت دیگر، شما با اصول اولیه مانند زیرساخت شروع می‌کنید، و سپس به سمت خارج به سمت نیازهای راه‌حل خاص کار می‌کنید. چگونه تصمیمات و پیکربندی‌های فناوری کل‌نگر (مانند طراحی‌های ذخیره‌سازی و محاسباتی یا فناوری‌های خاص) نیازهای تجاری خاص را برآورده می‌کنند؟ شما راه حل های خاصی برای حمایت از کسب و کار می سازید.
خارج در داخل
خارج در جهت مخالف حرکت می کند. شما با الزامات تجاری خاص شروع می کنید، مانند موارد استفاده تجاری برای راه حل های خاص یا، به احتمال زیاد، بسیاری از راه حل ها یا برنامه ها. سپس به سمت زیرساخت و سایر فناوری‌هایی که به‌طور خاص برای پشتیبانی از بسیاری از راه‌حل‌ها یا برنامه‌های مورد نیاز، مانند پایگاه‌های داده، ذخیره‌سازی، محاسبات، و سایر فناوری‌های فعال‌کننده انتخاب شده‌اند، حرکت می‌کنید.
اکثر معماران ابر از درون به بیرون حرکت می کنند. آنها زیرساخت های خود را قبل از درک واقعی هدف خاص راه حل انتخاب می کنند. آنها با یک ارائه‌دهنده ابر یا فروشنده پایگاه داده همکاری می‌کنند و راه‌حل‌های مرتبط با زیرساخت را انتخاب می‌کنند که تصور می‌کنند نیازهای راه‌حل‌های تجاری خاص آنها را برآورده می‌کنند. به عبارت دیگر، آنها قبل از اینکه راه حلی را در باریکی انتخاب کنند، یک راه حل را در وسعت انتخاب می کنند.
این گونه است که شرکت‌ها راه‌حل‌هایی را دریافت می‌کنند که کار می‌کنند، اما به شدت بهینه نشده‌اند یا اغلب، مسائل شگفت‌انگیز زیادی دارند، مانند مواردی که قبلاً مورد بحث قرار گرفت. کشف این مسائل مستلزم کار زیادی است و معمولاً تیم مستلزم حذف و جایگزینی راه حل های فناوری در حال پرواز است. آنها ممکن است مجبور باشند پایگاه داده ای اضافه کنند که از مدل پایگاه داده مورد نیاز پشتیبانی کند، حتی اگر هزینه مجوز متصل به یک معامله پایگاه داده بزرگ سازمانی را بپردازند. یا ممکن است سیستم امنیتی را جایگزین کنند تا با هوش مصنوعی کار کند، حتی اگر چند سال پیش نیم میلیون دلار برای آزمایش و استقرار سیستم موجود هزینه کردند. من از تجربه می‌دانم که بسیاری از شما اکنون در این شرایط زندگی می‌کنید.
من اغلب این استدلال را می شنوم که شرکت ابتدا باید فناوری های اساسی را انتخاب کند و این کار را بر اساس فرضیات موجود انجام می دهد و سپس به آنچه که سبد برنامه های کاربردی موجود آنها نیاز دارد نگاه می کند. اگرچه در روزهایی که شرکت‌ها سخت‌افزار و نرم‌افزار خود را می‌خریدند، این کار مقرون به صرفه‌تر بود، اما اکنون در جایی که دیگر چنین نیست، از منابع مبتنی بر ابر استفاده می‌کنیم.
اکنون می‌توانید از برنامه‌ها و راه‌حل‌های مورد نیاز خاص به هر تعداد گزینه زیرساختی برای پشتیبانی از آن برنامه‌ها و راه‌حل‌ها، به طور کامل بهینه شده، بروید. حتی می‌توانید زیرساخت منحصر به فردی داشته باشید که شامل پایگاه‌های داده، امنیت، حاکمیت و عملیات است که برای هر برنامه یا گروه کوچکی از برنامه‌ها یکباره است.
مزایای آن داشتن زیرساخت فناوری پشتیبانی است که می توانید برای حل بهینه مشکلات تجاری خاص انتخاب و پیکربندی کنید. دیگر نیازی نیست که برنامه ها را با تصمیمات فناوری که قبلاً گرفته اید تطبیق دهید. این امر باعث می‌شود که معماری ابری به روشی ترجیح داده شود زیرا واقعاً از قدرت ابر استفاده می‌کند.
پست های مرتبط
به معماری ابر از بیرون به داخل نزدیک شوید
به معماری ابر از بیرون به داخل نزدیک شوید
به معماری ابر از بیرون به داخل نزدیک شوید