![Search icon](https://hackernoon.imgix.net/search-new.png?w=19&h=19)
Jos törmäsit tälle sivulle ajatellen rikastuvasi jollain rikastu nopeasti -suunnitelmalla, olen pahoillani, että joudun tuottamaan sinulle pettymyksen. Tässä artikkelissa puhutaan pikemminkin siitä, kuinka voit pienentää pilvikululaskujasi miljoonalla dollarilla. Tekemällä sen, olet käytännössä tuottanut ylimääräisen miljoonan dollarin tuloja - jonka voit käyttää ostamalla verkkokurssini AWS:n avulla rikastumisesta ( linkki kurssille täällä ).
Pilvikustannukset jäävät usein huomiotta ja huomiotta yritysten projektien alussa. Vuoden 2021 HashiCorp-kyselyssä havaittiin, että lähes 40 prosenttia yrityksistä käytti ylimääräisiä pilvikustannuksia vuonna 2021 [ 1 ]. Vuonna 2023 lähes kaikki yritykset (94 %) myönsivät tuhlaavansa rahaa pilveen [ 1 ] ja ainakin 30 % pilvikustannuksista meni hukkaan [ 2 ]. Pilvikäyttö oli lähes 500 miljardia dollaria vuonna 2022 – siksi puhumme 150 miljardista dollarista, joka menee hukkaan vuodessa!
Tämä ei koske vain menetettyjä tuloja, vaan myös huonoja kestävän kehityksen käytäntöjä. 150 miljardia dollaria hukattua energiaa!
Nämä havainnot koskevat suuria ja pienempiä yrityksiä korkean pilven kypsyydestä matalaan pilveen. Se viittaa AWS:ään, mutta samoja periaatteita voidaan soveltaa mihin tahansa muuhun pilvipalveluntarjoajaan. Joten jos jokin osa työstäsi on pilvessä, tämä artikkeli on sinua varten.
Puhun tietotekniikan näkökulmasta, mutta samaa oppia voidaan soveltaa muihin ohjelmistosuunnittelun käytäntöihin.
Sukeltakaamme sisään.
Tällainen pilvilasku rajoittuu yleensä erittäin suuriin yrityksiin, jotka toimivat maailmanlaajuisesti miljoonien asiakkaiden kanssa.
Jotta saat käsityksen, miljoonan dollarin pilvilasku voi johtua Spark ETL -työn käsittelystä ~1,5 Tb tunnissa 24x7 365 päivää vuodessa. Toinen esimerkki voi olla sovellus, joka vastaanottaa miljardeja pyyntöjä päivässä useista paikoista ympäri maailmaa.
Suuressa yrityksessä on satoja tämän kokoisia sovelluksia, mikä johtaa miljardin dollarin sopimuksiin pilvipalveluntarjoajien kanssa. Esimerkiksi Airbnb oli sitoutunut käyttämään 1,2 miljardia dollaria pilviresursseihin viiden vuoden aikana vuoden 2019 lopussa [3 ].
Leikkasimme Expedialla 1,1 miljoonaa dollaria vuodessa maksavan tietojenkäsittely-ETL:n kustannuksia vain 100 000 dollariin vuodessa ottamalla käyttöön optimointikäytännöt. Se on 91 % kustannussäästö!!
Kaikilla yrityksillä ei ole niin suuria sovelluksia, mutta kuvittele, että pilvikustannukset pienenevät 90 % vain yksittäisen sovelluksen tai koko yrityksesi osalta.
Mene ja hanki luettelo kalleimmista sovelluksistasi ja haasta suunnitteluoletuksesi .
Kaikki nämä kysymykset palaavat tärkeimpään kysymykseen: miten sovellusta aiotaan käyttää? Mikä on sen olemassaolon liikearvo? Kuinka sovellus auttaa meitä saavuttamaan tietyn tavoitteen?
Tietenkin kaikki nämä vastaukset ovat hyvin usein epäselviä projektin alussa; mutta siksi suunnittelun tulee aina olla iteratiivinen prosessi, jotta muutokset tapahtuvat mahdollisimman saumattomasti. Insinöörien tulee omaksua evoluutio ja muutos ja sovittaa sovelluskehitys vaikutuksiin.
Toinen vaihe koostuu oikeanlaisten resurssien tarjoamisesta sovellukselle ja sen virittämisestä oikeaan infrastruktuuriin.
Insinöörinä ole tietoinen siitä, miten pilvikustannukset lasketaan. Esimerkiksi AWS tarjoaa spot-esiintymiä, joissa voit tarjota klusterin hinnasta – tämä on erityisen hyödyllistä, jos sinulla on vikasietoisia ja joustavia sovelluksia. Käytä niitä, jos voit – AWS väittää jopa 90 %:n kustannussäästön [ 4 ].
Joitakin muita näkökohtia, joihin sinun kannattaa kiinnittää huomiota, ovat:
AWS Graviton -esiintymien käytössä ei ole juurikaan haittoja. AWS on investoinut voimakkaasti kustannustehokkaimpien prosessorien luomiseen. Voit saada jopa 40 % vähennyksen pilvikuluissa vain vaihtamalla Intel-pohjaisesta prosessorista ARM-pohjaiseen prosessoriin [ 10 ].
Ainoa varoitus tähän on, että sovelluksesi on oltava yhteensopiva Gravitonin käyttämien ARM-pohjaisten prosessorien kanssa. Jos olet tekemisissä hallitun palvelun, kuten RDS:n tai OpenSearchin, kanssa, vaihtamisessa ei ole lainkaan hankaluuksia – AWS käsittelee taustalla olevan käyttöjärjestelmän ja sovellusten yhteensopivuuden. Jos rakennat omaa sovellustasi, saatat joutua kääntämään paketin uudelleen sen mukaan, mitä kieltä käytät – Java ja muut kielet eivät vaadi muutoksia, kun taas Python vaatii huomiota.
Lopuksi, älä unohda seurata kulujasi odottamattomien huippujen ja yllätysten varalta. Kustannukset hakemuksesi päivänä 0 ovat erilaiset kuin 170. päivän kustannukset. Varmista, että seuraat muutoksia ja ymmärrät miksi muutos tapahtuu: onko kyseessä s3-tallennuskustannusten pinoaminen vai onko se vain kertaluonteinen piikki?
Aseta tarvittavat hälytykset ja toimintaohjeet !
Tärkeää on, että käytät kustannusten allokointitunnisteet seurataksesi kuluja osaston, projektin tai ympäristön mukaan. Vältä tietosuon syntymisen riski, jossa kustannuksia ei voida jäljittää tai se vaatii pitkän matkan eri lokijärjestelmien välillä. Palaamisen mihin tahansa tiettyyn hakemuskustannuksiin pitäisi olla nopeaa ja helppoa.
Missä tahansa työskenteletkin, uusien ominaisuuksien ja nykyisten optimoinnin tasapainottaminen on vaikeaa. Ketä ei ole painostettu toimittamaan uusia omituisia ominaisuuksia valonnopeudella.
Sekä insinöörien että johtajien on kuitenkin tärkeää tehdä tietoisia ja ennakoivia päätöksiä nykyisistä projekteistaan ja hallita riskejä ja mahdollisuuksia tehokkaasti.