Certamente, você já se perguntou quanto custa a infraestrutura do seu projeto. É surpreendente: o aumento das despesas não é linear em relação às cargas. Muitos proprietários de negócios, CTOs e desenvolvedores, de forma inconsciente, percebem que estão pagando demais. Mas pelo quê exatamente?
Normalmente, a redução de custos se resume a encontrar a solução mais barata, a tarifa da AWS ou, se falamos sobre racks físicos, a otimização da configuração do hardware. Além disso, na prática, isso é tratado por qualquer um, como a sorte permitir: se estamos falando de uma startup, provavelmente é o desenvolvedor líder, que já está lidando com muitas responsabilidades. Em empresas maiores, isso é tratado pelo CMO/CTO, e, às vezes, até o diretor-geral se envolve pessoalmente com o chefe de contabilidade. No geral, essas são as mesmas pessoas que já têm muitas preocupações "especializadas". Assim, as contas de infraestrutura aumentam, mas quem realmente lida com isso... são aqueles que não têm tempo para se aprofundar na questão.
Se for preciso comprar papel higiênico para o escritório, isso é responsabilidade do responsável pela manutenção ou da pessoa encarregada da empresa de limpeza. Se falamos de desenvolvimento — são os leads e o CTO. Vendas — também é tudo claro. Mas desde os tempos antigos, quando chamávamos de "servidor" o armário que abrigava um sistema torre comum com um pouco mais de memória RAM e alguns discos em RAID, todos (ou, pelo menos, muitos) ignoram o fato de que as compras de recursos deveriam ser gerenciadas por alguém especificamente treinado para isso.
Infelizmente, a memória histórica e a experiência indicam que essa tarefa foi delegada por décadas a pessoas "casuais": quem estivesse mais próximo, era quem assumia a responsabilidade. E apenas recentemente, o mercado começou a formar e reconhecer a profissão de FinOps. Essa é a pessoa especificamente treinada cuja função é controlar a compra e o uso de recursos. E, em última análise, reduzir os custos da empresa nesse sentido.
Nós não recomendamos abrir mão de soluções caras e eficazes: cada negócio deve decidir por si mesmo o que precisa para uma existência confortável em termos de hardware e tarifas de nuvem. No entanto, não podemos ignorar o fato de que a compra imprudente "por lista" sem controle e análise posterior de uso resulta em perdas significativas para muitas empresas devido à gestão ineficaz dos "ativos" de seu back-end.
Quem é FinOps
Suponhamos que você tenha uma empresa sólida, da qual os vendedores falam com admiração como "enterprise". Provavelmente, você comprou uma dúzia ou mais de servidores, AWS e outras coisas "menores" de forma "por lista". O que faz sentido: em uma grande empresa, sempre há algum movimento acontecendo — algumas equipes crescem, outras se desfazem, e outras são transferidas para projetos vizinhos. E assim, a combinação desses movimentos junto com o mecanismo de compras "por lista" acaba levando a alguns fios grisalhos ao revisar a fatura mensal da infraestrutura.
Então, o que fazer — continuar a ficar grisalho pacientemente, cobrir ou investigar as razões por trás desses numerosos zeros horríveis na fatura?
O que pode ser oculto: a aprovação, consentimento e o próprio pagamento do pedido dentro da empresa para a mesma tarifa da AWS nem sempre (na verdade — quase nunca) é rápido. E justamente devido ao constante movimento corporativo, parte dessas aquisições pode se "perder" em algum lugar. E simplesmente ficar paradas. Se um administrador atento notar um servidor abandonado em sua sala de servidores, no caso das tarifas de nuvem, a situação é muito pior. Eles podem ficar "aninhados" por meses — pagos, mas ao mesmo tempo já não necessários para o departamento ao qual foram adquiridos. Enquanto isso, colegas do escritório ao lado começam a arrancar seus cabelos ainda não grisalhos — eles não conseguem que uma tarifa AWS similar, urgentemente necessária, seja paga há semanas.
Qual é a solução mais óbvia? Certo, passar as rédeas para quem precisa, e todos ficam satisfeitos. Mas as comunicações horizontais nem sempre estão bem estruturadas. E o segundo departamento pode simplesmente não saber sobre a riqueza do primeiro, que, por sua vez, não parece precisar muito dessa riqueza.
Quem é o culpado? — Na verdade, ninguém. Assim é como tudo está organizado até agora.
Quem sofre com isso? — Todos, toda a empresa.
Quem pode corrigir a situação? — Sim, FinOps.
FinOps não é apenas uma camada entre desenvolvedores e o equipamento de que precisam, mas uma pessoa ou uma equipe que sabe onde, o que e quão bem estão dispostos em termos das tarifas de nuvem adquiridas pela empresa. De fato, essas pessoas devem trabalhar em conjunto com o DevOps de um lado e o departamento financeiro do outro, exercendo o papel de intermediário eficaz e, o mais importante, analista.
Um pouco sobre otimização
Nuvens. Relativamente baratas e muito convenientes. Mas essa solução deixa de ser econômica quando o número de servidores se torna de dois ou três dígitos. Além disso, as nuvens oferecem a oportunidade de utilizar cada vez mais serviços que antes estavam indisponíveis: como bancos de dados como serviço (Amazon AWS, Azure Database), aplicações serverless (AWS Lambda, Azure Functions) e muitos outros. Todos eles são incríveis por serem simples de usar — comprou e levou, sem problemas. Só que quanto mais uma empresa e seus projetos se aprofundam nas nuvens, pior o diretor financeiro dorme. E mais rápido o CEO fica grisalho.
O fato é que as faturas de vários serviços em nuvem são sempre extremamente confusas: você pode receber uma descrição de três páginas sobre uma única linha, explicando para onde, como e por que seu dinheiro foi gasto. Isso, claro, é agradável, mas é praticamente impossível compreendê-las. E nossa opinião sobre isso não é a única: para traduzir faturas de nuvem para um formato compreensível, existem serviços inteiros, como ou . Se alguém se preocupou em criar um serviço separado para decifrar faturas, então a escala do problema superou o custo da tinta para cabelo.
Então, o que o FinOps faz nessa situação:
- tem uma compreensão clara de quando e em quais volumes as soluções em nuvem foram adquiridas.
- sabe como esses recursos estão sendo utilizados.
- redistribui-os de acordo com as necessidades de cada departamento.
- não compra "só para ter".
- e, no final, economiza seu dinheiro.
Um ótimo exemplo é o armazenamento em nuvem de uma cópia fria do banco de dados. Você, por exemplo, a arquiva para reduzir o consumo de espaço e tráfego durante a atualização do armazenamento? Sim, à primeira vista, pode parecer uma situação trivial — em um caso específico, mas a soma de tais situações triviais acaba resultando em custos excessivos com serviços em nuvem.
Ou outra situação: você adquiriu recursos extras na AWS ou Azure, para não ficar sobrecarregado durante picos de demanda. Pode-se ter certeza de que esta é a solução ideal? Afinal, se instâncias ficam paradas 80% do tempo, você está apenas jogando dinheiro fora para a Amazon. Além disso, para esses casos, a AWS e a Azure oferecem instâncias burstable — por que ter servidores ociosos, se você pode usar uma ferramenta para resolver problemas de cargas de pico? Ou, em vez de instâncias On Premise, seria melhor considerar as Reserved — elas são muito mais baratas e ainda oferecem descontos.
A propósito, sobre descontos
Como mencionamos no início, as compras muitas vezes são feitas por quem quer que esteja disponível — alguém foi designado, e depois ele se vira sozinho. Na maioria das vezes, esse 'designado' é alguém já bastante ocupado, e acabamos com a situação em que a pessoa decide rapidamente e de maneira qualificada o que e em que quantidades comprar, mas de forma totalmente autônoma.
E ao interagir com um vendedor do serviço em nuvem, é possível obter condições mais vantajosas, especialmente quando se fala em compras em atacado de recursos. É claro que não se consegue tais descontos de um sistema em uma transação silenciosa e unilateral — mas conversando com um gerente de vendas real, pode-se conseguir algo. Ou esses vendedores podem sugerir em que produtos estão oferecendo descontos. Isso também pode ser útil.
Por outro lado, é importante lembrar que a AWS ou Azure não são as únicas opções disponíveis. Claro, não estamos falando de montar um servidor próprio — mas há alternativas a estas duas soluções clássicas dos gigantes.
Por exemplo, o Google ofereceu às empresas a plataforma Firebase, na qual é possível hospedar um projeto móvel sob demanda, que pode exigir rápida escalabilidade. Armazenamento, banco de dados em tempo real, hospedagem e sincronização de dados na nuvem estão disponíveis em um único lugar com essa solução.
Por outro lado, se não estamos falando de um projeto monolítico, mas de um conjunto deles, a solução centralizada nem sempre é vantajosa. Se o projeto é de longa duração, tem sua própria história de desenvolvimento e uma quantidade correspondente de dados que precisam ser armazenados, é melhor considerar uma alocação mais fragmentada.
Ao otimizar os gastos com serviços em nuvem, você pode perceber repentinamente que, para aplicativos críticos para os negócios, pode ser mais sensato adquirir planos mais robustos que garantam uma operação ininterrupta da empresa. No entanto, guardar o legado do desenvolvimento, arquivos antigos, bancos de dados e outros em nuvens caras não é a melhor solução. Afinal, para esses dados, um centro de dados padrão com HDDs comuns e hardware médio sem qualquer 'extra' pode ser suficiente.
Aqui, novamente, pode-se pensar que 'todo esse trabalho não vale a pena', mas toda a problemática desta publicação se baseia no fato de que, em várias etapas, as pessoas responsáveis negligenciam detalhes e fazem o mais conveniente e rápido. O que, no final, leva a faturas assustadoras após alguns anos.
Qual é o resultado?
De fato, as nuvens são ótimas, resolvem um monte de problemas para empresas de qualquer tamanho. No entanto, a novidade desse fenômeno leva ao fato de que ainda não temos uma cultura de consumo e gerenciamento. FinOps é uma alavanca organizacional que ajuda a utilizar as capacidades em nuvem de forma mais eficiente. O principal é não transformar esse cargo em uma espécie de pelotão de execução, cuja missão é pegar desenvolvedores distraídos em falta e 'repreendê-los' por recursos ociosos.
Os desenvolvedores devem desenvolver, e não contar o dinheiro da empresa. E o FinOps deve tornar tanto o processo de compra quanto o processo de descarte ou transferência de recursos em nuvem para outras equipes eventos simples e agradáveis para todos os envolvidos.
Fonte: habr.com
