![Search icon](https://hackernoon.imgix.net/search-new.png?w=19&h=19)
Om du stötte på den här sidan och trodde att du kommer att bli rik med något bli rik-snabbt-schema, är jag ledsen att besviken. Den här artikeln kommer snarare att prata om hur du kan minska dina molnkostnader med 1 miljon dollar. Genom att göra det kommer du i princip ha genererat en extra miljon dollar i intäkter — som du kan spendera på att köpa min onlinekurs om hur du blir rik med AWS ( länk till kursen här ).
Molnkostnaden förbises ofta och inte redovisas i början av företags projekt. HashiCorps undersökning från 2021 visade att nästan 40 % av företagen spenderade för mycket på molnkostnader 2021 [ 1 ]. År 2023 medgav nästan alla företag (94 %) att de slösade bort pengar på molnet [ 1 ] och minst 30 % av molnets kostnad var bortkastade [ 2 ]. Molnutgifterna var nästan 500 miljarder dollar 2022 — därför talar vi om 150 miljarder dollar som slösas bort per år!!
Detta är inte bara ett problem för uteblivna intäkter utan också dåliga hållbarhetsmetoder. 150 miljarder dollar av bortkastad energi!
Dessa fynd involverar stora företag såväl som mindre, från hög molnmognad till låg molnmognad. Det hänvisar till AWS, men samma principer kan tillämpas på vilken annan molnleverantör som helst. Så om någon del av ditt jobb är i molnet, då är den här artikeln för dig.
Jag talar ur ett dataingenjörsperspektiv, men samma lärdomar kan tillämpas på andra programvarutekniker.
Låt oss dyka in.
Denna typ av molnräkning är vanligtvis begränsad till mycket stora företag som verkar globalt med miljontals kunder.
För att ge dig en idé kan en molnnota på 1 miljon dollar resultera från ett Spark ETL-jobb som bearbetar ~1,5 Tb per timme 24x7 under 365 dagar om året. Ett annat exempel kan vara en applikation som tar emot miljarder förfrågningar om dagen från flera platser i världen.
I ett stort företag finns det hundratals applikationer i den här storleken – vilket resulterar i miljardkontrakt med molnleverantörer. Till exempel hade Airbnb ett åtagande att spendera 1,2 miljarder dollar på molnresurser under fem år i slutet av 2019 [3 ].
På Expedia sänkte vi kostnaderna för en databehandlings-ETL som kostar 1,1 miljoner dollar per år till bara 100 000 dollar per år genom att implementera optimeringsmetoder. Det är en kostnadsminskning på 91 %!!
Alla företag har inte applikationer av så stor storlek, men tänk dig att sänka dina molnkostnader med 90 % bara för en enskild applikation eller för hela ditt företag.
Gå och få en lista över dina dyraste applikationer och utmana dina designantaganden .
Alla dessa frågor går tillbaka till den viktigaste frågan: hur kommer applikationen att användas? Vad är affärsvärdet för att det ska finnas? Hur hjälper applikationen oss att uppnå ett givet mål?
Naturligtvis är alla dessa svar väldigt ofta oklara i början av ett projekt; men det är därför design alltid ska vara en iterativ process – så att förändringar kan ske så sömlöst som möjligt. Ingenjörer bör omfamna evolution och förändring, anpassa applikationsutveckling med effekt.
Det andra steget består av att förse applikationen med rätt resurser och ställa in den till rätt infrastruktur.
Som ingenjör, var medveten om hur molnkostnaderna beräknas. Till exempel tillhandahåller AWS spot-instanser där du kan bjuda på klusterpriset – detta är särskilt användbart om du har feltoleranta och flexibla applikationer. Använd dem om du kan — AWS hävdar att kostnaderna minskar med upp till 90 % [ 4 ].
Några andra överväganden du kanske vill ta upp är:
Det finns små eller inga nackdelar med att använda AWS Graviton-instanser. AWS har investerat mycket i att skapa de mest kostnadseffektiva processorerna. Du kan få upp till 40 % minskning av molnutgifterna bara genom att byta från en Intel-baserad processor till en ARM-baserad processor [ 10 ].
Den enda förbehållet till detta är att din applikation måste vara kompatibel med de ARM-baserade processorer som Graviton körs på. Om du har att göra med en hanterad tjänst som RDS eller OpenSearch så finns det ingen komplikation alls med att byta – AWS hanterar det underliggande operativsystemet och applikationskompatibiliteten. Om du bygger din egen applikation kan du behöva kompilera om paketet beroende på vilket språk du använder - Java och andra språk kräver ingen förändring medan Python kräver lite uppmärksamhet.
Slutligen, glöm inte att fortsätta övervaka dina kostnader för oväntade toppar och överraskningar. Kostnaden dag 0 av din ansökan kommer att skilja sig från kostnaden dag 170. Se till att du håller reda på ändringarna, och du förstår varför förändringen sker: staplar det s3-lagringskostnader eller är det bara en engångsföreteelse spika?
Ställ in nödvändiga varningar och driftguider !
Viktigt, implementera kostnadsfördelningstaggar för att spåra utgifter per avdelning, projekt eller miljö. Undvik risken att skapa ett dataträsk där kostnaden inte går att spåra eller kräver en lång resa över olika loggsystem. Det ska vara snabbt och enkelt att gå tillbaka till en given applikationskostnad.
Var du än arbetar är det svårt att balansera leveransen av nya funktioner med optimeringen av nuvarande. Vem har inte blivit pressad att leverera nya knäppa funktioner i ljusets hastighet.
Det är dock viktigt för både ingenjörer och chefer att fatta medvetna och proaktiva beslut om sina nuvarande projekt, hantera risker och möjligheter effektivt.