Programmering

7 mørke hemmeligheter med skykostnader

Er det noe mer forførende enn prislister for skymaskiner? Det er ikke mange av oss som er gamle nok til å huske å betale en krone for et godteri, men skybrukere nyter priser som er enda mindre.

Googles N1-standardmaskin pris er $ 0,0475 per time, men du kan få den for bare $ 0,0100 per time for dine batchbehandlingsbehov - hvis du er villig til å bli forhindret av viktigere jobber. De gale brukerne kan gå opp til den høye CPU-versjonen for $ 0,015 per time - fortsatt mindre enn to cent. Woo-hoo!

Azure belaster et minimisk $ 0,00099 per gigabyte for å lagre data i en måned i arkivlagringsnivået. Amazon kan imidlertid tilby de mest iøynefallende lave prisene - å lade uendelig minimale $ 0,0000002083 for 128 megabyte minne for å støtte en Lambda-funksjon. (Fire sifre med presisjon?)

De små tallene kaster oss utenfor vakta. Medisinske forsikringer og eiendomsregninger kan knuse budsjettet, men når det kommer til skyen kan vi glede oss over å kaste penger rundt som konfetti. Det er fordi prisene for mange skytjenester er bokstavelig talt lavere enn kostnaden for et stykke konfetti.

Så kommer slutten av måneden, og skyregningen er mye større enn noen forventet. Hvordan legger disse fraksjonene av øre seg så raskt?

Her er syv mørke hemmeligheter om hvordan skyselskapene gjør brøkdeler av cent til ekte penger.

Skjulte “statister”

Noen ganger domineres de flotteste tallene av tilleggene du ikke legger merke til. Amazons S3 Glacier har et "Deep Archive" -nivå designet for langsiktige sikkerhetskopier som er priset forførende til $ 0,00099 per gigabyte, noe som fungerer til $ 1 per terabyte per måned. Det er lett å forestille seg å legge til side sikkerhetskopibåndene og bryderiet for enkelheten til Amazons tjeneste.

Men la oss si at du faktisk vil se på dataene. Hvis du klikker deg gjennom til en annen fane på prisarket, kan du se at kostnaden for henting er $ 0,02 per gigabyte. Det er 20 ganger dyrere å se på dataene enn å lagre det i en måned. Hvis en restaurant brukte denne prismodellen, ville de belaste deg $ 2 for biffmiddagen, men $ 40 for sølvtøyet.

Jeg antar at Amazons prismodell gir god mening fordi de designet produktet for å støtte langvarig lagring, ikke uformell surfing og endeløs generering av rapporter. Hvis vi ønsker hyppig tilgang, kan vi betale for det vanlige S3-nivået. Men hvis målet er å spare arkivering, må vi forstå de sekundære kostnadene og planlegge fremover.

Sted betyr noe

Skyselskapene blender oss ofte med kart som viser datasentre over hele kloden, og inviterer oss til å parkere arbeidsbelastningen vår uansett hvor vi føler oss mest komfortable. Prisene er imidlertid ikke alltid de samme. Amazon tar kanskje $ 0,00099 per gigabyte i Ohio, men det er $ 0,002 per gigabyte i Nord-California. Er det det varme været? Nærheten til stranden? Eller bare kostnadene for eiendom?

Alibaba, det kinesiske skyselskapet, ønsker tydeligvis å oppmuntre utviklere til å bruke datasentre over hele verden. Avanserte forekomster starter på bare $ 2,50 per måned utenfor Kina, men hopper til $ 7 per måned i Hong Kong og $ 15 per måned på fastlands-Kina.

Det er opp til oss å se på disse prisene og velge deretter. Vi kan ikke velge datasentre bare fordi de virker mer praktiske eller er ideelle kandidater for en inspeksjonstur.

Kostnader for dataoverføring

Det eneste problemet med å granske prislistene og flytte arbeidsmengden til de billigste datasentrene er at skyselskapene også tar betalt for dataflytting. Hvis vi prøver å være smarte og arbitrage kostnadene ved å flytte biter rundt om i verden på jakt etter den billigste beregningen og lagringen, kan vi ende opp med større regninger for å flytte dataene.

Kostnadene for dataflyt over nettverket er overraskende store. Å, en og annen gigabyte vil ikke utgjøre en forskjell, men det kan være en stor feil å replikere en ofte oppdatert database over hele landet hvert millisekund bare fordi noe jordskjelv eller orkan kan komme.

Roach moteller

De berømte annonsene for en kakerlakkfelle kunngjorde: "Kakerlakker sjekker inn, men de sjekker ikke ut." Du kan føle det samme når du ser på kostnadene for datautgangen. Skyselskaper belaster deg ofte ikke for å bringe data inn i skyen. Ville en butikk kreve en kunde å gå inn døra? Men hvis du prøver å sende ut dataene, er utgiftsregningen uendelig større.

Dette kan bite alle, små eller store, som ser noe på innholdet blir viralt. Plutselig ønsker alle å se noe meme eller video på serveren din, og siden webserveren din tappert tilfredsstiller alle forespørslene, spinner måleren for utgående kostnader raskere og raskere.

Senket kostnad feilslutning

Det er alltid øyeblikk når den nåværende maskinen eller konfigurasjonen vil slite med å gjøre jobben, men hvis du bare øker størrelsen, vil det være bra. Og det er bare noen få ekstra per time. Hvis vi allerede betaler flere dollar i timen, vil ikke ytterligere noen øre slå oss konkurs. Og skyselskapene er der for å hjelpe med bare et klikk.

Kasinoer kjenner den samme veien til lommebøkene våre. Vi har allerede kommet så langt - nok en liten betaling er ingenting. Men skarpe blyantregnskapsførere vet at den sunkne kostnaden av feil - også kaste gode penger etter dårlige - er et stort problem for spillere, ledere og stort sett alle andre enn små barn. Pengene vi har brukt er borte. Det kommer aldri tilbake. Nye utgifter er imidlertid noe vi kan kontrollere.

Det er litt annerledes når du utvikler programvare. Vi kan ofte ikke være sikre på hvor mye minne eller CPU en funksjon vil kreve. Vi blir nødt til å samle kraften til maskinene en del av tiden. Den virkelige utfordringen er å holde øye med budsjettet og kontrollere kostnadene underveis. Bare bare å legge til litt mer CPU her eller minne, er det veien til en stor regning på slutten av måneden.

Overhead

En skymaskin er ikke en maskin i seg selv, men en del av en større fysisk maskin som er delt inn i N-deler. Skivene er imidlertid ikke kraftige nok til å håndtere belastningen på egenhånd, så vi distribuerer verktøy som Kubernetes for å holde N-stykker i arbeid. Hvorfor kutter vi en fettboks i N-stykker bare for å sy den sammen igjen? Hvorfor ikke bare ha den ene fettmaskinen som håndterer en fettbelastning?

Skyevangelister kan si at folk som stiller uhåndterlige spørsmål som det, ikke får fordelene med sky. Alle de ekstra lagene og ekstra kopiene av operativsystemet gir rikelig med redundans og fleksibilitet. Vi bør være takknemlige for at alle disse tilfellene starter og lukkes i en forseggjort, orkestrert dans.

Men enkel utvinning med Kubernetes oppmuntrer til slurvet programmering. En nodefeil er ikke et problem fordi poden vil seile videre når Kubernetes erstatter forekomsten. Så vi betaler litt mer for alt overhead for å opprettholde de ekstra lagene, takknemlige for at vi bare kan starte en ren fersk maskin uten noe av cruft som ser ut til å komme i veien.

Uendelig sky

Til slutt er det vanskelige problemet med cloud computing at den beste funksjonen, dens tilsynelatende uendelige evne til å skalere opp for å håndtere enhver etterspørsel, også er et budsjettfelt. Skal hver bruker gjennomsnittlig 10 gigabyte utgang eller 20 gigabyte? Trenger hver server to gigabyte RAM eller fire? Når vi starter prosjektene, er det umulig å vite.

Den gamle løsningen for å kjøpe et fast antall servere for et prosjekt kan begynne å klemme når etterspørselen øker, men i det minste skyter ikke budsjettkostnadene opp. Fans på serverne kan sutre fra hele belastningen, og brukerne kan rype om den langsomme responsen, men du får ikke et panikkanrop fra regnskapsteamet.

Vi kan tegne blyanter sammen, men ingen vet det egentlig. Da dukker brukerne opp og alt kan skje. Ingen merker når kostnadene kommer lavere, men når måleren begynner å snurre raskere og raskere, begynner sjefen å være oppmerksom. Det dypeste problemet er at bankkontoene våre ikke skaleres som skyen.

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