Com guanyar 1 milió de dòlars amb AWS en un any

Si has topat amb aquesta pàgina pensant que et faràs ric amb algun esquema d'enriquiment ràpid, em sap greu decebre't. Aquest article parlarà més aviat de com reduir les factures de costos del núvol en 1 milió de dòlars. En fer-ho, bàsicament haureu generat un milió de dòlars addicionals en ingressos, que podeu gastar comprant el meu curs en línia sobre com enriquir-vos amb AWS ( enllaç al curs aquí ).

El cost del núvol sovint es passa per alt i no es té en compte a l'inici dels projectes de les empreses. L'enquesta de HashiCorp del 2021 va trobar que gairebé el 40% de les empreses van gastar en excés en costos del núvol el 2021 [ 1 ]. El 2023, gairebé totes les empreses (94%) van admetre que estaven malgastant diners al núvol [ 1 ] i que almenys el 30% del cost del núvol es va malgastar [ 2 ]. La despesa al núvol va ser de gairebé 500.000 milions de dòlars el 2022; per tant, estem parlant d'uns 150.000 milions de dòlars perduts a l'any!

No només això és una preocupació pels ingressos perduts, sinó també les pràctiques de sostenibilitat pobres. 150.000 milions de dòlars d'energia malgastada!

Aquestes troballes involucren grans empreses així com petites, des de la maduresa d'alt núvol fins a la maduresa de núvol baix. Es refereix a AWS, però els mateixos principis es poden aplicar a qualsevol altre proveïdor de núvol. Per tant, si alguna part de la vostra feina està al núvol, aquest article és per a vosaltres.

Parlo des d'una perspectiva d'enginyer de dades, però els mateixos aprenentatges es poden aplicar a altres pràctiques d'enginyeria de programari.

Submergem-nos.

Què es necessita per gastar 1 milió de dòlars en costos del núvol en un any?

Aquest tipus de factura al núvol sol estar restringida a empreses molt grans que operen a nivell mundial amb milions de clients.

Per fer-vos una idea, una factura al núvol d'1 milió de dòlars pot resultar d'un processament de treballs de Spark ETL ~ 1,5 Tb per hora les 24 hores del dia, els 7 dies del dia durant els 365 dies de l'any. Un altre exemple podria ser una aplicació que rep milers de milions de sol·licituds al dia des de diverses ubicacions del món.

En una gran empresa, hi ha centenars d'aplicacions d'aquesta mida, donant lloc a contractes de mil milions de dòlars amb proveïdors de núvol. Per exemple, Airbnb es va comprometre a gastar 1.200 milions de dòlars en recursos al núvol durant cinc anys a finals del 2019 [3 ].

A Expedia vam reduir els costos d'un ETL de processament de dades que costava 1,1 milions de dòlars anuals a només 100.000 dòlars l'any mitjançant la implementació de pràctiques d'optimització. Això és una reducció de costos del 91%!!

No totes les empreses tenen aplicacions d'una mida tan gran, però imagineu reduir el cost del vostre núvol en un 90% només per a una sola aplicació o per a tota la vostra empresa.

Com comencem a estalviar?

PAS 1: desafieu els vostres supòsits de disseny

Aneu i obteniu una llista de les vostres aplicacions més cares i desafieu els vostres supòsits de disseny .

• Esteu creant una aplicació que tingui una disponibilitat del 99,999% i una latència inferior a un mil·lisegon, però que, de manera realista, els usuaris serien prou bons amb una disponibilitat del 99% i una latència de centenars de mil·lisegons?
• Esteu creant conjunts de dades amb milers de milions de files, però els usuaris només farien servir agregacions d'algunes de les mesures?
• Esteu obtenint dades en temps real, però les dades només s'analitzen una vegada al dia?
• Esteu actualitzant la memòria cau cada 10 segons, però realment només canvia al llarg dels dies?

Totes aquestes preguntes es remunten a la pregunta més important: com s'utilitzarà l'aplicació? Quin és el valor empresarial perquè existeixi? Com ens ajuda l'aplicació a assolir un objectiu determinat?

Per descomptat, totes aquestes respostes sovint són poc clares a l'inici d'un projecte; però és per això que el disseny ha de ser sempre un procés iteratiu, permetent que els canvis es produeixin de la manera més perfecta possible. Els enginyers haurien d'acceptar l'evolució i el canvi, alineant el desenvolupament d'aplicacions amb l'impacte.

PAS 2: Ajusteu els vostres recursos d'infraestructura segons les vostres necessitats

El segon pas consisteix a proporcionar a l'aplicació els recursos adequats i ajustar-la a la infraestructura adequada.

Com a enginyer, tingueu en compte com es calculen els costos del núvol. Per exemple, AWS ofereix instàncies puntuals, on podeu fer una oferta pel preu del clúster; això és especialment útil si teniu aplicacions flexibles i tolerants a errors. Utilitzeu-los si podeu: AWS reclama fins a un 90% de reducció dels costos [ 4 ].

Algunes altres consideracions que potser voldreu abordar són:

• Esteu donant servei als clients a nivell mundial o només en una àrea geogràfica? Realment necessiteu la vostra infraestructura per viure a tot el món o podeu configurar-la més a prop de la vostra base de clients?
• Esteu sobreprovisionant les instàncies del clúster? Intenteu assegurar-vos que hi ha prou capacitat per gestionar les càrregues punta sense costos innecessaris. Utilitzeu l'escala automàtica per ajustar dinàmicament els recursos en funció de la demanda real, evitant el pagament excessiu dels recursos inactius.
• Si esteu treballant amb dades i Spark, assegureu-vos d'entendre els conceptes i l'ajustament de Spark! Si no ho feu, feu una ullada als recursos següents [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ].

PAS 3: utilitzeu instàncies d'AWS Graviton

Hi ha pocs o cap inconvenient en utilitzar instàncies AWS Graviton. AWS ha invertit molt en crear els processadors més rendibles. Podeu obtenir fins a un 40% de reducció de la despesa al núvol només canviant d'un processador basat en intel a un processador basat en ARM [ 10 ].

L'única advertència a això és que la vostra aplicació ha de ser compatible amb els processadors basats en ARM en què s'executa Graviton. Si esteu tractant amb un servei gestionat com ara RDS o OpenSearch, no hi ha cap complicació en canviar: AWS s'ocupa del sistema operatiu subjacent i la compatibilitat de les aplicacions. Si esteu creant la vostra pròpia aplicació, potser haureu de recompilar el paquet en funció del llenguatge que utilitzeu: Java i altres llenguatges no requereixen cap canvi, mentre que Python requereix una mica d'atenció.

PAS 4: Superviseu la vostra despesa en costos i eduqueu sobre la consciència dels costos

Finalment, no us oblideu de seguir supervisant els vostres costos per possibles pics i sorpreses inesperats. El cost del dia 0 de la vostra aplicació serà diferent del cost del dia 170. Assegureu-vos de fer un seguiment dels canvis i d'entendre per què s'està produint el canvi: s'acumula els costos d'emmagatzematge s3 o és només un únic espiga?

Configureu les alertes i guies operatives necessàries !

És important que implementeu etiquetes d'assignació de costos per fer un seguiment de la despesa per departament, projecte o entorn. Eviteu el risc de crear un pantà de dades on el cost no sigui rastrejable o requereixi un llarg viatge a través de diferents sistemes de registre. Hauria de ser ràpid i senzill tornar a qualsevol cost d'aplicació donat.

Pensaments finals

Allà on treballeu, és difícil equilibrar el lliurament de noves funcions amb l'optimització de les actuals. Qui no ha estat pressionat per oferir noves funcions peculiars a la velocitat de la llum.

Tanmateix, és essencial que tant els enginyers com els directius prenguin decisions deliberades i proactives sobre els seus projectes actuals, gestionant els riscos i les oportunitats de manera eficaç.