اگر به این صفحه برخورد کرده اید که فکر می کنید با طرحی سریع ثروتمند خواهید شد، متاسفم که شما را ناامید می کنم. این مقاله بیشتر در مورد چگونگی کاهش هزینه های ابری خود به میزان 1 میلیون دلار صحبت خواهد کرد. با انجام این کار، اساساً یک میلیون دلار درآمد اضافی ایجاد خواهید کرد - که می توانید برای خرید دوره آنلاین من در مورد چگونگی ثروتمند شدن با AWS خرج کنید ( لینک دوره در اینجا ).
هزینه ابر اغلب در ابتدای پروژه های شرکت ها نادیده گرفته می شود و به حساب نمی آید. نظرسنجی HashiCorp در سال 2021 نشان داد که تقریباً 40٪ از شرکتها در سال 2021 در هزینههای ابری بیش از حد هزینه کردهاند [ 1 ]. در سال 2023، تقریباً همه شرکتها (94%) اعتراف کردند که پول خود را در فضای ابری هدر میدهند [ 1 ] و حداقل 30 درصد از هزینههای ابری هدر رفت [ 2 ]. هزینه های ابری در سال 2022 تقریباً 500 میلیارد دلار بود - بنابراین ما در مورد 150 میلیارد دلار هدر رفته در سال صحبت می کنیم!
این نه تنها یک نگرانی از درآمدهای از دست رفته است، بلکه عملکرد ضعیف پایداری نیز دارد. 150 میلیارد دلار هدر رفت انرژی!
این یافتهها شامل شرکتهای بزرگ و همچنین شرکتهای کوچکتر، از بلوغ ابری بالا تا بلوغ کم ابری است. این به AWS اشاره دارد، اما همان اصول را می توان برای هر ارائه دهنده ابر دیگری اعمال کرد. بنابراین، اگر بخشی از کار شما در فضای ابری است، پس این مقاله برای شما مناسب است.
من از دیدگاه مهندس داده صحبت می کنم، اما همین آموخته ها را می توان در سایر روش های مهندسی نرم افزار نیز به کار برد.
بیایید شیرجه بزنیم
این نوع صورتحساب ابری معمولاً محدود به شرکتهای بسیار بزرگی است که در سطح جهانی با میلیونها مشتری فعالیت میکنند.
برای ارائه یک ایده، یک صورتحساب ابری 1 میلیون دلاری می تواند ناشی از پردازش شغل Spark ETL ~ 1.5 ترابایت در ساعت 24x7 به مدت 365 روز در سال باشد. مثال دیگر ممکن است اپلیکیشنی باشد که روزانه میلیاردها درخواست از چندین مکان در جهان دریافت می کند.
در یک شرکت بزرگ، صدها برنامه کاربردی در این اندازه وجود دارد - که منجر به قراردادهای میلیارد دلاری با ارائه دهندگان ابری می شود. به عنوان مثال، Airbnb متعهد شده بود که در پایان سال 2019 1.2 میلیارد دلار را برای منابع ابری طی پنج سال هزینه کند [3 ].
در Expedia، با اجرای شیوههای بهینهسازی، هزینههای یک ETL پردازش داده را با هزینه 1.1 میلیون دلار در سال به 100000 دلار در سال کاهش دادیم. یعنی 91 درصد کاهش هزینه!!
همه شرکتها برنامههایی با این اندازه عظیم ندارند، اما تصور کنید که هزینههای ابری خود را تا 90 درصد فقط برای یک برنامه یا برای کل شرکت خود کاهش دهید.
بروید و لیستی از گران ترین برنامه های کاربردی خود را دریافت کنید و فرضیات طراحی خود را به چالش بکشید .
همه این سوالات به مهم ترین سوال برمی گردد: برنامه چگونه قرار است استفاده شود؟ ارزش تجاری برای وجود آن چیست؟ برنامه چگونه به ما در رسیدن به هدف معین کمک می کند؟
البته، همه این پاسخ ها اغلب در ابتدای پروژه نامشخص هستند. اما به همین دلیل است که طراحی همیشه باید یک فرآیند تکراری باشد - اجازه می دهد تغییرات تا حد امکان یکپارچه اتفاق بیفتد. مهندسان باید تکامل و تغییر را بپذیرند و توسعه اپلیکیشن را با تاثیر هماهنگ کنند.
مرحله دوم شامل فراهم کردن برنامه با منابع مناسب و تنظیم آن در زیرساخت مناسب است.
به عنوان یک مهندس، از نحوه محاسبه هزینه های ابری آگاه باشید. به عنوان مثال، AWS نمونههای نقطهای را ارائه میکند، که در آن میتوانید قیمت کلاستر را پیشنهاد دهید - این به ویژه در صورتی مفید است که برنامههای کاربردی انعطافپذیر و مقاوم در برابر خطا داشته باشید. اگر می توانید از آنها استفاده کنید - AWS ادعا می کند تا 90٪ در هزینه ها کاهش می یابد [ 4 ].
برخی ملاحظات دیگر که ممکن است بخواهید به آنها بپردازید عبارتند از:
در استفاده از نمونه های AWS Graviton هیچ اشکالی وجود ندارد. AWS سرمایه گذاری زیادی برای ایجاد مقرون به صرفه ترین پردازنده ها کرده است. تنها با جابجایی از یک پردازنده مبتنی بر اینتل به یک پردازنده مبتنی بر ARM می توانید تا 40٪ کاهش در هزینه های ابری داشته باشید [ 10 ].
تنها نکته ای که در این مورد وجود دارد این است که برنامه شما باید با پردازنده های مبتنی بر ARM که Graviton روی آنها اجرا می شود، سازگار باشد. اگر با یک سرویس مدیریت شده مانند RDS یا OpenSearch سر و کار دارید، هیچ مشکلی در تعویض وجود ندارد - AWS با سیستم عامل اصلی و سازگاری برنامه ها سروکار دارد. اگر برنامه شخصی خود را میسازید، ممکن است بسته به زبانی که استفاده میکنید نیاز به کامپایل مجدد بسته داشته باشید - جاوا و سایر زبانها نیازی به تغییر ندارند در حالی که پایتون نیاز به توجه دارد.
در نهایت، فراموش نکنید که هزینه های خود را برای قله ها و شگفتی های غیرمنتظره زیر نظر داشته باشید. هزینه روز 0 برنامه شما با هزینه روز 170 متفاوت خواهد بود. اطمینان حاصل کنید که تغییرات را پیگیری می کنید و متوجه می شوید که چرا این تغییر اتفاق می افتد: آیا هزینه های ذخیره سازی s3 روی هم جمع می شود یا فقط یک بار است. سنبله؟
هشدارها و راهنمای عملیاتی لازم را تنظیم کنید !
نکته مهم، پیاده سازی برچسب های تخصیص هزینه برای ردیابی هزینه ها بر اساس بخش، پروژه یا محیط است. از خطر ایجاد یک باتلاق داده که در آن هزینه غیرقابل ردیابی است یا نیاز به یک سفر طولانی در سیستمهای گزارش مختلف دارد، اجتناب کنید. بازگشت به هر هزینه برنامه باید سریع و ساده باشد.
هر کجا که کار می کنید، ایجاد تعادل بین ارائه ویژگی های جدید با بهینه سازی ویژگی های فعلی دشوار است. چه کسی برای ارائه ویژگیهای عجیب و غریب جدید با سرعت نور تحت فشار قرار نگرفته است.
با این حال، هم برای مهندسان و هم برای مدیران ضروری است که تصمیمات آگاهانه و فعالانه ای در مورد پروژه های فعلی خود بگیرند و ریسک ها و فرصت ها را به طور موثر مدیریت کنند.