Sådan tjener du $1 million med AWS på ét år

Hvis du stødte ind på denne side og troede, at du vil blive rig med en bliv-rig-hurtig-ordning, er jeg ked af at skuffe dig. Denne artikel vil snarere tale om, hvordan du reducerer dine skyomkostningsregninger med $1 million. Ved at gøre det, vil du i det væsentlige have genereret en ekstra million dollars i omsætning - som du kan bruge på at købe mit online kursus om, hvordan du bliver rig med AWS ( link til kursus her ).

Cloud-omkostninger bliver ofte overset og ikke taget højde for i begyndelsen af virksomheders projekter. HashiCorp-undersøgelsen fra 2021 viste, at næsten 40 % af virksomhederne brugte for meget på cloud-omkostninger i 2021 [ 1 ]. I 2023 indrømmede næsten alle virksomheder (94 %), at de spildte penge på skyen [ 1 ] og mindst 30 % af skyomkostningerne var spildt [ 2 ]. Skyudgifterne var næsten 500 milliarder dollars i 2022 - derfor taler vi om 150 milliarder dollars spildt om året!!

Dette er ikke kun en bekymring for mistede indtægter, men også dårlig bæredygtighedspraksis. 150 milliarder dollars spildt energi!

Disse resultater involverer store virksomheder såvel som mindre, fra høj-sky-modenhed til lav-sky-modenhed. Det refererer til AWS, men de samme principper kan anvendes på enhver anden cloud-udbyder. Så hvis en del af dit job er i skyen, så er denne artikel noget for dig.

Jeg taler fra et dataingeniørperspektiv, men de samme erfaringer kan anvendes til andre softwareingeniørpraksis.

Lad os dykke ned.

Hvad skal der til for at bruge 1 million dollars i skyomkostninger på et år?

Denne form for skyregning er normalt begrænset til meget store virksomheder, der opererer globalt med millioner af kunder.

For at give dig en idé, kan en skyregning på 1 million dollar skyldes et Spark ETL-job, der behandler ~1,5 Tb i timen 24x7 i 365 dage om året. Et andet eksempel kan være en applikation, der modtager milliarder af anmodninger om dagen fra flere steder i verden.

I en stor virksomhed er der hundredvis af applikationer i denne størrelse - hvilket resulterer i milliardkontrakter med cloud-udbydere. For eksempel havde Airbnb en forpligtelse til at bruge $1,2 milliarder på cloud-ressourcer over fem år ved udgangen af 2019 [3 ].

Hos Expedia har vi reduceret omkostningerne til en databehandlings-ETL, der koster 1,1 millioner dollars om året, til kun 100.000 dollars om året ved at implementere optimeringspraksis. Det er en omkostningsreduktion på 91 %!!

Ikke alle virksomheder har applikationer af så stor en størrelse, men forestil dig at reducere dine cloudomkostninger med 90 % bare for en enkelt applikation eller for hele din virksomhed.

Hvordan begynder vi at spare?

TRIN 1: Udfordr dine designantagelser

Gå hen og få en liste over dine dyreste applikationer og udfordr dine designantagelser .

• Bygger du en applikation, der har en tilgængelighed på 99,999 % og en forsinkelse på under millisekunder, men realistisk set ville brugerne være gode nok med en tilgængelighed på 99 % og hundreder af millisekunders latency?
• Opretter du datasæt med milliarder af rækker, men brugere ville kun bruge aggregeringer af nogle af målene?
• Lander du data i realtid, men data analyseres kun én gang om dagen?
• Opdaterer du cachen hvert 10. sekund, men det ændrer sig kun rigtigt på tværs af dage?

Alle disse spørgsmål går tilbage til det vigtigste spørgsmål: hvordan skal applikationen bruges? Hvad er forretningsværdien for, at det eksisterer? Hvordan hjælper applikationen os med at nå et givent mål?

Selvfølgelig er alle disse svar meget ofte uklare i starten af et projekt; men det er derfor, design altid skal være en iterativ proces - så ændringer kan ske så problemfrit som muligt. Ingeniører bør omfavne evolution og forandring og tilpasse applikationsudvikling med effekt.

TRIN 2: Finjuster dine infrastrukturressourcer til dine behov

Det andet trin består i at forsyne applikationen med de rigtige ressourcer og tune den til den rigtige infrastruktur.

Som ingeniør skal du være opmærksom på, hvordan skyomkostninger beregnes. For eksempel leverer AWS spot-instanser, hvor du kan byde på klyngeprisen - dette er især nyttigt, hvis du har fejltolerante og fleksible applikationer. Brug dem, hvis du kan — AWS hævder at reducere omkostningerne med op til 90 % [ 4 ].

Nogle andre overvejelser, du måske vil tage stilling til, er:

• Betjener du kunder globalt eller kun i ét geografisk område? Har du virkelig brug for din infrastruktur til at leve over hele kloden, eller kan du sætte den tættere på din kundebase?
• Overprovisionerer du dine klyngeforekomster? Prøv at sikre, at der er nok kapacitet til at håndtere spidsbelastninger uden unødvendige omkostninger. Brug automatisk skalering til dynamisk at justere ressourcer baseret på faktisk efterspørgsel, hvilket forhindrer overbetaling for ledige ressourcer.
• Hvis du arbejder med data og Spark, skal du sørge for at forstå Spark-koncepter og tuning! Hvis du ikke gør det, så tag et kig på følgende ressourcer [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ].

TRIN 3: Brug AWS Graviton-instanser

Der er få eller ingen ulemper ved at bruge AWS Graviton-instanser. AWS har investeret massivt i at skabe de mest omkostningseffektive processorer. Du kan få op til 40 % reduktion i cloud-udgifter blot ved at skifte fra en intel-baseret processor til en ARM-baseret processor [ 10 ].

Den eneste advarsel til dette er, at din applikation skal være kompatibel med de ARM-baserede processorer, som Graviton kører på. Hvis du har at gøre med en administreret tjeneste såsom RDS eller OpenSearch, er der ingen komplikation overhovedet ved at skifte – AWS beskæftiger sig med det underliggende operativsystem og applikationskompatibilitet. Hvis du bygger din egen applikation, skal du muligvis omkompilere pakken afhængigt af hvilket sprog du bruger - Java og andre sprog kræver ingen ændring, hvorimod Python kræver noget opmærksomhed.

TRIN 4: Overvåg dine omkostningsudgifter, og undervis i omkostningsbevidsthed

Glem endelig ikke at holde øje med dine omkostninger for uventede peaks og overraskelser. Prisen på dag 0 af din ansøgning vil være anderledes end prisen på dag 170. Sørg for at holde styr på ændringerne, og du forstår, hvorfor ændringen sker: er det stabling af s3 lageromkostninger, eller er det blot en enkeltstående spids?

Opsæt de nødvendige advarsler og driftsvejledninger !

Det er vigtigt, at implementere omkostningsfordelingstags for at spore udgifter efter afdeling, projekt eller miljø. Undgå risikoen for at skabe en datasump, hvor omkostningerne ikke kan spores eller kræver en lang rejse på tværs af forskellige logsystemer. Det skal være hurtigt og enkelt at gå tilbage til enhver given ansøgningsomkostning.

Sidste tanker

Uanset hvor du arbejder, er det svært at balancere leveringen af nye funktioner med optimeringen af de nuværende. Hvem er ikke blevet presset til at levere nye finurlige funktioner med lysets hastighed.

Det er dog essentielt for både ingeniører og ledere at træffe bevidste og proaktive beslutninger om deres nuværende projekter og håndtere risici og muligheder effektivt.