۳۰ آذر ۱۴۰۳

Techboy

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

معماری ابر را از طریق یک لنز بهینه سازی جدید مشاهده کنید

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

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

از آنجایی که معماری رایانش ابری پا به سن گذاشته، روش‌هایی که ما موفقیت را تعریف می‌کنیم نیز باید رشد کنند. در سال ۲۰۲۱، به این نکته اشاره کردم که بهینه سازی رایانش ابری بیشتر یک فرآیند باینری است تا آنالوگ.

آنچه که در آن زمان گفتم هنوز هم درست است: “خیلی چیزها در خطر است. معماری‌هایی که بهینه‌سازی نشده و پرهزینه هستند (معماری‌های ابری) ممکن است واقعاً کارساز باشند، اما ممکن است باعث شوند کسب‌وکار میلیون‌ها دلار در هفته از دست بدهد، در حالی که اکثر مردم عاقل‌تر نیستند. سی فناوری در جایی استفاده می‌شود که ۱۲ مورد بهتر کار می‌کردند، و طراحی نکردن برای تغییر به این معنی است که چابکی کسب‌وکار آسیب می‌بیند.”

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

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

Radius مایکروسافت و آینده توسعه ابری

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

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

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

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

آیا محاسبات ابری می تواند واقعاً فدرال شود؟

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

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

با این حال، فرض کنید فروشنده A بهترین برنامه های بومی موجود را برای عملیات مالی شما دارد، فروشنده B بهترین برنامه های بومی را برای نیازهای CRM شما دارد و فروشنده C بهترین برنامه های بومی را برای نیازهای موجودی شما دارد. رفتن به چند ابری برای به دست آوردن بهترین نژاد برای این سه نیاز، و همچنین برای ده ها انتخاب دیگر (امنیت، ذخیره سازی، شبکه و غیره)، ممکن است به نفع شرکت شما نباشد. هر یک از این انتخاب‌ها لایه دیگری از پیچیدگی و هزینه را اضافه می‌کنند که می‌تواند به سرعت از مزایای اضافه شده پیشی بگیرد.

تغییر در چشم انداز یادگیری ماشین

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

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

وقتی راه‌حل‌های ابری وجود دارد که کار می‌کنند، بسیاری از کارکنان تیم «به اندازه کافی خوب است» تمایل دارند به یکی از سه میمون عاقل تبدیل شوند: آنها نمی‌خواهند چیزی بشنوند، ببینند یا درباره ابر صحبت کنند. راه حلی که آنها به استقرار یا عملیات فعلی کمک کردند. برعکس، به نظر می رسد همیشه فردی در تیم وجود دارد که «صبر کن، چه هزینه ای دارد؟» کسانی که متوجه می شوند راه حل ابری به تخلیه منابع سازمانی بسیار بیشتر از آنچه باید ادامه خواهد داد. آنها اولین کسانی هستند که ممیزی را پیشنهاد یا اصرار می کنند.

در کدام تیم خواهید بود؟