Əgər siz tez varlanmaq sxemi ilə varlanacağınızı düşünərək bu səhifəyə girmisinizsə, sizi məyus etdiyim üçün üzr istəyirəm. Bu məqalə daha çox bulud xərclərinizi 1 milyon dollar azaltmaq barədə danışacaq. Bununla, siz mahiyyətcə əlavə bir milyon dollar gəlir əldə etmiş olacaqsınız – bu gəliri AWS ilə necə varlanmaq barədə onlayn kursumu almağa sərf edə bilərsiniz ( kursu buradan keçid ).
Şirkətlərin layihələrinin başlanğıcında bulud dəyəri çox vaxt nəzərə alınmır və nəzərə alınmır. 2021-ci ildə HashiCorp sorğusu göstərdi ki, şirkətlərin demək olar ki, 40%-i 2021-ci ildə bulud xərclərinə həddindən artıq pul xərcləyib [ 1 ]. 2023-cü ildə demək olar ki, bütün şirkətlər (94%) buludda pul xərclədiklərini etiraf etdilər [ 1 ] və bulud xərclərinin ən azı 30%-i boşa getdi [ 2 ]. 2022-ci ildə bulud xərcləri demək olar ki, 500 milyard dollar idi - buna görə də biz ildə 150 milyard dollar israfından danışırıq!
Bu, təkcə əldən verilmiş gəlirlərdən deyil, həm də zəif davamlılıq təcrübələrindən narahatdır. 150 milyard dollar enerji sərfiyyatı!
Bu tapıntılar yüksək buludlu yetkinlikdən aşağı buludlu yetkinliyə qədər böyük müəssisələri, eləcə də kiçik müəssisələri əhatə edir. Bu, AWS-ə aiddir, lakin eyni prinsiplər istənilən digər bulud provayderinə tətbiq edilə bilər. Beləliklə, işinizin hər hansı bir hissəsi buluddadırsa, bu məqalə sizin üçündür.
Mən məlumat mühəndisi nöqteyi-nəzərindən danışıram, lakin eyni öyrənmələr digər proqram mühəndisliyi təcrübələrinə də tətbiq oluna bilər.
Gəlin içəri girək.
Bu cür bulud hesabı adətən qlobal miqyasda milyonlarla müştəri ilə fəaliyyət göstərən çox böyük müəssisələrlə məhdudlaşır.
Sizə bir fikir vermək üçün, 1 milyon dollarlıq bulud fakturası Spark ETL işinin ilin 365 günü ərzində 24x7 saatda ~1,5 Tb işlənməsi nəticəsində yarana bilər. Başqa bir misal, dünyanın bir çox yerindən gündə milyardlarla sorğu alan bir tətbiq ola bilər.
Böyük bir müəssisədə bu ölçüdə yüzlərlə proqram var və nəticədə bulud provayderləri ilə milyard dollarlıq müqavilələr bağlanır. Məsələn, Airbnb 2019-cu ilin sonunda beş il ərzində bulud resurslarına 1,2 milyard dollar xərcləmək öhdəliyi götürmüşdü [3 ].
Expedia-da biz optimallaşdırma təcrübələrini tətbiq etməklə ildə 1,1 milyon dollara başa gələn məlumat emalı ETL-nin xərclərini ildə cəmi 100.000 dollara endirdik. Bu, 91% xərclərin azalmasıdır!
Bütün şirkətlərin belə böyük ölçüdə tətbiqləri yoxdur, ancaq tək bir proqram və ya bütün şirkətiniz üçün bulud xərclərinizi 90% azaltdığınızı təsəvvür edin.
Gedin və ən bahalı tətbiqlərinizin siyahısını əldə edin və dizayn fərziyyələrinizə etiraz edin .
Bütün bu suallar ən vacib suala qayıdır: proqram necə istifadə olunacaq? Onun mövcud olması üçün biznes dəyəri nədir? Tətbiq bizə verilən məqsədə çatmaqda necə kömək edir?
Əlbəttə ki, bütün bu cavablar çox vaxt layihənin əvvəlində qeyri-müəyyən olur; lakin buna görə dizayn həmişə iterativ bir proses olmalıdır - dəyişikliklərin mümkün qədər qüsursuz baş verməsinə imkan verir. Mühəndislər təkamül və dəyişikliyi qəbul etməli, tətbiqin inkişafını təsirlə uyğunlaşdırmalıdırlar.
İkinci addım tətbiqi lazımi resurslarla təmin etmək və lazımi infrastruktura uyğunlaşdırmaqdan ibarətdir.
Bir mühəndis olaraq bulud xərclərinin necə hesablandığından xəbərdar olun. Məsələn, AWS klaster qiymətinə təklif verə biləcəyiniz spot nümunələri təqdim edir — bu, xüsusilə də xətaya dözümlü və çevik tətbiqləriniz varsa faydalıdır. Mümkünsə, onlardan istifadə edin — AWS xərclərin 90%-ə qədər azaldığını iddia edir [ 4 ].
Müraciət etmək istədiyiniz bəzi digər mülahizələr bunlardır:
AWS Graviton nümunələrindən istifadə edərkən heç bir çatışmazlıq yoxdur və ya çox azdır. AWS ən sərfəli prosessorların yaradılmasına böyük sərmayə qoyub. Siz sadəcə intel əsaslı prosessordan ARM əsaslı prosessora keçid etməklə bulud xərclərini 40%-ə qədər azalda bilərsiniz [ 10 ].
Bunun üçün yeganə xəbərdarlıq, tətbiqinizin Graviton-un işlədiyi ARM əsaslı prosessorlara uyğun olmasıdır. RDS və ya OpenSearch kimi idarə olunan xidmətlə məşğul olursunuzsa, onda keçiddə heç bir çətinlik yoxdur — AWS əsas ƏS və tətbiq uyğunluğu ilə məşğul olur. Öz tətbiqinizi qurursunuzsa, istifadə etdiyiniz dildən asılı olaraq paketi yenidən tərtib etməli ola bilərsiniz - Java və digər dillər heç bir dəyişiklik tələb etmir, Python isə bir qədər diqqət tələb edir.
Nəhayət, gözlənilməz zirvələr və sürprizlər üçün xərclərinizi izləməyi unutmayın. Tətbiqinizin 0-cı günündəki xərc 170-ci günün dəyərindən fərqli olacaq. Dəyişiklikləri izlədiyinizə əmin olun və dəyişikliyin nə üçün baş verdiyini anladığınızdan əmin olun: bu, s3 yaddaş xərclərini yığırmı, yoxsa birdəfəlikdir sünbül?
Lazımi xəbərdarlıqları və əməliyyat təlimatlarını qurun !
Əsas odur ki, şöbə, layihə və ya ətraf mühitə görə xərcləri izləmək üçün xərc bölgüsü etiketlərini tətbiq edin. Xərcləri izləmək mümkün olmayan və ya müxtəlif log sistemləri arasında uzun səyahət tələb edən məlumat bataqlığı yaratmaq riskindən çəkinin. İstənilən tətbiq dəyərinə qayıtmaq tez və sadə olmalıdır.
Harada işlədiyinizdən asılı olmayaraq, yeni funksiyaların çatdırılmasını cari funksiyaların optimallaşdırılması ilə balanslaşdırmaq çətindir. Kimə işıq sürətində yeni qeyri-adi xüsusiyyətləri təqdim etmək üçün təzyiq edilməyib.
Bununla belə, həm mühəndislər, həm də menecerlər üçün cari layihələri ilə bağlı düşünülmüş və fəal qərarlar qəbul etmələri, riskləri və imkanları effektiv şəkildə idarə etmələri vacibdir.