თუ ამ გვერდზე შეხვედით და ფიქრობთ, რომ გამდიდრდებით სწრაფი გამდიდრების სქემით, ვწუხვარ, რომ იმედი გაგიცრუებთ. ამ სტატიაში ვისაუბრებთ იმაზე, თუ როგორ შეამციროთ თქვენი ღრუბლოვანი ხარჯების გადასახადები 1 მილიონი დოლარით. ამით თქვენ არსებითად გამოიმუშავებთ დამატებით მილიონ დოლარს - რომელიც შეგიძლიათ დახარჯოთ ჩემი ონლაინ კურსის შესაძენად, თუ როგორ უნდა გამდიდრდეთ AWS-ით ( კურსის ბმული აქ ).
Cloud ღირებულება ხშირად შეუმჩნეველი და გაუთვალისწინებელია კომპანიების პროექტების დასაწყისში. 2021 HashiCorp-ის გამოკითხვამ დაადგინა, რომ კომპანიების თითქმის 40%-მა ზედმეტად დახარჯა ღრუბლოვანი ხარჯები 2021 წელს [ 1 ]. 2023 წელს თითქმის ყველა კომპანიამ (94%) აღიარა, რომ ფლანგავდა ფულს ღრუბელზე [ 1 ] და ღრუბლის ხარჯების მინიმუმ 30% იხარჯებოდა [ 2 ]. Cloud-ის დახარჯვა 2022 წელს თითქმის 500 მილიარდი დოლარი იყო - შესაბამისად, ჩვენ ვსაუბრობთ წელიწადში 150 მილიარდ დოლარზე გაფლანგვაზე!!
ეს არ არის მხოლოდ გამოტოვებული შემოსავლების შეშფოთება, არამედ მდგრადობის ცუდი პრაქტიკაც. 150 მილიარდი დოლარის გადაყრილი ენერგია!
ეს დასკვნები მოიცავს როგორც მსხვილ, ისე მცირე საწარმოებს, მაღალი ღრუბლის სიმწიფიდან დაწყებული ღრუბლის სიმწიფემდე. ეს ეხება AWS-ს, მაგრამ იგივე პრინციპები შეიძლება გამოყენებულ იქნას ნებისმიერი სხვა ღრუბლოვანი პროვაიდერისთვის. ასე რომ, თუ თქვენი სამუშაოს რომელიმე ნაწილი ღრუბელშია, მაშინ ეს სტატია თქვენთვისაა.
მე ვსაუბრობ მონაცემთა ინჟინრის პერსპექტივიდან, მაგრამ იგივე ცოდნა შეიძლება გამოყენებულ იქნას სხვა პროგრამული ინჟინერიის პრაქტიკაში.
მოდი ჩავყვინთოთ.
ამ სახის ღრუბლოვანი გადასახადი, როგორც წესი, შემოიფარგლება ძალიან მსხვილი საწარმოებით, რომლებიც მუშაობენ გლობალურად მილიონობით კლიენტით.
წარმოდგენა რომ მოგაწოდოთ, 1 მილიონი აშშ დოლარის ღრუბლოვანი გადასახადი შეიძლება მოჰყვეს Spark ETL სამუშაოს დამუშავებას ~ 1,5 ტბ საათში 24x7 წელიწადში 365 დღის განმავლობაში. კიდევ ერთი მაგალითი შეიძლება იყოს აპლიკაცია, რომელიც დღეში მილიარდობით მოთხოვნას იღებს მსოფლიოს მრავალი ადგილიდან.
მსხვილ საწარმოში, ამ ზომის ასობით აპლიკაციაა - რის შედეგადაც ხდება მილიარდი დოლარის კონტრაქტები ღრუბელ-პროვაიდერებთან. მაგალითად, Airbnb-ს ჰქონდა ვალდებულება 2019 წლის ბოლოს ხუთი წლის განმავლობაში 1,2 მილიარდი დოლარი დახარჯოს ღრუბლოვანი რესურსებისთვის [3 ].
Expedia-ში ჩვენ შევამცირეთ მონაცემთა დამუშავების ETL-ის ხარჯები, რომელიც წელიწადში 1,1 მილიონი დოლარი ჯდება, სულ რაღაც 100,000 დოლარამდე წელიწადში ოპტიმიზაციის პრაქტიკის დანერგვით. ეს არის ხარჯების 91%-იანი შემცირება!!
ყველა კომპანიას არ აქვს ასეთი უზარმაზარი ზომის აპლიკაციები, მაგრამ წარმოიდგინეთ, რომ თქვენი ღრუბლის ღირებულება 90%-ით შემცირდება მხოლოდ ერთი აპლიკაციისთვის ან მთელი კომპანიისთვის.
წადით და მიიღეთ თქვენი ყველაზე ძვირადღირებული აპლიკაციების სია და გააპროტესტეთ თქვენი დიზაინის ვარაუდები .
ყველა ეს კითხვა უბრუნდება ყველაზე მნიშვნელოვან კითხვას: როგორ იქნება აპლიკაციის გამოყენება? რა არის ბიზნესის ღირებულება მის არსებობისთვის? როგორ გვეხმარება აპლიკაცია მოცემული მიზნის მიღწევაში?
რა თქმა უნდა, ყველა ეს პასუხი ძალიან ხშირად გაურკვეველია პროექტის დასაწყისში; მაგრამ სწორედ ამიტომ, დიზაინი ყოველთვის უნდა იყოს განმეორებადი პროცესი - რაც საშუალებას მისცემს ცვლილებები მოხდეს რაც შეიძლება შეუფერხებლად. ინჟინრებმა უნდა გაითავისონ ევოლუცია და ცვლილებები, აპლიკაციის შემუშავების გათანაბრება გავლენასთან.
მეორე ნაბიჯი მოიცავს აპლიკაციის სწორი რესურსებით უზრუნველყოფას და სწორ ინფრასტრუქტურაზე მორგებას.
როგორც ინჟინერმა, იცოდეთ როგორ გამოითვლება ღრუბლის ხარჯები. მაგალითად, AWS გთავაზობთ წერტილოვან შემთხვევებს, სადაც შეგიძლიათ განაცხადოთ კლასტერული ფასი – ეს განსაკუთრებით სასარგებლოა, თუ თქვენ გაქვთ შეცდომისადმი ტოლერანტული და მოქნილი აპლიკაციები. გამოიყენეთ ისინი, თუ შეგიძლიათ — AWS აცხადებს ხარჯების 90%-მდე შემცირებას [ 4 ].
ზოგიერთი სხვა მოსაზრება, რომლის განხილვაც გსურთ, არის:
AWS Graviton-ის ინსტანციების გამოყენებაში მცირე ხარვეზებია. AWS-მა დიდი ინვესტიცია მოახდინა ყველაზე ეკონომიური პროცესორების შესაქმნელად. თქვენ შეგიძლიათ მიიღოთ ღრუბლოვანი ხარჯების 40%-მდე შემცირება მხოლოდ Intel-ზე დაფუძნებული პროცესორიდან ARM-ზე დაფუძნებულ პროცესორზე გადასვლით [ 10 ].
ამის ერთადერთი გაფრთხილება არის ის, რომ თქვენი აპლიკაცია უნდა იყოს თავსებადი ARM-ზე დაფუძნებულ პროცესორებთან, რომლებზეც მუშაობს Graviton. თუ საქმე გაქვთ ისეთ მართულ სერვისებთან, როგორიცაა RDS ან OpenSearch, მაშინ გადართვაში არანაირი გართულება არ არის – AWS ეხება ძირითად OS და აპლიკაციების თავსებადობას. თუ თქვენ ქმნით საკუთარ აპლიკაციას, მაშინ შეიძლება დაგჭირდეთ პაკეტის ხელახლა შედგენა იმისდა მიხედვით, თუ რომელ ენას იყენებთ - Java და სხვა ენები არ საჭიროებენ ცვლილებას, ხოლო Python მოითხოვს გარკვეულ ყურადღებას.
და ბოლოს, არ დაგავიწყდეთ გააგრძელოთ თქვენი ხარჯების მონიტორინგი მოულოდნელი მწვერვალებისა და სიურპრიზებისთვის. თქვენი განაცხადის 0 დღის ღირებულება განსხვავდება 170 დღის ღირებულებისგან. დარწმუნდით, რომ თვალყურს ადევნებთ ცვლილებებს და გესმით, რატომ ხდება ცვლილება: აგროვებს s3 შენახვის ხარჯებს თუ ეს მხოლოდ ერთჯერადია სპიკი?
დააყენეთ საჭირო გაფრთხილებები და ოპერაციული სახელმძღვანელოები !
მნიშვნელოვანია, დანერგეთ ხარჯების განაწილების ტეგები, რათა თვალყური ადევნოთ ხარჯებს დეპარტამენტის, პროექტის ან გარემოს მიხედვით. მოერიდეთ მონაცემთა ჭაობის შექმნის რისკს, სადაც ღირებულება მიუკვლეველია ან მოითხოვს გრძელ მოგზაურობას სხვადასხვა ჟურნალის სისტემაში. სწრაფი და მარტივი უნდა იყოს ნებისმიერი მოცემული განაცხადის ღირებულებაზე დაბრუნება.
სადაც არ უნდა მუშაობდეთ, რთულია ახალი ფუნქციების მიწოდების დაბალანსება მიმდინარე ფუნქციების ოპტიმიზაციასთან. ვისზეც არ ყოფილა ზეწოლა, რომ მიეწოდებინა ახალი უცნაური თვისებები სინათლის სიჩქარით.
თუმცა, ინჟინრებისთვისაც და მენეჯერებისთვისაც აუცილებელია მიზანმიმართული და აქტიური გადაწყვეტილებების მიღება მიმდინარე პროექტების შესახებ, რისკებისა და შესაძლებლობების ეფექტურად მართვაში.