Z-Flow – a solução Zappts de Git Workflow

Integração contínua, flexibilidade e limpeza de histórico eficiente: conheça o Z-Flow e avance na produtividade com seu time de desenvolvimento!

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

O assunto de hoje aqui no blog é Git Worflow e eu vou te apresentar um pouco da solução Z-Flow, desenvolvida pela Zappts. Vamos nessa?

Bom, quando falamos sobre o trabalho em equipe de um time de desenvolvimento, não podemos deixar de citar o uso de uma ferramenta de versionamento. 

O nosso amigo git é provavelmente um dos primeiros sistemas de versionamento de código que todo desenvolvedor tem contato quando começa a trabalhar em time, e apesar do git ser poderosíssimo e muito útil, muito ainda se discute a respeito de como utilizá-lo. 

Portanto, se você tem essa dúvida, continue lendo este artigo que eu vou compartilhar com você algumas informações importantes sobre o assunto!

Git Workflow

Qual é a melhor forma de trabalhar com git? Como organizo as branches?

Desses questionamentos surgiram os workflows e é a partir deles que podemos encontrar as respostas que tanto procuramos. 

Um workflow é um framework para a organização de branches

O workflow dita como devem ser organizadas e nomeadas as branches e quais movimentações devem ser feitas até a entrega do produto final. 

Existem diversos modelos conhecidos e você provavelmente já deve ter esbarrado em algum deles. 

Mas, com tantos frameworks já disponíveis e conhecidos, por que criar um novo workflow?

Primeiro, é importante destacar que os modelos mais antigos não levam em consideração nosso cenário atual de integração e entrega contínua (aquelas palavras famosas: CI/CD). 

E os modelos mais novos, como o “Github Flow” ou o “Feature Branch Workflow?

De fato, eles realmente são ótimos para CI/CD (inclusive nos baseamos em alguns conceitos básicos do Github Flow). Porém, eles apresentam uma branch master e homolog (ou release em alguns projetos) muito poluídas, e às vezes, com dezenas ou centenas de milhares de commits, o que impossibilita qualquer expert de entender qual foi a sequência de entregas realizadas.

Essa enormidade de commits passam a não servir para nada (a não ser para confundir), além de tornar muito complexo o processo de rollback (para quem nunca passou por isso, nem queira saber como é ter que fazer git revert e revert de revert para conseguir colocar as coisas em ordem novamente).

Aqui na Zappts já nos deparamos muito com essa situação em projetos próprios e também de clientes. Por isso, pensamos em uma nova forma de organizar a forma de como entregar funcionalidade para produção.

Z-Flow – A solução Zappts de Git Workflow

Vamos lá: tudo o que fazemos quando trabalhamos em desenvolvimento de software está focado em entregas com qualidade, certo?

Com base nessa premissa, nós criamos um modelo de workflow que deixasse nossa branch de desenvolvimento com todos os commits feitos pelos desenvolvedores (eles são importantes ali), e nossa branch de produção com o histórico de entregas e não de commits de desenvolvimento, permitindo também a administração de deploys por entregas específicas e não de um todo.

Assim surgiu o Z-Flow!

O que preciso saber para extrair o máximo deste artigo?

Para que esteja na mesma página que nós e acompanhe as dores que passamos antes de decidirmos pensar no Z-Flow, seria importante que você conhecesse de:

  • Git: que já tenha trabalhado em algum projeto que usa git como sistema de versionamento de código. Se já passou pelas dores de gerenciar um git com muitos desenvolvedores, projeto grande, código que “sumiu do nada” da sua branch, melhor ainda.
  • GitFlow: parte da premissa que todas as feature branches partem de Dev. Ou seja, Dev precisa estar estável com todas as features que serão publicadas para homologação e posteriormente produção.
  • GithubFlow: parte da premissa que todas as feature branches partem de Master e que todas as feature branches podem ser mergeadas em master separadamente. Normalmente, em projetos maiores, existem branches intermediárias (todas provenientes da master), que recebem individualmente a feature branch.
  • Delivery Contínuo (CI/CD): usando os commits das branches como source para executar uma pipeline de publicação automática. Quando um commit é submetido (pushed) para uma branch, automaticamente um script é executado, que publica esse novo código para um determinado ambiente.

Atenção: se você trabalha com desenvolvimento de softwares, venha fazer parte do nosso time! Confira as vagas e mande seu currículo hoje mesmo! 😀

Apresentando o Z-Flow

Como dito anteriormente, se você implementar o Z-Flow no seu projeto, terá uma branch de produção MUITO limpa, constando apenas o histórico de entregas e seguindo a cronologia de entrega de cada feature, além de uma branch de desenvolvimento que tenha todos os históricos de commits feitos por todos desenvolvedores.

Branches principais

O Z-Flow possui quatro branches principais:

  • master
  • develop
  • qa
  • homolog

A master é a branch de produção e sempre representa uma versão estável do nosso software. 

Quanto à develop, é nessa branch que as novas features vão se acumulando e o time de desenvolvimento têm visão de quais features já foram implementadas por outros desenvolvedores. 

Por conta da branch de develop ser atualizada recorrentemente, é a branch mais suscetível a instabilidades. 

Agora, vamos apresentar duas novas branches que talvez você ainda não conheça: a qa e a homolog.

A branch de qa é dedicada ao time de qualidade. É nela que os testes por parte do time de qualidade são executados. 

A branch de qa é mais estável que a branch de develop, uma vez que os desenvolvedores devem garantir a estabilidade da sua feature antes de repassá-la para a fase de testes.

p.s: a branch qa é recomendada, mas não é obrigatória para que o Z-Flow funcione da forma como idealizamos. Se você tem um time ou projeto pequeno, talvez essa branch possa ser dispensada.

E por último, temos a branch de homolog, onde estão todas as features testadas pelo time de QA, mas que ainda precisam ser homologadas pelo time de negócio. Essa é a branch que entrega features para produção. 

Importante: em alguns casos específicos de projetos, é necessário incluir a branch Pré-Prod após homolog. Esse caso será tratado mais à frente.

Z-Flow – Transitando entre branches

Para que o desenvolvimento aconteça de maneira paralela e eficiente, usamos as branches secundárias. São elas:

  • feature branch
  • delivery branch

Lembrando que para cada feature desenvolvida teremos uma feature branch e uma delivery branch.

Para todas as transições entre branches, sejam elas principais ou secundárias, recomendamos que sejam seguidas as boas práticas de git, pelo menos usando ferramentas que suportam merge por Pull Request e designando usuários independentes para fazer code review a cada Pull Request.

Feature Branch

  • Deriva de: master
  • Recebe o conteúdo: dos comitts feitos pelos desenvolvedores da feature
  • Entrega seu conteúdo em: develop (–no–ff), qa (–no–ff)
  • Convenção: feature/*

A feature branch é onde o desenvolvedor vai incorporar as novas funcionalidades do sistema. 

Ela sempre deriva de master para garantir que estamos trabalhando em cima de uma versão estável de produção. 

Todas as implementações da feature devem ser feitas na feature branch, nunca diretamente na develop ou em alguma outra branch.

Uma vez que o desenvolvimento é finalizado, a feature deve ser entregue (mergeada) no modo no-fast-forward em develop para que o desenvolvedor possa fazer testes integrados a outras funcionalidades incorporadas pelos outros times. 

Após fazer todas as implementações e alterações na feature branch e garantir a estabilidade da feature em develop, o desenvolvedor pode mergear a feature branch como modo no-fast-forward na branch qa para iniciar a fase de testes. Portanto, o nosso fluxo fica assim:

  • git checkout master
  • git pull origin master
  • git checkout -b feature/minha-feature
  • **após implementar alterações (git commits):
  • git checkout develop
  • git pull origin develop
  • git merge –no-ff feature/minha-feature
  • git push origin develop
  • **quando a feature estiver pronta para fase de testes:
  • git checkout qa
  • git pull origin qa
  • git merge –no-ff feature/minha-feature
  • git push origin qa

Delivery branch

  • Deriva de: master
  • Recebe o conteúdo: da feature branch (–squash)
  • Entrega seu conteúdo em: homolog (–no-ff)
  • Convenção: delivery/*

Com o intuito de limpar o histórico de commits, a delivery branch serve para diminuir o histórico de commits de uma feature branch pronta para entrega. 

Entenda a delivery branch como sendo exatamente a feature branch, com o mínimo de commits possíveis, os commits referentes a cada “entrega” da feature.

Para chegarmos a esse objetivo, a delivery branch recebe a merge squash da sua feature branch equivalente após a aprovação da feature em QA.

Assim, a delivery branch fica com o mesmo conteúdo da feature branch (master + nova funcionalidade), mas apenas com um commit (o resultante do merge squash).

Segue o nosso fluxo:

  • git checkout master
  • git pull origin master
  • git checkout -b delivery/minha-feature
  • git merge –squash feature/minha-feature
  • git commit -m “delivery da feature minha-feature”

Homolog Branch

  • Deriva de: master
  • Recebe o conteúdo: da delivery branch (–no-ff)
  • Entrega seu conteúdo em: master (–no-ff)

A branch de homolog receberá todas as features que estão testadas e prontas para serem homologadas.

Para entregar o conteúdo de cada feature pronta a ser homologada para homolog, a delivery branch (referente à cada feature) será mergeada em homolog.

O merge aqui acontece no modo “no-ff” para que se crie um histórico de entrega da feature para homologação. Então, atenção: é a delivery branch que deve ser entregue para homologação.

p.s: a branch homolog fica apenas com os commits referentes a cada entrega de feature feita para homologação. Ao usar o Z-Flow, você tem na branch homolog um histórico limpo de todas as entregas de features para homologação!

  • git checkout homolog
  • git pull origin homolog
  • git merge –no-ff delivery/minha-feature
  • git push origin homolog

Master Branch

  • Recebe o conteúdo: da homolog (–no-ff)
  • Entrega seu conteúdo: para criação de novas feature branches e delivery branches

E quando as features são entregues na master?

Consideramos, para este flow, uma entrega para produção como sendo exatamente o que está homologado.

Dessa forma, quando chega o momento certo, a branch master precisa ser uma “cópia” da branch homolog.

Quando um conjunto de features está homologado , basta dar merge no modo “no-ff” de homolog para master para atualizá-la, tornando master  uma nova versão estável.

  • git checkout master
  • git pull origin master
  • git merge –no-ff homolog
  • git push origin master

Assim, podemos taggear a última versão estável cada vez que entregamos um conjunto de features.

p.s. 1: quando se fizer necessário ter uma branch “pré-prod”, siga os passos descritos aqui como ‘master’. Após pré-prod estar validado, siga novamente esses passos trocando “homolog” por “pré-prod”.


p.s 2: a branch master fica apenas com os commits referentes a cada entrega de feature feita para homologação. Ao usar o Z-Flow, você tem na branch master um histórico limpo de todas as entregas de features para homologação em conjunto de um histórico com todas as entregas feitas para produção.

Por que precisamos de uma delivery branch?

Mas, por que precisamos criar uma branch a mais se poderíamos simplesmente dar merge squash da feature diretamente em homolog?

Realmente, isso pode ser feito deixando o flow bem mais simples. Então, qual a razão da existência da delivery branch?

Nós da Zappts prezamos muito pelo code review e sempre é importante alguém aprovar o nosso código antes de submetermos para uma das branches principais.

Usando o merge squash, por conta da maneira que as ferramentas de code review usam git diff, fica bem difícil entender as diferenças entre um commit e outro.

Logo, o intuito de criar uma branch intermediária, somente para criar um merge squash (um commit único) da feature branch, é para não atrapalhar o code review entre as outras branches.

O processo fica um pouco mais trabalhoso, de fato, mas o esforço compensa: por um pequeno custo (5 comandos de git), se consegue um retorno enorme (imensurável em alguns projetos) de se ter uma branch homolog e master limpas, com poucos commits cronologicamente organizados na forma de entregas. 

Nós pagaríamos o dobro (ou mais) por esse resultado 🙂

Lidando com erros

Como tratar no Z-Flow quando nossa feature está com erros?

A regra é simples: erros encontrados localmente (feature) ou nas branches develop e qa são consertados na feature branch e entregues novamente em develop e qa.

Se o erro foi pego na branch homolog deve ser consertado na feature branch, replicado (squashed) para a delivery branch e entregue novamente em homolog.

Entende-se que a delivery branch vai ficar com alguns commits a mais (a primeira entrega e a segunda entrega com o erro corrigido). É exatamente o que se busca: um histórico limpo de entregas.

E quando encontramos um erro que já está em produção? Nesse caso, criamos uma branch específica para tratar o erro, chamada de hotfix

Hotfix Branch

  • Deriva de: master
  • Entrega o conteúdo em: delivery/hotfix (–squash) 
  • Convenção: hotfix/*

A branch de hotfix deve seguir o mesmo fluxo já apresentado na feature branch, mudando apenas a convenção de nomes. Nesse caso:

  • git checkout master
  • git pull origin master
  • git checkout -b hotfix/meu-hotfix
  • após implementar alterações (git commits):
  • git checkout develop
  • git pull origin develop
  • git merge –no-ff hotfix/meu-hotfix
  • git push origin develop
  • **após garantir estabilidade do hotfix:
  • git checkout qa
  • git pull origin qa
  • git merge –no-ff hotfix/meu-hotfix
  • git push origin qa

E da mesma forma que para uma feature branch existe uma delivery branch, para o hotfix também existe uma delivery hotfix branch.

Delivery Hotfix Branch

  • Deriva de: master
  • Recebe o conteúdo: da hotfix (–squash)
  • Entrega o conteúdo em: homolog (–no-ff)
  • Convenção: delivery/hotfix/*

E o fluxo também segue o mesmo de uma delivery branch, apenas alterando a convenção de nomes:

  • git checkout master
  • git pull origin master
  • git checkout -b delivery/hotfix/meu-hotfix
  • git merge –squash hotfix/meu-hotfix
  • git commit -m “delivery do hotfix meu-hotfix”
  • git push origin delivery/hotfix/meu-hotfix

Vale ressaltar que devido à urgência que o hotfix pode apresentar, é possível pular passos no Z-Flow e entregar diretamente um hotfix em qa ou criar diretamente uma delivery branch para entrega em homolog/master.

Integração Contínua e Deploy Contínuo

O Z-Flow garante integração contínua uma vez que as branches são incorporadas juntas em todas as branches principais.

Com o Z-Flow sempre se está testando features integradas umas às outras. Ao passar pela branch de qa, o Z-Flow garante que uma nova feature não quebra as demais já entregues em produção na branch master

Há casos que é necessário entregar features prontamente ou antes de um conjunto de funcionalidades. Nestes, alguns passos do Z-Flow podem ser pulados e a delivery  branch pode ser mergeada diretamente na master, uma vez que a delivery branch já deriva da master.

Isso garante que todas as delivery branches sempre contenham: master (ambiente de produção estável) + feature (nova funcionalidade).

Logo, o Z-Flow é um modelo flexível que permite tanto a entrega de um conjunto de features já integrados ou a divisão da entregas em pacotes separados. 

Branch de produção mais estável

Como a feature branch deve passar pelas branches de develop e qa (e é intensamente testada), dificilmente a branch de produção ficará instável.

Isso ocorre porque somente features que já contém master testadas e prontas são entregues em produção.

Ou seja, o cenário de master + nova implementação já é simulado e testado desde develop e qa.

Histórico mais limpo

Como a delivery delivery sempre é um squash de uma feature branch e ela é entregue em homolog e master, o Z-Flow garante que em branches finais o histórico de commits será muito mais limpo, considerando assim um histórico de entregas e não um histórico de desenvolvimento.

Utilizando as delivery branches, fica fácil entender a cronologia de entregas, uma vez que cada delivery branch geralmente é composta de dois commits (um commit da implementação e um commit do merge).

E já que você chegou até aqui com a gente, deve estar interessado em saber como o Z-Flow funciona na realidade, certo? Então, vamos lá!

Acompanhe na imagem abaixo um exemplo de como o histórico fica mais limpo e claro sobre as entregas nas branches homolog e master e como o histórico fica completo com todos os commits de desenvolvimento nas branches develop e qa, cumprindo os objetivos principais do Z-Flow.

Tem duas formas de analisar esta imagem:

1. Com foco nas branches: faça a análise apenas das branches, de cima para baixo, esquecendo as branches ao lado. Veja como fica o histórico de commits de uma única branch. Entenda o que aconteceu com a branch, evolutivamente. Lembre-se de olhar com uma visão de desenvolvedor para as branches de develop e qa e com a visão de negócio para as branches de homolog e master.

2. Com foco no fluxo: acompanhe o fluxo de merges. Quando o merge é do tipo no-ff, ele arrasta o histórico de commits da branch origem. Quando o merge é do tipo squash, ele resume todos os commits da branch em um único commit.

Conclusão

O Z-Flow é uma alternativa aos modelos de workflow. Ele traz flexibilidade e garante CI/CD ao mesmo tempo que limpa o histórico de commits, além de manter uma branch de produção estável.

E aí, pronto para colocar o Z-Flow no seu catálogo de workflows? Pronto para usar o Z-Flow no seu projeto ?

Se a sua empresa precisa de ajuda para estruturar processos de desenvolvimento, conte com a gente! Vamos acelerar seus resultados com soluções produtivas, como o Z-Flow. Fale agora mesmo com nossos especialistas 😀

E se você é desenvolvedor(a), olha só: que tal vir trabalhar na Zappts?

Aqui, você vai encontrar o MELHOR ambiente para desenvolver suas habilidades, expor ideias e aprender muita coisa legal.

Construímos um espaço incrível de trabalho e diversão, que respeita a diversidade e que dá condições para que todos possam deixar suas marca em nossa história!

Vem conferir as vagas, trabalhar e aprender com a gente 👉 https://zappts.com/trabalhe-conosco/

Até o próximo artigo 👋

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 e 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! 🙂