![Search icon](https://hackernoon.imgix.net/search-new.png?w=19&h=19)
As jy hierdie bladsy raakgeloop het en gedink jy gaan ryk word met een of ander vinnig-ryk-ryk-skema, is ek jammer om jou teleur te stel. Hierdie artikel sal eerder praat oor hoe om jou wolkkosterekeninge met $1 miljoen te verminder. Deur dit te doen, sal jy in wese 'n ekstra miljoen dollar se inkomste gegenereer het - wat jy kan spandeer om my aanlyn kursus te koop oor hoe om ryk te word met AWS ( skakel na kursus hier ).
Wolkkoste word dikwels aan die begin van Maatskappye se projekte oor die hoof gesien en nie verreken nie. Die 2021 HashiCorp-opname het bevind dat byna 40% van maatskappye in 2021 oorbestee het aan wolkkoste [ 1 ]. In 2023 het byna alle maatskappye (94%) erken dat hulle geld op die wolk mors [ 1 ] en ten minste 30% van wolkkoste is vermors [ 2 ]. Wolkbesteding was byna $500 miljard in 2022 — daarom praat ons van $150 miljard wat per jaar vermors word!!
Dit is nie net 'n bekommernis oor gemiste inkomste nie, maar ook swak volhoubaarheidspraktyke. $150 miljard se vermorste energie!
Hierdie bevindings behels groot ondernemings sowel as kleiner ondernemings, van hoë-wolk-volwassenheid tot lae-wolk-volwassenheid. Dit verwys na AWS, maar dieselfde beginsels kan op enige ander wolkverskaffer toegepas word. Dus, as enige deel van jou werk in die wolk is, dan is hierdie artikel vir jou.
Ek praat vanuit 'n data-ingenieur-perspektief, maar dieselfde leerstellings kan op ander sagteware-ingenieurspraktyke toegepas word.
Kom ons duik in.
Hierdie soort wolkrekening is gewoonlik beperk tot baie groot ondernemings wat wêreldwyd met miljoene kliënte werk.
Om jou 'n idee te gee, kan 'n wolkrekening van $1 miljoen die gevolg wees van 'n Spark ETL-werk wat ~1.5Tb per uur 24x7 vir 365 dae per jaar verwerk. Nog 'n voorbeeld kan 'n toepassing wees wat miljarde versoeke per dag van verskeie plekke in die wêreld ontvang.
In 'n groot onderneming is daar honderde toepassings van hierdie grootte - wat lei tot miljard-dollar-kontrakte met wolkverskaffers. Airbnb het byvoorbeeld 'n verbintenis gehad om aan die einde van 2019 $1,2 miljard aan wolkhulpbronne oor vyf jaar te bestee [3 ].
By Expedia het ons koste verlaag vir 'n dataverwerkings-ETL wat $1,1 miljoen dollar per jaar kos tot slegs $100 000 per jaar deur optimaliseringspraktyke te implementeer. Dit is 'n 91% kostevermindering!!
Nie alle maatskappye het toepassings van so 'n groot grootte nie, maar stel jou voor om jou wolkkoste met 90% te sny net vir 'n enkele toepassing of vir jou hele maatskappy.
Gaan kry 'n lys van jou duurste toepassings en daag jou ontwerpaannames uit .
Al hierdie vrae gaan terug na die belangrikste vraag: hoe gaan die toepassing gebruik word? Wat is die besigheidswaarde vir dit om te bestaan? Hoe help die toepassing ons om 'n gegewe doelwit te bereik?
Al hierdie antwoorde is natuurlik baie dikwels onduidelik aan die begin van 'n projek; maar dit is hoekom ontwerp altyd 'n iteratiewe proses moet wees - sodat veranderinge so naatloos moontlik kan plaasvind. Ingenieurs moet evolusie en verandering omhels en toepassingsontwikkeling in lyn bring met impak.
Die tweede stap bestaan om die toepassing van die regte hulpbronne te voorsien en dit op die regte infrastruktuur in te stel.
As 'n ingenieur, wees bewus van hoe wolkkoste bereken word. AWS bied byvoorbeeld spotgevalle waar u vir die groepprys kan bie – dit is veral nuttig as u foutverdraagsame en buigsame toepassings het. Gebruik hulle as jy kan - AWS eis tot 90% vermindering in koste [ 4 ].
Sommige ander oorwegings wat jy dalk wil aanspreek, is:
Daar is min of geen nadele in die gebruik van AWS Graviton-gevalle. AWS het baie belê in die skep van die mees koste-effektiewe verwerkers. Jy kan tot 40% vermindering in wolkbesteding kry net deur oor te skakel van 'n intel-gebaseerde verwerker na 'n ARM-gebaseerde verwerker [ 10 ].
Die enigste voorbehoud hiervoor is dat jou toepassing versoenbaar moet wees met die ARM-gebaseerde verwerkers waarop Graviton loop. As jy met 'n bestuurde diens soos RDS of OpenSearch te doen het, is daar geen komplikasie om oor te skakel nie - AWS handel oor die onderliggende bedryfstelsel en toepassingsversoenbaarheid. As jy jou eie toepassing bou, moet jy dalk die pakket hersaamstel, afhangende van watter taal jy gebruik - Java en ander tale vereis geen verandering nie, terwyl Python aandag verg.
Laastens, moenie vergeet om aan te hou om jou koste te monitor vir onverwagte hoogtepunte en verrassings nie. Die koste op dag 0 van jou aansoek sal verskil van die koste op dag 170. Maak seker dat jy tred hou met die veranderinge, en jy verstaan hoekom die verandering plaasvind: stapel dit s3 stoorkoste of is dit net 'n eenmalige spyker?
Stel die nodige waarskuwings en operasionele gidsboeke op !
Wat belangrik is, implementeer kostetoewysingsetikette om besteding volgens departement, projek of omgewing na te spoor. Vermy die risiko om 'n datamoeras te skep waar koste onopspoorbaar is of 'n lang reis deur verskillende logstelsels vereis. Dit behoort vinnig en eenvoudig te wees om terug te gaan na enige gegewe aansoekkoste.
Waar jy ook al werk, is dit moeilik om die lewering van nuwe kenmerke te balanseer met die optimalisering van huidige. Wie is nie onder druk geplaas om nuwe eienaardige kenmerke teen die spoed van lig te lewer nie.
Dit is egter noodsaaklik vir beide ingenieurs en bestuurders om doelbewuste en proaktiewe besluite oor hul huidige projekte te neem, om risiko's en geleenthede effektief te bestuur.