![Search icon](https://hackernoon.imgix.net/search-new.png?w=19&h=19)
Ha betoppant erre az oldalra, és azt gondolta, hogy valami "gyors meggazdagodás" tervvel fog meggazdagodni, sajnálom, hogy csalódást okozok. Ez a cikk inkább arról fog szólni, hogyan csökkentheti a felhőalapú költségszámlákat 1 millió dollárral. Ezzel lényegében további egymillió dollár bevételre tehet szert – amit elkölthet az AWS-el való gazdagodásról szóló online tanfolyamom megvásárlására ( a kurzus linkje itt ).
A felhőköltségeket gyakran figyelmen kívül hagyják, és nem veszik figyelembe a vállalatok projektjei kezdetén. A 2021-es HashiCorp felmérés szerint a vállalatok csaknem 40%-a túlköltekezett a felhőköltségekre 2021-ben [ 1 ]. 2023-ban szinte minden vállalat (94%) elismerte, hogy pénzt pazarol a felhőre [ 1 ], és a felhőköltségek legalább 30%-a elpazarolt [ 2 ]. 2022-ben a felhőre fordított kiadások csaknem 500 milliárd dollárt tettek ki – tehát évente 150 milliárd dollár elpazaroltságról beszélünk!
Ez nemcsak az elmaradt bevételekkel, hanem a rossz fenntarthatósági gyakorlatokkal is aggodalomra ad okot. 150 milliárd dollár elpazarolt energia!
Ezek az eredmények nagyvállalatokra és kisebbekre egyaránt vonatkoznak, a magas felhőalapútól az alacsony felhőalapú érettségig. Az AWS-re vonatkozik, de ugyanezek az elvek bármely más felhőszolgáltatóra is alkalmazhatók. Tehát, ha munkája bármely része a felhőben van, akkor ez a cikk neked szól.
Adatmérnöki szemszögből beszélek, de ugyanezek a tanulságok más szoftvermérnöki gyakorlatokban is alkalmazhatók.
Merüljünk el.
Az ilyen típusú felhőalapú számlák általában nagyon nagy vállalkozásokra korlátozódnak, amelyek világszerte több millió ügyféllel működnek.
Hogy ötletet adjunk, 1 millió dolláros felhőalapú számla származhat egy Spark ETL-feladatból, amelynek feldolgozása óránként ~1,5 Tb 24x7, az év 365 napján. Egy másik példa lehet egy olyan alkalmazás, amely naponta több milliárd kérést kap a világ több helyéről.
Egy nagyvállalatnál több száz ilyen méretű alkalmazás létezik, ami milliárd dolláros szerződéseket köt a felhőszolgáltatókkal. Például az Airbnb kötelezettséget vállalt arra, hogy 2019 végén öt éven keresztül 1,2 milliárd dollárt költ felhőforrásokra [3 ].
Az Expedián optimalizálási gyakorlatok bevezetésével csökkentettük az évi 1,1 millió dollárba kerülő adatfeldolgozási ETL költségeit évi 100 000 dollárra. Ez 91%-os költségcsökkentést jelent!!
Nem minden vállalat rendelkezik ilyen hatalmas méretű alkalmazásokkal, de képzelje el, hogy 90%-kal csökkentheti felhőköltségeit egyetlen alkalmazás vagy az egész vállalat esetében.
Menjen el, és szerezze be a legdrágább alkalmazásai listáját, és kérdőjelezze meg tervezési feltételezéseit .
Mindezek a kérdések a legfontosabb kérdéshez nyúlnak vissza: hogyan fogják használni az alkalmazást? Mi az üzleti érték a létezéshez? Hogyan segít az alkalmazás egy adott cél elérésében?
Természetesen ezek a válaszok nagyon gyakran homályosak egy projekt elején; de éppen ezért a tervezésnek mindig iteratív folyamatnak kell lennie – lehetővé téve a változtatások lehető legzökkenőmentesebb megtörténését. A mérnököknek fel kell venniük az evolúciót és a változást, összehangolva az alkalmazásfejlesztést a hatásokkal.
A második lépés az alkalmazás megfelelő erőforrásokkal való ellátása és a megfelelő infrastruktúrára való hangolása.
Mérnökként legyen tisztában a felhőköltségek kiszámításával. Például az AWS azonnali példányokat biztosít, ahol ajánlatot tehet a fürt árára – ez különösen akkor hasznos, ha hibatűrő és rugalmas alkalmazásai vannak. Ha teheti, használja őket – az AWS akár 90%-os költségcsökkentést is állít [ 4 ].
Néhány további megfontolás, amellyel foglalkozni szeretne:
Az AWS Graviton-példányok használatának nincs vagy alig van hátránya. Az AWS sokat fektetett a legköltséghatékonyabb processzorok létrehozásába. Akár 40%-os csökkenést is elérhet a felhőköltségekben, ha Intel-alapú processzorról ARM-alapú processzorra vált [ 10 ].
Az egyetlen figyelmeztetés ezzel kapcsolatban az, hogy az alkalmazásnak kompatibilisnek kell lennie azokkal az ARM-alapú processzorokkal, amelyeken a Graviton fut. Ha olyan felügyelt szolgáltatással foglalkozik, mint az RDS vagy az OpenSearch, akkor a váltás egyáltalán nem okoz bonyodalmat – az AWS az alapul szolgáló operációs rendszerrel és az alkalmazások kompatibilitásával foglalkozik. Ha saját alkalmazást készít, akkor előfordulhat, hogy a használt nyelvtől függően újra kell fordítania a csomagot – a Java és más nyelvek nem igényelnek változtatást, míg a Python némi figyelmet igényel.
Végül ne felejtse el folyamatosan figyelemmel kísérni költségeit a váratlan csúcsok és meglepetések miatt. Az alkalmazás 0. napjának költsége el fog térni a 170. napi költségtől. Ügyeljen arra, hogy nyomon kövesse a változásokat, és megértse, miért történik a változás: az s3 tárolási költségeinek halmozásáról van szó, vagy csak egyszeri tüske?
Készítse el a szükséges riasztásokat és üzemeltetési útmutatókat !
Fontos, hogy a költségelosztási címkéket részleg, projekt vagy környezet szerint nyomon követhesse. Kerülje el annak kockázatát, hogy olyan adatmocsár jöjjön létre, ahol a költségek nyomon követhetetlenek vagy hosszú utat igényelnek a különböző naplórendszereken keresztül. Gyorsnak és egyszerűnek kell lennie, hogy visszatérjen bármely adott alkalmazási költséghez.
Bárhol is dolgozik, nehéz egyensúlyt teremteni az új funkciók és a jelenlegiek optimalizálása között. Akit ne kényszerítettek volna arra, hogy fénysebességgel új, különleges funkciókat biztosítson.
Mindazonáltal mind a mérnökök, mind a vezetők számára elengedhetetlen, hogy tudatos és proaktív döntéseket hozzanak jelenlegi projektjeikről, hatékonyan kezelve a kockázatokat és a lehetőségeket.