Escolha uma Página

Desvendando FINOPS

Descubra como otimizar o orçamento de TI reduzindo custos da Nuvem

Por Luciano Osorio – Scrum Master da Zappts

FinOps é um modelo operacional para a Nuvem que possibilita a retomada do controle financeiro sobre a infraestrutura de TI, para que os departamentos operacional e financeiro trabalhem juntos e com os mesmos objetivos.

FINOPS – Vantagens e Desafios da Nuvem

Vamos começar falando das vantagens da Nuvem.

Ela traz muita flexibilidade, é extremamente elástica quando é preciso aumentar ou diminuir a sua utilização.

Na Nuvem, é possível fazer diversos tipos de processamento e atividades diferentes dentro de um único ambiente, com a facilidade de um clique para contratar cada um desses serviços.

No entanto, a Nuvem traz algumas situações que precisam ser observadas e endereçadas, e eu vou explicar melhor sobre esses desafios a partir de agora.

Desafios da Nuvem

Tradicionalmente, o departamento de TI era responsável por definir quais os servidores seriam comprados, o armazenamento disponível e o poder de processo estaria disponível. Tudo isso era definido com antecedência dentro do planejamento financeiro anual da empresa.

Porém, com o advento da Nuvem algumas coisas mudaram e o programador passou a ter o poder de decisão sobre os recursos que precisa utilizar para poder fazer a inovação na qual está trabalhando.

Com isso, surge um problema: o departamento financeiro deixa de ter visão do que está sendo gasto com TI e isso pode trazer um problema de controle muito grande para a empresa.

A falta de controle de custos com TI pode gerar rombos enormes nos orçamentos, quando, por exemplo, a empresa possui uma aplicação que tem recursos e clientes, mas que custa muito mais caro se comparada ao retorno financeiro obtido com ela. 

Como evitar essa falta de controle?

Para evitar essa falta de controle de custos, um consórcio formado por grandes utilizadores da Nuvem propôs um modelo operacional que, quando aplicado, possibilita a retomada do controle financeiro sobre a infraestrutura estabelecendo uma linguagem comum entre os departamentos financeiro e de TI.

Assim foi criado o FinOps com o objetivo de:

  • Estabelecer o controle do que está sendo utilizado com recursos de TI;
  • Revelar quanto dinheiro está sendo gasto em infraestrutura;
  • Indicar quais departamentos e aplicações mais consomem os recursos e o orçamento de TI.

A partir da leitura desses indicadores, a empresa consegue provisionar adequadamente o budget para fazer as compras necessárias e limitar a infraestrutura daqueles pedaços da empresa que usam pouco a Nuvem.

A ideia do FinOps é simples: juntar as áreas de tecnologia e finanças para que ambas falem a mesma língua e estejam alinhadas nos mesmos objetivos.

As fases do FINOPS

O FinOps foi estruturado em três fases.

A primeira fase é a fase de informação, que vai dar visibilidade de quais são áreas da empresas que estão gastando mais, como esse dinheiro está sendo investido, quais recursos são de fato utilizados e quais podem ser trocados.

A área de informação vai gerar essa visibilidade para a área de negócios, o que possibilita uma tomada de decisão informada a respeito do que está acontecendo na Nuvem.

A segunda fase é a de otimização. 

Com base nas informações que foram coletadas, chega o momento de propor maneiras de otimizar o custo do serviço, de acordo com as finalidades para as quais a Nuvem está sendo utilizada.  

Após o processo de otimização, tem início a terceira fase do FinOps: a operação. 

Aqui, serão formalizados os custos dentro do planejamento financeiro da empresa, gerando budgets e reserva de dinheiro para a compra dos recursos de Nuvem que são necessários, com relatórios customizados que vão trazer informações do quanto está sendo utilizado de cada um dos serviços de Nuvem contratados. 

Quem está utilizando esses serviços? Quais são as aplicações que utilizam esses serviços? Quanto do serviço está sendo utilizado fisicamente?

Questões que podemos solucionar com assertividade a partir da utilização do FinOps como modelo operacional para a Nuvem.

Reduzindo custos da Nuvem com FINOPS

A partir de agora, você vai conhecer as ações estratégicas do modelo FinOps para reduzir custos da Nuvem, começando pelo tagging

FINOPS – Fase 1 – Informação

O tagging funciona da seguinte maneira: você vai dizer para cada um dos microsserviços que estão rodando na Nuvem qual é o departamento, aplicação e a área da empresa que está fazendo a utilização do serviço.

É possível utilizar diferentes combinações de informações para fazer o tagging, e quando ele estiver pronto, é preciso rodá-lo durante um tempo para capturar dados de consumo da Nuvem atribuídos a cada uma das grandes áreas dentro da empresa ou das aplicações que estão sendo utilizadas. 

Isso ajuda a segregar o custo e a direcioná-lo, bem como a fazer uma alocação de custo correta, a partir da identificação de quais áreas da empresa estão gastando mais do orçamento. 

Na sequência, vem a medição do quanto está sendo utilizado de cada um dos serviços. 

Neste ponto, existem duas situações possíveis: contratar um serviço e utilizá-lo por uma fração do tempo que ele estiver disponível ou contratar um serviço e gerar uma instância do mesmo, que ficará ativa por um tempo considerável e será utilizada pontualmente. 

Após algumas semanas fazendo essa medição, é possível gerar informação e prever o quanto será utilizado de um determinado recurso ao longo do tempo, o que vai ajudar muito na fase de operação, quando será estimado o orçamento.

Ainda na fase de informação, os reports serão fundamentais para levar toda informação coletada em diferentes formatos para os diferentes públicos: técnico, financeiro, gestão. 

Assim, é estruturada a cadeia de informação necessária para poder operar o FinOps.

FINOPS – Fase 2 – Otimização

É na fase de otimização que se trabalha toda a informação sobre os recursos da Nuvem que estão sendo utilizados, começando por considerar aqueles que estão acima ou abaixo do que a empresa realmente precisa: ou seja, os recursos super e subprovisionados. 

Os serviços em desuso podem ser removidos do plano de Nuvem, o que ajuda a reduzir o custo. 

Outra estratégia é trabalhar com a automação, utilizando robôs para o levantamento e derrubada dos serviços menos utilizados. Dessa forma, dá pra fazer o trigger dos serviços mais robustos quando for necessário.

Tendo a previsão do quanto será utilizado de cada serviço da Nuvem, é possível fazer a compra de instâncias reservadas com até três anos de antecedência, que pode custar até 43% mais barato do que uma instância sob demanda. 

Além de todas essas ações, o right sizing será um grande diferencial para o dimensionamento adequado do serviço para cada tipo de aplicação utilizada, assim como a comparação de preços, levando em consideração serviços semelhantes com custos diferentes. 

Está gostando do artigo? Aproveite e baixe o ebook com o passo a passo para a implementação do FINOPS. Conteúdo exclusivo e gratuito!

FINOPS – Fase 3 – Operação

Na fase de operação “levamos o negócio para dentro da Nuvem”, por meio de uma visão de negócio de longo prazo. Eu explico.

Nesse ponto do FinOps, traçamos objetivos de crescimento, melhorias na performance e definimos as quantidades de acessos no futuro.

Com os orçamentos definidos, é necessário fazer o alinhamento do custo da Nuvem com os objetivos para chegar a conclusão sobre o quanto já foi atingido e qual o ritmo de investimento adequado para alcançá-los totalmente. 

É imprescindível ter governança nessa fase, por meio de relatórios periódicos do consumo do budget que foi reservado para a Nuvem, indicando o crescimento de uso da aplicação e o retorno que isso tá trazendo para o negócio.

Importante: aumentar o custo da Nuvem não significa, necessariamente, a existência de um problema. 

Vamos pensar na utilização de um serviço online, por exemplo, o Uber. 

Quando foi lançado, o Uber tinha pouca densidade de utilização. Com o tempo, o negócio foi ganhando escalabilidade, muitas pessoas começaram a consumir o serviço, e portanto, muitos mais recursos da Nuvem foram necessários para suprir a demanda.

Ou seja, o aumento do custo da Nuvem, em si, não é necessariamente um problema, porém, é preciso ter algum tipo de indicador que mostre o custo da Nuvem por usuário e esse valor tem que ser constante ou um valor que caia ao longo do tempo, a menos que se esteja implementando uma nova tecnologia ou funcionalidade, que apresentará oscilação no custo.

E concluindo a fase de operação, as melhorias devem ser constantes, considerando tudo o que mencionei até aqui, como por exemplo, melhorias na maneira como as aplicações estão sendo construídas e no tagging.

Aplicações que não estão sendo tagueadas, deixam de gerar visibilidade de como o custo está sendo consumido. Assim, uma “fatia” do custo da Nuvem deixa de ficar clara para a tomada de decisão e departamentos envolvidos (TI e financeiro).

Então, é muito importante acompanhar periodicamente os diversos indicadores que serão criados no momento de visibilidade e investir em melhorias da performance desses indicadores. 

FINOPS – Case Nubank 

O Nubank, fundado em 2013, é o maior banco digital independente do mundo, com mais de 20 milhões de clientes em todo o Brasil.

Quando iniciou a jornada de FinOps, não tinha visibilidade alguma do quanto estava gastando na Nuvem, com uma tendência de explodir os custos de nos próximos meses de utilização. Então, o Nubank adotou uma estratégia.

Primeiro, o banco passou pela fase de visibilidade e estabeleceu um indicador muito importante: o de custo da Nuvem por cliente. 

Esse índice considera uma massa de clientes para dividir o custo da Nuvem.

Dessa forma, o Nubank conseguiu monitorar, ao longo do tempo, como o custo da Nuvem estava crescendo para cada “x” quantidade de clientes que eles obtinham a mais, e também, conseguiram ter uma visibilidade  de qual seria a tendência para os próximos meses.

Objetivo: o Nubank estabeleceu uma estratégia de tagging muito agressiva para que nos próximos três meses após aplicar a estratégia, atingissem, no máximo, 10% das aplicações sem tagging, e isso era cobrado fortemente de todas as equipes. 

Naquele tempo, o Nubank tinha aproximadamente 90 serviços online, 50 squads trabalhando com a criação e a atualização de serviços. 

Os custos estavam crescendo de uma maneira descontrolada, e sem visibilidade, o banco não tinha uma estratégia definida, com uma demora extremamente grande entre um deploy de uma parte nova da aplicação e o outro. 

Três anos depois de aplicar a estratégia de FinOps, o Nubank manteve e até conseguiu reduzir o custo da Nuvem por cliente, mesmo com o aumento da quantidade de serviços ativos para mais de 250, com mais de 50 squads em operação.

Como resultado, o Nubank passou a trabalhar com custos da Nuvem previsíveis, por meio de uma visibilidade muito boa de como o banco vai crescer os serviços da Nuvem utilizados, seguindo como principais estratégias do modelo FinOps o tagging, a compra de instâncias reservadas e o right sizing

Assim, o Nubank se tornou um case de FinOps bem aplicado, chegando a fazer mais de 50 deploys de correções ou novas funcionalidades por dia de uma maneira praticamente instantânea, sem dores e sem ter saldos consideráveis no custo da Nuvem. 

Conclusão

Este artigo tem o objetivo de apresentar o conceito de FinOps, o modelo operacional para a Nuvem que possibilita a retomada do controle financeiro sobre a infraestrutura de TI. 

O controle dos recursos utilizados e a identificação dos departamentos que mais consomem os serviços da Nuvem são diferenciais estratégicos, voltados para a redução de custos em um cenário de trabalho conjunto entre TI e financeiro.

Se você ficou com alguma dúvida ou se precisa de ajuda para a implementação do FinOps na sua empresa, entre em contato clicando aqui!

E antes de me despedir, vou deixar um vídeo com mais informações sobre gestão de custos da Nuvem e FinOps. Abraço e até o próximo artigo!  👋👋👋

https://www.youtube.com/watch?v=mJjeDENeqTE&t=1133s

Desvendando o Serverless – Cloud Computing

O que você sabe sobre Serverless? Vem comigo que eu te conto tudo!

Por Thauany Moedano – Cloud Architect e Back-End Software Developer da Zappts

Serverless Cloud Computing

Neste artigo, eu vou te contar um pouco do surgimento do Serverless e como aplicá-lo da melhor forma. 

Antigamente, o modelo mais comum de arquitetura eram os monolitos. Em um monolito, todos os componentes da sua aplicação estão unidos em um único módulo.

Embora o deploy de uma aplicação monolítica seja muito simples e seja fácil evoluir os componentes como um todo, o monolito apresenta um único ponto de falha. Isso quer dizer que se qualquer falha ocorrer em sua aplicação, todo o sistema falha.

E assim surgiram os microsserviços!

Os microsserviços surgiram com o objetivo de quebrar a aplicação em várias partes pequenas e independentes. 

Então, se um componente falhar, tudo bem: nossa aplicação não cairá por completo, mas o custo de uma aplicação distribuída e resiliente se torna um problema conforme a aplicação escala. 

Quantas máquinas e quantos contêineres vou precisar gerenciar? 

E a nuvem veio

Com o advento da nuvem, hoje é possível fazer deploy de aplicações inteiras sem ser o dono de um único data center

Aplicações distribuídas se tornaram muito mais simples de se manter. Os principais benefícios de usar um provedor em nuvem são:

  • Pagar somente o que usar: quando seu sistema escala, é possível provisionar mais máquinas para atender a demanda. Quando as máquinas não são mais necessárias, basta deletá-las. Você só é cobrado pelo tempo de uso.
  • Não há necessidade de estimar a capacidade final da aplicação: com a nuvem, é possível escalar o ambiente à medida que a demanda cresce. Em outras palavras, não é necessário se preocupar se o setup atual atende à demanda, pois sempre é possível provisionar novos recursos.
  • Simplicidade na criação de recursos: e a melhor parte desses benefícios é que tudo pode ser feito com poucos cliques!

É por isso que muitos estão migrando suas aplicações para a nuvem.

Isso impulsionou a popularidade da Arquitetura de Microsserviços, mas a disseminação dessa arquitetura levou as equipes de desenvolvimento a um novo desafio: orquestrar e gerenciar uma infraestrutura distribuída, dividida em contêineres, pode ser tão complexo quanto se queira

Esses novos desafios podem acarretar em deploys longos e aumentar o custo operacional. 

Mas, e se não precisássemos nos preocupar com manutenção e gerenciamento de servidores? E se o desenvolvimento fosse completamente focado na criação da aplicação ao invés da infraestrutura? 

E assim nasceu o Serverless!

Serverless, que na tradução livre significa “ Sem Servidor “, é um modelo em nuvem onde a equipe de desenvolvimento não gerencia os servidores. 

O objetivo principal do conceito de Serverless é que sua equipe foque mais no desenvolvimento da aplicação do que na infraestrutura.

Mas, calma: como uma aplicação pode existir sem servidor?

O servidor está lá, mas é totalmente gerenciado pelo provedor de nuvem. 

Ao invés de pagar pelo provisionamento de recursos, o Serverless cobra somente o consumo computacional da sua aplicação, conforme ela é executada.

E como funciona o desenvolvimento pensando Serverless?

A aplicação é desenvolvida em um modelo de execução conhecido como Function As a Service (FaaS). 

Nesse modelo, pequenas funções são escritas e associadas a eventos. Quando um evento ocorre, a função é executada. 

Esses eventos podem, por exemplo, ser uma chamada de API, uma postagem em uma fila, um upload de uma imagem ou um registro de usuário e o custo é somente no consumo computacional da função quando é executada. 

Já entendemos que Serverless significa não se preocupar com infraestrutura. Mas quais outras vantagens esse modelo em nuvem pode nos trazer?

Vantagens do Serverless

E para entender mais sobre esse modelo, nada melhor que conhecer suas principais vantagens de usar a arquitetura Serverless, que são:

  •  Lançamento de uma aplicação com pouco custo e em tempo rápido: o timing de um negócio é extremamente importante para o sucesso do mesmo. Com Serverless, é possível lançar rapidamente no mercado aplicações funcionais com pouco gasto de recursos.
  • Menor complexidade: as aplicações costumam ser menos complexas, pois é o provedor cloud que gerencia a infraestrutura.
  • Alta disponibilidade: como todo o servidor é gerenciado pelo provedor de nuvem, a aplicação é altamente disponível sem um custo extra por isso.
  • Fácil integração com CI/CD: a computação “sem servidor” torna muito mais simples o deploy e a atualização da sua aplicação

Então, Serverless é nossa bala de prata?

Embora Serverless traga muitos benefícios, nem todo modelo de negócio se adequa à sua utilização. 

Existem cenários que precisamos ter, em algum nível, controle sobre a infraestrutura. Além disso, existem outros fatores que podem comprometer a opção por Serverless. São eles:

  • As funções tem um tempo pequeno para timeout (em torno de 15 minutos). Logo, aplicações com workloads grandes e contínuos não são indicadas para serem escritas em Serverless.
  • As soluções Serverless ainda são bem distintas entre os provedores de nuvem. Isso significa que se sua aplicação precisa ser mais independente de um provedor o possível, Serverless não é recomendado.
  • Troubleshooting pode ser complicado uma vez que não é possível reproduzir fielmente um ambiente Serverless localmente.

serverless sem servidor

Qual o preço de Serverless?

Muito se fala no custo operacional de uma aplicação Serverless, e na maioria dos casos, as aplicações sem servidor realmente apresentam custos menores do que aplicações tradicionais. 

Isso acontece porque em Serverless você paga pelo consumo do recurso em si e não pelo provisionamento da infraestrutura.

Entretanto, é importante sempre calcularmos o preço do consumo do recurso. 

Aplicações com uma demanda muito grande de utilização e com uma intensidade grande de requests por segundo podem se tornar mais caras utilizando Serverless do que provisionando máquinas virtuais para hospedar a aplicação. Veja alguns exemplos:

Serverless – Cenário 1: Sistema escolar

Considere um sistema escolar em que os alunos podem se matricular nas matérias e no fim do período consultar suas notas. 

Existem dois períodos de grande movimentação no site: o começo das aulas e o fim das aulas. 

Vamos imaginar a seguinte situação: o dono desse sistema escolheu como provedor de nuvem a AWS: ele optou por provisionar instâncias virtuais (também conhecidas como EC2).  Por sua vez, o arquiteto escolheu para a solução uma máquina do tipo m4.large, que é a indicada para a maioria das aplicações em produção (essa máquina gera por mês um custo aproximado de $ 72 dólares). 

Durante o período de matrícula (2 meses do ano) e o período de notas finais (2 meses do ano), o tráfego aumenta e é necessário provisionar uma máquina extra.

Em um ano, o custo total dessa aplicação seria de $ 1152 dólares, mas o arquiteto analisou que esse sistema ficará no ar por bastante tempo e fez a reserva de uma instância para um ano. 

Com apenas uma máquina rodando sob demanda por 4 meses, o custo diminuiu para $ 789 dólares. Considerável, mas ainda parece alto.

Se movermos a solução para uma aplicação Serverless, utilizando os serviços AWS Lambda e API Gateway, qual seria nossa economia? 

Suponha que durante no período em que a demanda é baixa aconteça por volta de 5 mil requisições por dia. Em oito meses de baixa demanda, seria gerada em torno de 1.200.000 requisições. 

Agora, considere que nos meses de matrícula e notas finais, o número de requisições salta para 100 mil por dia. Em quatro meses, teria acontecido em torno de 12 a 13 milhões de requisições. A soma total nos traz em torno de 14 milhões de requisições no ano. Isso não custaria mais do que $ 55 dólares. 

Impressionante, não? Mas calma, vamos ver um cenário em que Serverless poderia sair muito caro.

Serverless – Cenário 2: E-commerce

Para simplificar, vamos supor que um e-commerce esteja calculando o custo de uma operação especial de natal. 

Para atender a demanda, o arquiteto sugeriu provisionar cinco máquinas m4.large. Isso custaria para esse mês especial um total de $ 360 dólares.

Qual o custo usando as mesmas tecnologias Serverless do cenário anterior? 

Bem, com a correria de fim de ano, o site estará bem movimentado, gerando pelo menos 50 requisições por segundo. Apenas o custo do serviço de API Gateway geraria no mínimo um custo de $ 451 dólares. 

E vale lembrar que também estamos desconsiderando o custo do banco de dados, que em um banco de dados Serverless pode ter um custo por conexão mais elevado.

Isso nos mostra que Serverless não é indicado em cenários de grande carga de requisições, já que o custo de provisionar uma máquina será menor que o custo do consumo dos recursos.

Sobre custos da nuvem, aproveito para falar em FinOps, um modelo operacional que trabalha o gerenciamento eficiente de finanças, tornando mais assertivo o cálculo de gastos futuros em plataformas cloud como a AWS, Azure e Google Cloud. Baixe agora o ebook e saiba mais!

Como aplicar Serverless da melhor forma?

O ideal em uma arquitetura em nuvem é sempre aproveitar o melhor que cada modelo de negócio pode nos oferecer. 

Uma aplicação não precisa ser 100% Serverless se esse modelo não atender a todos os requisitos do seu produto.

Isso significa que Serverless pode ser um recurso estrategicamente inteligente quando utilizado em pontos chave da sua aplicação.  

Dessa forma, os melhores cenários para usar Serverless são:

  • Eventos stateless (para pequenas tarefas na sua aplicação) e assíncronos (cujo padrão de execução não pode ser previsto);
  • Pequenos processamentos/transformação de dados, desde que sejam concluídos em um curto espaço de tempo;
  • Aplicações Web simples, como portais e gerenciamento de conteúdo;
  • Backend de aplicações mobile cujo acesso é esporádico;
  • Gerenciamento de notificações , sistema de mensagens e chatbots.

E agora, pronto para usar Serverless?

Serverless deve ser visto como uma nova opção no catálogo de soluções ao desenvolver uma arquitetura em nuvem. 

Sempre em algum grau, é possível implementar conceitos de Serverless em sua aplicação, desde a criação de pequenos eventos para alterar o tamanho de uma imagem, até a criação de uma aplicação inteiramente sem servidor.

Aqui, contei um pouco da história do Serverless e dei alguns exemplos de como esse modelo da Cloud Computing pode ser útil para tocar processos mais simples e ágeis. 

Continue acompanhando os conteúdos do nosso blog. Temos artigos sobre UX, Scrum e muitos outros assuntos da área de tecnologia. 

Espero que tenha gostado desta publicação e até a próxima! 🙂