Programmering

7 mørke hemmeligheder med skyomkostninger

Er der noget mere forførende end cloud-maskinlister? Der er ikke mange af os, der er gamle nok til at huske at betale en krone for et stykke slik, men skybrugere nyder priser, der er endnu mindre.

Googles N1-standardmaskins pris er 0,0475 $ i timen, men du kan få den til kun 0,0100 $ i timen til dine batchbehandlingsbehov - hvis du er villig til at blive forhindret af vigtigere job. De skøre forbrugere kan træde op til den høje CPU-version for $ 0,015 i timen - stadig mindre end to cent. Woo-hoo!

Azure opkræver et minimalt $ 0,00099 per gigabyte for at gemme data i en måned i dets arkivlager. Amazon tilbyder dog muligvis de mest iøjnefaldende lave priser - opkræver en uendelig $ 0.0000002083 $ for 128 megabyte hukommelse for at understøtte en Lambda-funktion. (Fire cifre med præcision?)

Disse små tal kaster os ude af vagt. Lægeforsikring og ejendomsregninger knuser måske budgettet, men når det kommer til skyen, kan vi nyde at smide penge rundt som konfetti. Det skyldes, at priserne på mange skytjenester bogstaveligt talt er lavere end prisen på et stykke konfetti.

Så kommer slutningen af ​​måneden, og skyregningen er meget større end nogen havde forventet. Hvordan tilføjes disse fraktioner af øre så hurtigt?

Her er syv mørke hemmeligheder om, hvordan skyfirmaerne gør fraktioner af cent til rigtige penge.

Skjulte “ekstra”

Nogle gange er de mest prægtige numre domineret af de ekstra, som du ikke bemærker. Amazons S3 Glacier har et "Deep Archive" -lag designet til langsigtede sikkerhedskopier, der forførende er prissat til $ 0,00099 pr. Gigabyte, noget der fungerer til $ 1 per terabyte pr. Måned. Det er let at forestille sig at lægge backupbåndene og besværet til side for at gøre det nemmere for Amazons service.

Men lad os sige, at du rent faktisk vil se på disse data. Hvis du klikker igennem til en anden fane på prisarket, kan du se, at omkostningerne ved hentning er $ 0,02 pr. Gigabyte. Det er 20 gange dyrere at se på dataene end at gemme dem i en måned. Hvis en restaurant brugte denne prismodel, ville de opkræve dig $ 2 for bøfmiddagen, men $ 40 for sølvtøj.

Jeg formoder, at Amazons prisfastsættelsesmodel giver masser af mening, fordi de designet produktet til at understøtte langtidsopbevaring ikke afslappet browsing og endeløs rapportgenerering. Hvis vi ønsker hyppig adgang, kan vi betale for det almindelige S3-niveau. Men hvis målet er at spare arkivering, er vi nødt til at forstå de sekundære omkostninger og planlægge.

Placering betyder noget

Skyfirmaerne blænder os ofte med kort, der viser datacentre over hele kloden, og opfordrer os til at parkere vores arbejdsbelastninger, uanset hvor vi føler os mest komfortable. Priserne er dog ikke altid de samme. Amazon opkræver muligvis $ 0,00099 per gigabyte i Ohio, men det er $ 0,002 per gigabyte i det nordlige Californien. Er det det varme vejr? Nærheden til stranden? Eller bare udgifterne til fast ejendom?

Alibaba, det kinesiske skyfirma, ønsker helt klart at tilskynde udviklere til at bruge deres datacentre over hele kloden. Lavtliggende forekomster starter med kun $ 2,50 pr. Måned uden for Kina, men springer til $ 7 pr. Måned i Hongkong og $ 15 pr. Måned på det kinesiske fastland.

Det er op til os at overvåge disse priser og vælge i overensstemmelse hermed. Vi kan ikke vælge datacentre, bare fordi de virker mere bekvemme eller er ideelle kandidater til en inspektionstur.

Omkostninger til dataoverførsel

Det eneste problem med at undersøge prislisterne og flytte vores arbejdsbyrde til de billigste datacentre er, at skyfirmaerne også opkræver betaling for dataflytning. Hvis vi forsøger at være kloge og arbitrage omkostningerne ved at flytte bits rundt om i kloden og søge efter den billigste beregning og lagring, kan vi ende med større regninger for at flytte dataene.

Omkostningerne til datastrøm over hele netværket er overraskende store. Åh, en lejlighedsvis gigabyte gør ikke en forskel, men det kan være en stor fejl at replikere en ofte opdateret database over hele landet hvert millisekund, bare fordi der kan komme et jordskælv eller orkan.

Roach moteller

De berømte annoncer for en kakerlakfælde annoncerede: "Kakerlakker tjekker ind, men de tjekker ikke ud." Du har det måske på samme måde, når du ser på omkostningerne ved dataudgang. Cloudfirmaer debiterer dig ofte ikke for at bringe data ind i skyen. Ville en butik opkræve en kunde for at gå ind døren? Men hvis du forsøger at sende dataene ud, er regningen for udgang uendeligt større.

Dette kan bide enhver, lille eller stor, der ser noget indhold blive viralt. Pludselig ønsker alle at se noget meme eller video på din server, og da din webserver modigt opfylder alle anmodninger, drejer måleren til udladningsafgifter hurtigere og hurtigere.

Uheldige fejl i fejl

Der er altid øjeblikke, hvor den aktuelle maskine eller konfiguration vil kæmpe for at udføre jobbet, men hvis du bare øger størrelsen, vil det være fint. Og det er kun få cent ekstra i timen. Hvis vi allerede betaler flere dollars i timen, vil nogle få øre ikke slå os i konkurs. Og skyvirksomhederne er der for at hjælpe med blot et klik.

Kasinoer kender den samme vej til vores tegnebøger. Vi er allerede kommet så langt - en anden lille betaling er intet. Men skarpe blyant-revisorer ved, at den sænkede omkostningsfejl - altså at kaste gode penge efter dårlige - er et stort problem for spillere, ledere og stort set alle undtagen små børn. De penge, vi har brugt, er væk. Det kommer aldrig nogensinde tilbage. Nye udgifter er dog noget, vi kan kontrollere.

Det er lidt anderledes, når du udvikler software. Vi kan ofte ikke være sikre på, hvor meget hukommelse eller CPU en funktion kræver. Vi bliver nødt til at samle maskinernes magt noget af tiden. Den virkelige udfordring er at holde øje med budgettet og kontrollere omkostningerne undervejs. Bare tilføj lidt mere CPU her eller hukommelse med glæde, der er stien til en stor regning i slutningen af ​​måneden.

Overhead

En skymaskine er ikke en maskine i sig selv, men et stykke af en større fysisk maskine, der er opdelt i N-dele. Skiverne er dog ikke stærke nok til at håndtere belastningen alene, så vi implementerer værktøjer som Kubernetes for at holde N-stykker sammen. Hvorfor skærer vi en fedtkasse i N stykker bare for at sy den sammen igen? Hvorfor ikke bare have den ene fedtmaskine, der håndterer en fedtbelastning?

Cloudevangelister siger måske, at folk, der stiller uhøjtidelige spørgsmål som det, ikke får fordelene ved skyen. Alle de ekstra lag og ekstra kopier af operativsystemet giver masser af redundans og fleksibilitet. Vi skal være taknemmelige for, at alle disse forekomster starter og lukker ned i en detaljeret, orkestreret dans.

Men den lette genopretning med Kubernetes tilskynder til sjusket programmering. En knudefejl er ikke et problem, fordi pod'en sejler videre, da Kubernetes erstatter forekomsten. Så vi betaler lidt mere for alt overhead for at opretholde de ekstra lag, taknemmelige for, at vi bare kan starte en ren frisk maskine uden noget af det krypt, der ser ud til at komme i vejen.

Uendelig sky

I sidste ende er det vanskelige problem med cloud computing, at den bedste funktion, dens tilsyneladende uendelige evne til at skalere op for at håndtere enhver efterspørgsel, også er et budgetmine felt. Skal hver bruger gennemsnitligt udgøre 10 gigabyte eller 20 gigabyte? Har hver server brug for to gigabyte RAM eller fire? Når vi starter projekterne, er det umuligt at vide det.

Den gamle løsning at købe et fast antal servere til et projekt kan begynde at klemme, når efterspørgslen øges, men i det mindste skyder budgetomkostningerne ikke op. Fans på serverne klynker muligvis fra hele belastningen, og brugerne rykker muligvis over det langsomme svar, men du får ikke et panikopkald fra regnskabsteamet.

Vi kan tegne blyanter sammen, men ingen ved det rigtig. Derefter dukker brugerne op, og alt kan ske. Ingen bemærker, hvornår omkostningerne kommer lavere, men når måleren begynder at dreje hurtigere og hurtigere, begynder chefen at være opmærksom. Det dybeste problem er, at vores bankkonti ikke skaleres som skyen.

$config[zx-auto] not found$config[zx-overlay] not found