![Search icon](https://hackernoon.imgix.net/search-new.png?w=19&h=19)
Se atopaches esta páxina pensando que te vas facer rico con algún esquema de enriquecemento rápido, lamento decepcionarte. Este artigo falará máis ben sobre como diminuír as facturas dos custos da nube en 1 millón de dólares. Ao facelo, xerará esencialmente un millón de dólares extra en ingresos, que pode gastar comprando o meu curso en liña sobre como facerse rico con AWS ( ligazón ao curso aquí ).
O custo da nube adoita pasarse por alto e non se contabiliza ao comezo dos proxectos das empresas. A enquisa de HashiCorp de 2021 descubriu que case o 40% das empresas gastaron en exceso en custos da nube en 2021 [ 1 ]. En 2023, case todas as empresas (94%) admitiron que estaban a perder cartos na nube [ 1 ] e que polo menos o 30% do custo da nube desperdiciouse [ 2 ]. O gasto na nube foi de case 500.000 millóns de dólares en 2022; polo tanto, estamos a falar duns 150.000 millóns de dólares desperdiciados ao ano.
Non só isto é unha preocupación polos ingresos perdidos, senón tamén polas malas prácticas de sustentabilidade. 150.000 millóns de dólares de enerxía desperdiciada!
Estes descubrimentos implican tanto a grandes empresas como a outras máis pequenas, desde a madurez de nube alta ata a madurez de nube baixa. Refírese a AWS, pero os mesmos principios pódense aplicar a calquera outro provedor de nube. Entón, se algunha parte do teu traballo está na nube, este artigo é para ti.
Falo desde a perspectiva de enxeñeiro de datos, pero as mesmas aprendizaxes pódense aplicar a outras prácticas de enxeñería de software.
Mergullémonos.
Este tipo de factura na nube adoita restrinxirse a empresas moi grandes que operan a nivel mundial con millóns de clientes.
Para que che fagas unha idea, unha factura na nube de 1 millón de dólares pode resultar dun procesamento de traballo de Spark ETL ~ 1,5 Tb por hora 24x7 durante 365 días ao ano. Outro exemplo pode ser unha aplicación que recibe miles de millóns de solicitudes ao día desde varias localizacións do mundo.
Nunha empresa grande, hai centos de aplicacións deste tamaño, o que resulta en contratos de miles de millóns de dólares con provedores de nube. Por exemplo, Airbnb tiña o compromiso de gastar 1.200 millóns de dólares en recursos na nube durante cinco anos a finais de 2019 [3 ].
En Expedia reducimos os custos dun ETL de procesamento de datos que custaba 1,1 millóns de dólares ao ano a só 100.000 dólares ao ano mediante a implementación de prácticas de optimización. Iso é unha redución de custos do 91%!!
Non todas as empresas teñen aplicacións dun tamaño tan grande, pero imaxina reducir o custo da túa nube nun 90 % só para unha única aplicación ou para toda a túa empresa.
Vai e obtén unha lista das túas aplicacións máis caras e desafía as túas suposicións de deseño .
Todas estas preguntas remóntanse á pregunta máis importante: como se vai utilizar a aplicación? Cal é o valor empresarial para que exista? Como nos está a axudar a aplicación a acadar un obxectivo determinado?
Por suposto, todas estas respostas son moitas veces pouco claras ao comezo dun proxecto; pero é por iso que o deseño debe ser sempre un proceso iterativo, permitindo que os cambios se produzan coa maior fluidez posible. Os enxeñeiros deben aceptar a evolución e o cambio, aliñando o desenvolvemento de aplicacións co impacto.
O segundo paso consiste en proporcionar á aplicación os recursos axeitados e axustala á infraestrutura adecuada.
Como enxeñeiro, teña en conta como se calculan os custos da nube. Por exemplo, AWS ofrece instancias puntuales nas que podes poxar polo prezo do clúster; isto é especialmente útil se tes aplicacións flexibles e tolerantes a fallos. Utilízaos se pode - AWS reclama unha redución de custos de ata un 90 % [ 4 ].
Algunhas outras consideracións que pode querer abordar son:
Hai poucos ou ningún inconveniente ao utilizar instancias de AWS Graviton. AWS investiu moito na creación dos procesadores máis rendibles. Podes conseguir unha redución de ata un 40% no gasto na nube só cambiando dun procesador baseado en intel a un procesador baseado en ARM [ 10 ].
A única advertencia a isto é que a súa aplicación debe ser compatible cos procesadores baseados en ARM nos que se executa Graviton. Se estás a tratar cun servizo xestionado como RDS ou OpenSearch, non hai ningunha complicación ao cambiar: AWS ocúpase do SO subxacente e da compatibilidade das aplicacións. Se estás construíndo a túa propia aplicación, quizais necesites recompilar o paquete dependendo do idioma que esteas a usar: Java e outras linguaxes non requiren cambios, mentres que Python require certa atención.
Por último, non esquezas seguir supervisando os teus custos para detectar picos e sorpresas inesperadas. O custo do día 0 da túa aplicación será diferente do custo do día 170. Asegúrate de facer un seguimento dos cambios e de entender por que se está a producir o cambio: está a acumular os custos de almacenamento do s3 ou é só un único pico?
Configure as alertas e as guías operativas necesarias !
É importante que implemente etiquetas de asignación de custos para rastrexar o gasto por departamento, proxecto ou ambiente. Evite o risco de crear un pantano de datos onde o custo sexa imposible de rastrexar ou requira unha longa viaxe a través de diferentes sistemas de rexistro. Debe ser rápido e sinxelo volver a calquera custo da aplicación.
Onde queira que esteas a traballar, é difícil equilibrar a entrega de novas funcións coa optimización das actuais. Quen non foi presionado para ofrecer novas funcións peculiares á velocidade da luz.
Non obstante, é esencial que tanto os enxeñeiros como os xestores tomen decisións deliberadas e proactivas sobre os seus proxectos actuais, xestionando os riscos e as oportunidades de forma eficaz.