Por David Linthicum
O Cloud FinOps, uma prática que combina gestão financeira e operações na cloud, é fundamental para otimizar os custos da cloud e garantir uma utilização eficiente dos recursos. É uma das mais importantes tendências emergentes na computação em cloud.
Os seus benefícios vão para além do controlo de custos. Vamos explorar a forma como o FinOps da cloud também pode ajudar a destacar as más práticas de arquitetura da cloud que conduzem a más implementações. Ao analisar os dados da cloud e os padrões de custos, as equipas de FinOps podem identificar áreas de preocupação e o que precisa de ser corrigido. Podemos aproveitar isto para o bem das implementações na cloud? Temos algumas coisas a considerar.
Análise e otimização de custos
As equipas de Cloud FinOps têm acesso a dados detalhados sobre os custos da cloud. Isto permite-lhes analisar os padrões de despesa e identificar más práticas de arquitetura da cloud que contribuem para uma sub-otimização desnecessária e para o desperdício de dinheiro.
Os erros incluem o aprovisionamento excessivo de recursos, a falta de automatização, a contentorização ineficaz ou a utilização inadequada de instâncias reservadas. Em muitos casos, as más decisões foram tomadas no passado e levarão muitos anos a corrigir; de facto, podem já ter causado danos irreparáveis à empresa.
Os sistemas de observabilidade FinOps podem analisar os dados de custos e identificar recursos ou serviços específicos que aumentam os custos. Isto conduz normalmente a potenciais melhorias arquitetónicas e a poupanças de custos significativos.
Avaliação do desempenho e da escalabilidade
As equipas de FinOps na cloud podem avaliar o desempenho e a escalabilidade da infraestrutura da cloud. A monitorização dos principais indicadores de desempenho, como os tempos de resposta, a latência e o débito, pode identificar estrangulamentos ou áreas em que a arquitetura atual limita a escalabilidade e o desempenho.
Uma vez que as FinOps normalmente acompanham este aspeto através do dinheiro gasto, é fácil determinar exatamente quanto é que os erros de arquitetura estão a custar à empresa. Não é invulgar descobrir que um sistema implementado na cloud custa 10 vezes mais por mês do que deveria. Estes números são chocantes para a maioria das empresas. Lembre-se, todo este dinheiro poderia ter sido gasto noutras áreas, como a inovação.
Alguns sistemas FinOps podem calcular as perdas líquidas resultantes destes erros de arquitetura. Em muitos casos, é até possível ver a redução líquida do valor do negócio.
Um exemplo: utilizar um único fornecedor de cloud pública sem considerar outros que possam ter melhores soluções, como uma base de dados que possa ser executada cinco vezes mais rapidamente, proporcionando um melhor desempenho e poupanças para as cerca de 50 aplicações que a utilizam. Uma base de dados melhor teria custado um terço do custo, proporcionado cinco vezes mais desempenho e poupado 15 milhões de dólares por ano em ganhos de produtividade. Pior ainda. Esses 15 milhões de dólares poderiam ter sido utilizados para desenvolver uma nova linha de produtos, que a empresa poderia ter transformado em 100 milhões de dólares em receitas. Este pode parecer um exemplo extremo, mas já vi coisas como esta virem à tona após uma análise da arquitetura da cloud, oportunidades perdidas, ineficiências, etc. É mais comum do que muitos imaginam.
Controlo de danos
OK, agora a questão com que a maioria dos profissionais da cloud não quer lidar: e se a sua arquitetura de cloud tiver algumas ineficiências importantes?
Suspeito que a maioria das implementações na cloud tem algum grau de ineficiência, por isso não é o único. É bom aceitar os danos para poder afetar custos à resolução dos problemas. Sugiro que divida cada problema em domínios que possam ser tratados separadamente e que os trate por ordem de prioridade, do mais dispendioso para o menos dispendioso. Terá de travar muitas batalhas para ganhar a guerra.
A maior parte delas serão coisas como bases de dados mal concebidas, tecnologia incorreta, má implementação da cloud e planeamento das operações na cloud: coisas de natureza tática e que, embora não sejam fáceis de resolver, são fáceis de entender como solucionar.
No entanto, há erros mais estratégicos, como a utilização de um único fornecedor de serviços na cloud. Talvez na altura tenha parecido uma boa ideia. Talvez um fornecedor tivesse uma relação com vários membros da direção ou houvesse razões políticas para as escolhas limitadas. Infelizmente, a empresa ainda acaba com uma grande dívida técnica que poderia ter sido evitada.
Note-se que o FinOps não é perfeito. É bom a encontrar áreas para melhores otimizações, mas os bons arquitetos de cloud ainda precisam de identificar a origem dessas más práticas de arquitetura. Por outras palavras, o FinOps é bom na deteção de problemas, mas ainda não identifica os problemas e a forma de os resolver.
