Escolha uma Página

Zappters Protagonistas – Episódio #5: O melhor da vida é aproveitar a vida.

Episódio #5: Thauany Moedano.

Bem-vind_ ao Zappters Protagonistas!

Nesta série você tem a oportunidade de conhecer a história dos talentos da Zappts, empresa “full remota” focada em projetos de transformação digital de grandes marcas.

Você perdeu nosso último episódio? Confira a história do Gabriel no Episódio #4: A única escolha que eu fiz foi ser eu mesmo

Quer conhecer nossas vagas? Então, clique aqui.


Nossa entrevistada da semana foi Thauany Moedano, Head de Back-end e Arquitetura da Zappts. 

Thau, para os mais íntimos, cresceu em Itaquera, São Paulo, mas afirma com muita convicção que não é corinthiana. 

Palmeirense de 25 anos, Thau mora há 7 anos em São José dos Campos, cidade onde fica a sede da Zappts.

“Lá atrás eu não sabia que iria estudar Ciência da Computação. Meus pais sempre falavam que Direito era muito legal, que eu ia me dar bem, então experimentei”. 

Ela chegou a fazer um curso técnico em serviços jurídicos e foi nesse momento que descobriu que essa área não era para ela.

“Nossa, eu detestei direito!”

Autointitulada “meio nerd”, Thau procurou por vários cursos de graduação que fizessem sentido para ela, até se apaixonar por Ciência da Computação. 

“Passei na Unifesp em São José dos Campos. Saí de Sampa com o coração apertado, mas certa de que tudo iria dar certo”.

Pouco antes disso, ainda no ensino médio, o avô de Thau sofreu um AVC. Sua preocupação em sair de São Paulo vem daí, pois sua mãe e avó ficaram responsáveis por cuidar dele.

“Lembro como se fosse ontem o sorrisão que o meu avô deu quando eu disse que havia passado no vestibular. Toda a família ficou emocionada.”

Como uma boa estudante recém chegada em uma nova cidade, Thau morou por alguns anos em uma república. 

“Foi uma época de muitas descobertas, principalmente acadêmicas. Fiz iniciação científica, fui representante discente, participei de congressos até tentei jogar futsal, mas falhei miseravelmente”.

Thau nos contou que sempre foi baladeira e que na faculdade aprendeu a jogar bilhar e truco.

“Gosto muito de música. O primeiro show que eu fui foi do Avenged Sevenfold, e o último do Gustavo Lima. Tudo a ver, né?!”.

“Como eu não tinha família em São José dos Campos, meus amigos da faculdade e do trabalho foram minha família por aqui”.

Durante a iniciação científica, Thau se desanimou com a área acadêmica e percebeu que aquilo não estava fazendo sentido para ela.

“Então eu fui buscar um estágio de verdade e consegui. Minha primeira chefe foi a Carla, que também trabalha na Zappts e é Head de Agile”.

Thau lembra até hoje que, durante o estágio, ganhou um bilhete da Carla com uma mensagem que agora leva para a vida inteira.


“Lembro que estava escrito algo do tipo ‘obrigada pela sua postura, nunca se sinta menos do que você é e nunca deixe ninguém te dizer isso’. Tenho o bilhete guardado até hoje”.

Tudo ia muito bem na vida de nossa protagonista até que, em meados de 2018, ela saiu da república e foi morar sozinha.

“Eu havia terminado um relacionamento de mais de 4 anos e muita gente que eu conhecia de São José estava se formando e saindo da cidade. Então me senti totalmente forever alone”. 

Para piorar, a empresa onde Thau trabalhava fez um corte de mais de 30 funcionários, fazendo com que muitas pessoas da sua equipe fossem embora.

“Foi bastante gente embora, pessoas que eu conversava desde o início e que faziam parte não só na minha vida profissional, mas pessoal também”.

Nesse momento, ela foi para um novo projeto dentro da empresa, onde precisava viajar praticamente toda semana.

“Eu ia na segunda-feira e só voltava na sexta. Me sentia ainda mais sozinha. Comecei a me sentir deprimida e logo busquei ajuda profissional de uma terapeuta”.

Thau nos contou que até hoje ela faz terapia, e que isso foi uma das melhores decisões que ela teve na vida: procurar ajuda.

Sem medo de ser feliz, e por orientação da terapeuta, Thau também recorreu à psiquiatria para tratar sua ansiedade.

“A ansiedade ficou tão grande em mim que eu fui buscar ajuda. Fui diagnosticada com TAG, transtorno de ansiedade generalizada”.

“Tava tudo bem com minha família, com o trabalho, mas dentro de mim eu estava bem mal. Aceitar e admitir essa condição foi a coisa mais importante que eu fiz”.

Ela nos contou ainda que sempre tentou adivinhar o futuro e que isso não ajudava muito.

“Eu sempre tentei pensar no que poderia acontecer, e isso gerou ansiedade em mim. Procurar ajuda não me fez louca, mas sim humana por reconhecer minhas limitações”.

Sem dúvida, o bem-estar é uma das coisas mais importantes na vida de uma pessoa, e priorizar a própria saúde é fundamental para ter uma vida com harmonia.

“Antes do tratamento eu sentia que eu não me priorizava. Pouco importava minha saúde mental”.

No meio de toda essa história, no final de 2019, a ex-chefe Carla já estava na Zappts e contou para Thau o que ela estava perdendo em não fazer parte do time. 

“A Carla me disse que eu tinha que trabalhar na Zappts. Então mandei meu currículo e fiz minha entrevista com o Rodrigo em um shopping.”

A vaga era para programação em javascript, node em nuvem, tecnologias com as quais nossa protagonista nunca havia trabalhado anteriormente. 

“Era tudo muito diferente para mim, mas eu topei dar essa virada de 180 graus na minha vida. Foi a melhor decisão”.

Na época, a empresa contava com apenas 25 Zappters, e Thau reencontrou não apenas Carla, mas outros amigos com quem já havia trabalhado antes, como Luciano.

“Na Zappts eu descobri que nuvem era a minha paixão. Nunca gostei muito de programação, mas sempre curti arquitetar e propor soluções para problemas. Então com ajuda da Zappts eu tirei minha primeira certificação em arquitetura de nuvem”.

Thau nos contou que durante a pandemia ela decidiu não morar mais sozinha, e passou a dividir uma casa com mais 3 amigos. 

“Isso foi essencial para mim, pois não me sentia mais tão sozinha e podia dividir minhas dores e felicidades com esses amigos que se tornaram mais do que irmãos pra mim”.

Pois bem,  eis que nossa protagonista “conheceu um carinha” que iria mudar por completo sua vida.

“Eu conheci ele no Tinder, igual a música. Conversamos umas 3 vezes até que saímos para jogar bilhar. O pessoal que morava comigo apareceu no bar e ficou zoando o cara. Pensei que ele nunca mais iria falar comigo”.

Com o tempo, os dois foram parando de se falar. Passaram-se meses e Thau conheceu um novo pretendente. Sim, também no Tinder.

“Sai com esse novo carinha, e adivinha quem estava no bar onde fui conhecê-lo? Sim, o primeiro rapazinho”.

Thau disse um “oi, tudo bem?” e naquele momento percebeu que havia feito besteira em não seguir conversando com o primeiro pretendente.

“No dia seguinte eu mandei um ‘oi, sumido’ pra ele. Voltamos a sair e com o tempo começamos a namorar”.

Hoje, eles moram juntos e recentemente adotaram uma cachorrinha, batizada com o nome de Haru. 

“Animais sempre foram muito presentes na minha vida. Meu avô já teve galinha de angola, ganso, coelho, hamster, porquinho da índia e peixes. Hoje na casa dos meus pais há 8 gatos e 4 cachorros”.

Thau já fez muitos amigos “nas internets”. Na adolescência ela jogava ‘Neopets” e teve até um blog para falar do tema.

“Uma vez, nas férias, fui até o Rio de Janeiro conhecer o pessoal que também jogava Neopets, foi louco. Também já fui pra BH pra conhecer outro pessoal”. 

Nossa protagonista também é pianista, e até deu uma palinha no piano durante o último happy hour da Zappts.

“Sempre adorei filmes musicais, tipo La La Land. Já fiz aula de canto mas percebi que aquilo não era pra mim. Daí tinha um teclado jogado aqui em casa há muitos anos, então decidi aprender”.

Ela começou então a fazer aulas de piano toda semana e ganhou de presente dos amigos um piano digital. Sim, isso que são amigos!

“Foi uma válvula de escape pra mim, ainda mais na pandemia. Não podendo sair de casa, sem poder tomar cerveja e comer torresmo nos bares de São José, encontrei no piano uma paixão”.

Além do piano, Thau também gosta de futebol americano, jogos como magic e xadrez, e ainda tem uma coleção de moedas comemorativas das Olimpíadas do Rio.

“Além disso, eu também amo karaoke. Uma vez até cantei ‘eu dormi na praça’ com um grupo de japoneses”. 

Thau tem diversos sonhos para depois da pandemia, como comprar um terreno e construir sua própria casa.

“Também tenho muita vontade de voltar a viajar. Meu sonho é conhecer as 7 maravilhas do mundo, começando pelas ruínas de Petra”

A Zappts se orgulha demais por ter talentos tão comprometidos e profissionais como a Thau.

Você perdeu nosso 4º episódio? Confira a história do Gabriel no Episódio #4: A única escolha que eu fiz foi ser eu mesmo.

Confira nossas novas vagas, clicando aqui.

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