معماری ابر باید تغییرات سریع را در خود جای دهد

دیروز ما معماری هایی را حول نیازمندی های استاتیک ساختیم که به آرامی تغییر کردند. پیکربندی‌های مبتنی بر ابر امروزی باید به سرعت با رشد و تغییر سازگار شوند.

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

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

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

این روزها، شرکت‌هایی مانند MidCo بیشتر یک قانون هستند تا استثنا. شما انتظار دارید که این مشکل را در شرکت‌های قدیمی مشاهده کنید که دارای سیلوهای غیر یکپارچه و سهام فناوری هستند که به ۶۰ سال قبل بازمی‌گردد. اما این شرکت ها معمولا کمتر از ۱۰ سال عمر دارند و بسیاری از آنها هرگز از چیزی جز سیستم های مبتنی بر ابر استفاده نکرده اند. بنابراین، چگونه آنها مختل شدند؟

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

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

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

چگونه برای چیزی که نمی دانیم اتفاق خواهد افتاد برنامه ریزی کنیم؟

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

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

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

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

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

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

ساده، درست است؟ وقت آن است که دست به کار شوید.