چرا هزینه Cloud دیگر فقط مسئله مالی نیست، بلکه مسئله معماری است؟
- شوک قبض ابری (Bill Shock): مهاجرت به فضای ابری بدون بازطراحی معماری، منجر به افزایش چشمگیر مخارج سازمان میشود.
- تله Lift and Shift: انتقال مستقیم نرمافزارهای یکپارچه به Cloud باعث هدررفت بودجه برای منابع بلااستفاده میشود.
- هزینههای پنهان شبکهای: در معماری میکروسرویسها، ترافیک بین سرویسها به سرعت از هزینه خود سرورها پیشی میگیرد.
- ظهور FinOps: فرهنگی نوین که در آن مهندسان نرمافزار، هزینه را به عنوان یک معیار اصلی معماری در نظر میگیرند.
در سالهای گذشته، وعده اصلی ارائهدهندگان خدمات ابری بسیار فریبنده بود. آنها میگفتند دیتاسنترهای فیزیکی خود را تعطیل کنید و هزینههای خود را کاهش دهید. در نتیجه، بسیاری از سازمانها با اشتیاق به این سمت حرکت کردند.
با این حال، پس از گذشت یک دهه، بسیاری از مدیران فناوری اطلاعات با پدیدهای به نام «شوک قبض ابری» مواجه شدهاند. به عبارت دیگر، صورتحساب ماهانه کلاود به طور ناگهانی به دهها هزار واحد پولی افزایش مییابد. در این شرایط، اولین واکنش سازمانها مراجعه به تیم مالی است. اما واقعیت تلخ این است که ریشه این هزینههای سرسامآور دقیقاً در قلب معماری نرمافزار نهفته است.
به همین دلیل، در این مقاله جامع از مجله آلفاتک، این موضوع مهم را بررسی خواهیم کرد. ما نشان میدهیم که چگونه با رویکرد مهندسی هزینه، میتوان نرمافزارهایی مقیاسپذیر و مقرونبهصرفه طراحی کرد.
سندرم Lift and Shift؛ انتقال مشکلات به فضای گرانتر
بزرگترین اشتباه استراتژیک در مهاجرت به ابر، استفاده از رویکرد Lift and Shift (برداشتن و انتقال دادن) است. در یک دیتاسنتر سنتی، شما سرورها را از قبل خریداری کردهاید. بنابراین، چه پردازنده شما کامل درگیر باشد و چه بیکار بماند، هزینه اصلی پرداخت شده است. در چنین محیطی، مهندسان عادت کردهاند منابع را بیش از حد نیاز در نظر بگیرند.
از سوی دیگر، وقتی همین نرمافزار یکپارچه مستقیماً به Cloud منتقل میشود، فاجعه رخ میدهد. در Cloud، شما به صورت ثانیهای برای منابع رزرو شده پول میدهید. فرمول پایه هزینههای ابری به این شکل محاسبه میشود:
در نتیجه، اگر معماری شما قابلیت مقیاسپذیری خودکار (Auto-scaling) نداشته باشد، مجبورید ماشینهای قدرتمند را همیشه روشن نگه دارید. این یعنی شما در حال سوزاندن بودجه برای ظرفیت خالی سیستم هستید. بنابراین، مشکل از تیم مالی نیست، بلکه معماری نرمافزار انعطافپذیری لازم را ندارد.
میکروسرویسها و هیولای پنهانی به نام Egress Cost
برای حل مشکل انعطافپذیری، بسیاری از تیمها به سمت معماری میکروسرویسها حرکت میکنند. در این معماری، نرمافزار به دهها سرویس کوچک تقسیم میشود. اگرچه این روش از نظر چابکی فوقالعاده است، اما یک تله مالی بزرگ به نام ترافیک شبکه به همراه دارد.
در برنامههای یکپارچه، فراخوانی توابع در حافظه رم انجام میشود که هزینهای ندارد. اما در میکروسرویسها، سرویسها باید از طریق شبکه با هم صحبت کنند. ارائهدهندگان ابری برای خروج داده (Egress) هزینه دریافت میکنند. بنابراین، اگر معماری شما بیش از حد خرد شده باشد، حجم عظیمی از داده در شبکه جابجا میشود و قبض ابری شما به شدت افزایش مییابد.
دوراهی معماری: Serverless در برابر Containers
یکی دیگر از تصمیمات مهم معماری، انتخاب بین محیطهای کانتینری و محیطهای بدون سرور (Serverless) است. وعده اصلی Serverless این است که فقط زمان اجرای کد هزینه پرداخت میکنید.
این مدل برای بارهای کاری غیرقابل پیشبینی بسیار اقتصادی است. با این حال، اگر سیستم شما به صورت مداوم با حجم بالای درخواستها کار کند، Serverless به شدت گرانتر از یک کانتینر اختصاصی تمام خواهد شد. در نتیجه، انتخاب بین این دو روش، یک تصمیم حیاتی با پیامدهای سنگین مالی است.
جدول مقایسه الگوهای معماری و تاثیر آنها بر هزینه
| الگوی معماری | ماهیت هزینه در Cloud | نقاط قوت مالی | نقاط ضعف و ریسکهای مالی |
|---|---|---|---|
| یکپارچه (Monolithic) | پرداخت ثابت برای ماشینهای قدرتمند | هزینه شبکه داخلی تقریباً صفر است. | هدررفت بالای منابع به دلیل عدم مقیاسپذیری دقیق. |
| میکروسرویس (Microservices) | پرداخت متغیر بر اساس کانتینرها | بهینهسازی هزینه با مقیاسپذیری دقیق. | هزینه پنهان وحشتناک انتقال داده بین سرویسها. |
| بدون سرور (Serverless) | پرداخت به ازای زمان اجرا | هزینه صفر در زمان بیکاری سیستم. | هزینه نجومی در صورت ترافیک مداوم و بالا. |
گرانش داده (Data Gravity) و استراتژی ذخیرهسازی
در فضای ابری، دادهها وزن و هزینه دارند! مفهومی به نام «گرانش داده» نشان میدهد که سرویسها به سمت محل ذخیره دادههای عظیم کشیده میشوند. علاوه بر این، انتخاب نوع ذخیرهسازی تاثیر مستقیمی بر هزینهها دارد.
ذخیره مداوم لاگها و بکآپها در لایه گرانقیمت (Hot Storage) بودجه سازمان را میبلعد. بنابراین، در یک معماری آگاه به هزینه، سیستم به گونهای طراحی میشود که دادههای قدیمی به صورت خودکار به لایههای ارزانتر (Cold Storage) منتقل شوند.
ظهور FinOps؛ وقتی مهندسان، حسابدار میشوند
با توجه به تمام چالشهای ذکر شده، دیسیپلین جدیدی به نام FinOps شکل گرفته است. این رویکرد صرفاً یک ابزار نیست، بلکه یک تغییر فرهنگی بزرگ به شمار میرود. در این فرهنگ، تیمهای مهندسی و مالی در کنار هم تصمیمگیری میکنند.
در رویکرد FinOps، تصمیمات معماری فقط بر اساس سرعت و پایداری گرفته نمیشود. بلکه هزینه نیز یک شاخص حیاتی است. مهندسان یاد میگیرند که از منابع تخفیفدار (مانند Spot Instances) برای پردازشهای سبکتر استفاده کنند. در نهایت، این کار نیازمند طراحی یک معماری مقاوم در برابر خطا است.
تحلیل اختصاصی آلفاتک: هزینه به عنوان یک بُعد غیرعملکردی (NFR)
در مهندسی نرمافزار سنتی، شاخصهایی مانند امنیت و سرعت اهمیت بالایی داشتند. ما در آلفاتک معتقدیم که در عصر ابری، هزینه (Cost) باید به عنوان یکی از مهمترین نیازمندیهای غیرعملکردی در نظر گرفته شود. اگر سیستمی بسیار سریع باشد اما شرکت را به مرز ورشکستگی بکشاند، آن معماری قطعاً شکست خورده است. بنابراین، موفقیت در Cloud نیازمند اجرای بهینه کد با بالاترین بازده مالی است.
