Serviços serverless para diminuir seu custo!

Olá! Seja bem-vindo ao VEEZOR Podcast.

Um espaço totalmente dedicado a discutir sobre as principais tecnologias em computação em nuvem, segurança, banco de dados e inteligência artificial, gestão de identidade e tantos outros temas, que serão discutidos aqui.

Quer entender como essas e outras tecnologias em cloud podem revolucionar o seu negócio?

Entre em contato pelo site veezor.com

Esse conteúdo conta com o apoio da AWS, Amazon Web Services.

Eu sou Vinicius Perrott. Seja bem-vindo ao VEEZOR Podcast!

Vinícius Perrott: Se você não sabe o que que é, fique ligado. Nesse episódio também, eu vou contar com a participação de dois arquitetos de soluções em Cloud. Paulo, seja muito bem-vindo.

Paulo Fagiani: Prazer Perrott.

Perrott: Giam, seja muito bem-vindo.

Giampaolo Carmagnani: Obrigado, Perrott.

Perrott: Legal. Maravilha, vamos lá. Pessoal, não podemos nunca deixar de falar de redução de custos, em ambiente em nuvem. Obviamente, não é enxugar para usar menos. É usar, com consciência. Mas, falamos no episódio anterior, sobre serverless, para o que que serve, como funciona. E como é que a gente agora, pode entender melhor essa tecnologia, com foco no custo.

Giam: Perfeito. É importante perceber que o serverless é um conceito já antigo. Ele é recente na sua palavra. Então, a palavra serverless, ela se tornou um busword recente. Mas, há 10 anos, 20 anos, tem muita gente que já usa serverless e não sabe. E um dos primeiros serviços que a Amazon lançou, é um serviço serverless, desde a sua concepção, que é o SQS, que é o envio de filas. E um serviço muito conhecido, que talvez todos que usam a Amazon naturalmente usem, é o S3. O S3 é um serviço de storage, onde você paga pela utilização e transações. Então naturalmente sim, você vai pagar pelo que está guardado lá dentro, mensalmente, por giga, por tera. Mas, a cobrança do S3, se dá por transação. Eu escrevo eu pago, eu leio eu pago, eu recebo eu pago. Então, eu apago eu pago. Então, você tem as transações, você não paga por um servidor que está ligado o tempo todo. Você não tem o custo fixo nisso, né? Naturalmente, o custo fixo acaba sendo para os gigas ou teras que estão guardados ali, que não existe como fugir disso. Mas, você não está pagando pelo servidor que está guardando, mas, pelo gigabyte guardado ali dentro. E nisso, você tem uma série de tears, né? Então, você tem as camadas que você pode fazer. Se o seu dado, ele é usado frequentemente, você tem uma faixa de preço. Se seu dado é usado menos frequentemente, você já tem uma outra faixa de preço, que é de te dar uma condição de pagar menos, né, e ele vai mudar isso lá dentro, sem que você saiba em que servidor isso está. E existe tears tão baratos, com tear, que ele vai guardar a informação que você mandou em uma fita, que é basicamente isso. Ele vai pegar aquela informação, botar em uma fita, e jogar no robô, e vai jogar isso no container, em algum lugar físico. A gente falou do container no episódio anterior, mas é basicamente isso. E aí, você não vai ter acesso a informação imediatamente. Na hora que você precisa de acesso, você vai ter ali uma quantidade de horas mínimas, sei lá, 6 horas, 2 horas, 3 horas, para que alguém vá lá buscar aquela fita, recuperar a informação para você, e você receba ela. E por isso, vai pagar ainda muito menos. Eu não sei em que servidor isso está. Então, já é um serviço serverless por natureza, desde a sua concepção. E assim como esse, a gente tem serviços na área de computação recentes, que é o que se liga mais ao serverless, que é para funções serverless. Nós temos também na área de integração, que é onde você vai ter o SES, SQS, SNS. E você vai ter também na área de armazenamento de dados, que a gente já citou o S3. Mas, você vai ter um banco de dados totalmente serverless, por exemplo, que é um banco de dados do SQL, ou não apenas o SQL. E aí você vai ter uma série de outros bancos de dados. Por exemplo, o My SQL hoje, pode ser usado o serverless dele da Amazon, onde você controla basicamente a capacidade de transações que você vai ter de CPU, memória que você gostaria de ter, você trabalha com essas unidades. Ele escala isso menos de milissegundos, ele consegue subir e descer isso para você.

Perrott: Entendendo, esse conjunto de serviços Jean, que eu posso trazer para dentro da minha arquitetura, dentro do meu ambiente, é interessante que a gente possa estudar item a item, tecnologia a tecnologia, e descobrir as suas características, e seu potencial. E sim, incorporar, e ter o objetivo principal, que é ter eficiência, mas, com o menor custo possível.

Giam: Exatamente. A ideia é você pegar aquele pedaço da sua aplicação, do seu workload, que de repente você não use tanto, e faça sentido você migrar para uma estrutura serverless. Com isso, você otimiza seu custo, que é o que a gente está querendo. E atualmente existem frameworks, serverless, que ajudam você a migrar sua aplicação para usar esses serviços serverless. Fica muito mais fácil você provisionar aquele serviço, na verdade, faz só uma chamada, porque diferente do servidor, que você tem que ir lá, subir servidor, aplicar path, criar endereço de rede. E fazer uma chamada, e cria o serviço para você, e você conecta naquele serviço, já está funcionando. Ficou muito mais simples.

Perrott: Como você mesmo falou. Eu acho que é interessante a gente reforçar aqui nesse episódio. Se eu tenho um framework, que ele dá já um direcional e um norte específico, segui-lo minimamente, já traz resultados positivos para dentro do seu ambiente. Então, fica como uma dica aqui importante, é entender como o serviço funciona, e também entender como o framework, ele indica essas conexões, esse ambiente todo que você citou. Faz sentido isso?

Giam: Isso, exatamente. Ele, além de facilitar, né, ele vai lhe mostrar a melhor maneira de fazer aquilo, né? De repente, ele mostrar que aquilo que você achava que não estava legal no serverless, vai ficar legal no serverless. Você pode rodar seu código no container, que a gente já falou também, de forma serverless.

Perrott: Sim.

Giam: Ou seja, a mobilidade do container é tão grande, que ele também pode estar no serverless hoje em dia.

Perrott: Uma coisa que a gente também já comentou aqui, em todo o nosso episódio, em toda a nossa minissérie, é uma questão de uma arquitetura sempre ser revalidada, re-checada. Porque pode se parecer que uma vez que eu montei a minha arquitetura da minha aplicação, eu não vou mexer mais nela. Mas, a gente já citou. Novas tecnologias surgem, novos padrões, e até mesmo novas metodologias surgem, e otimizar essa minha infraestrutura. Uma vez que eu já estou utilizando um conceito de serverless, será que isso não vai me atrapalhar na minha arquitetura de ter que refazer tudo de novo, ter que reconfigurar tudo? Ou não, já estou algo muito mais preparado, a me moldar a novas tendências, novos produtos e serviços que vão surgindo em nuvem?

Jean: Eu acho que é uma tendência de você fazer essas alterações. Cada vez menos, você precisa mudar. Então, hoje por exemplo, S3 foi uma coisa que pegou tão bem, que a maioria dos provedores de nuvem, de data center, hoje tem uma cópia do S3 para fazer sotorage de objetos.

Perrott: Sim.

Giam: Então, se você tiver em qualquer outro provedor de mercado, eles têm o que eles chamam de uma cópia do S3, que você pode usar e mudar apenas o endereço. Ao invés de usar o S3, você usa o S4, S5, o nome que eles querem dar lá.

Perrott: Qualquer nome.

Giam: Então, a maioria… vira uma tendência. E aí você tem nesse, eu vou dar um exemplo nessas 3 categorias, né? Então, você pode hoje rodar um container com firegate. O firegate, é basicamente você não sabe o que que está ali por trás. E ele vai rodar por hora, você vai ser cobrado por minuto, por segundo. E aí você pode rodar um firegate, somente por 5 minutos, depois parar. E você só vai ser cobrado por aqueles 5 minutos. Mas, você tem um container. Do mesmo jeito que a sua aplicação rodaria em uma máquina C2 ali, com container dentro, com firegate você roda, pelo período que você precisar. Pode ser um lote, pode ser… inclusive, você pode ficar pelo resto da vida, se você quiser. Ele vai te cobrar, pelas horas de utilização dentro daquele mês. Mas, você pode por exemplo usar, por execução, dentro do lambda. E aí, o que que acontece? Vamos supor que você tenha hoje uma aplicação, que ela, é um serviço web, seja uma API, por exemplo. Então, você fez essa API, e você tem um servidor web na sua arquitetura atual. Seria um Apache, né? E aí, você tem a aplicação. Ou seja, em PHP, em Rubi, ou em Phyton. Em qualquer linguagem que for. E aquele framework daquela linguagem. E aí, é que tem o end port. Vamos dizer que o barra API ali é sua uni ponte, e ele vai devolver uma informação. Então, eu posso substituir o Apache, por exemplo, por um API gateway, que ele vai me cobrar por requisição naquele end point, né, no barra API, que eu coloquei. E ele chama uma função lambda que está rodando no próprio container que eu tinha feito antes, que é o mesmo, não mudou nada. E aí ele sobe aquele container, executa aquela função, e volta. Então, a ideia de funções lambda, não quer dizer que eu tenho que fazer uma função para cada coisa. Eu posso fazer um container que tem 3 mil funções ali dentro, e eu vou mapeando essas funções a partir de um API gateway, que vai dizer, olha, no mesmo container, eu tenho 3 mil funções. A diferença é o que você chamar aqui, você mapeia, e manda para cá. Então, eu posso aproveitar muita coisa tradicional, e jogar para serverless, né? Da mesma forma que você pode fazer isso para a parte de banco de dados, você pode usar para My SQL, só mudar a maneira de consumir. Ao invés de consumir um RDS hoje, onde você tem um tamanho de servidor X large, double X large, você vai dizer, não, eu quero provisionar o mínimo de meia CPU. Meia VCPU aqui. E eu quero que vocês escalem indefinidamente enquanto precisar, e só me cobre o que eu utilizar, né? Então, isso dá para fazer com banco de dados, isso dá para fazer com storage, isso dá para fazer, por exemplo, se eu tenho um servidor que só manda e-mail. E aí, eu percebi que eu mando 10 e-mails por hora. E aí eu estou ligando o servidor o tempo todo ali, para usar um SMTP para enviar e-mail. E aí eu descobri que eu pago por isso, uns U$ 20 dólares por mês. E aí eu posso fazer o SES, que apenas com uma modificação simples. E ele também usa SMTP, ele usa tudo. Só vamos mudar o endereço daquilo ali, e ele vai me cobrar por e-mail enviado, 0,001 centavo. Então de U$ 20 dólares, que é um número pequeno para isso, que foi passado a gastar menos de 1 centavo de dólar pó mês.

Perrott: É uma dízima periódica.

Giam: Então, nesse sentido, você dizer, economizar U$ 20 dólares, talvez não vale a pena. Mas, de U$ 20 dólares, para menos de 1 centavo. Se você for comparar U$ 20 dólares com menos de 1 centavo, é incomparável. Quem não quer economizar isso, com uma mudança de código que vai mudar apenas o nome do lugar que você ia. Você vai desligar um servidor, e vai usar a partir de então, um serviço gerenciado que te cobra por cada e-mail enviado, 0,0001 centavo.

Paulo: Além disso, você está tirando o custo da manutenção daquele servidor.

Perrott: Boa Jean. Boa.

Giam: Se você tem um vírus no seu servidor, se o sistema operacional aparece um security issue, e você tem que atualizar aquilo. E nesse caso, um servidor serverless, como SES da Amazon, por exemplo, quem tem que corrigir o bug, é a Amazon. Você não tem que fazer nada disso. Você nem sabe que ele corrigiu o bug. O seu e-mail continua sendo enviado, da mesma forma. Você só mudou foi o endereço. Ao invés de mandar pelo SMTP da sua máquina virtual, você está mandando para o SMTP da SES. A mudança durou 5 minutos, e ela ganhou um… Você pagou 20 vezes menos, no mínimo, ou 200 vezes menos, no caso, centavos. Imagina que esse custo não fosse U@ 20 dólares, fosse U@ 2 mil dólares. E você passasse a poder a pagar U$ 20dolares por mês. Quem é que não quer ter essa economia, com mudanças muito pequenas. Então, as pessoas se assuntam achando que são mudanças tremendas, quando, na verdade, as vezes são mudanças triviais, que demoram minutos. E contar com um parceiro nessa hora, pode ajudar você a acelerar essa mentalidade.

Perrott: São excelentes insights que você compartilhou aqui. E uma coisa que eu entendi nesse conceito, primeiro, não somente a economia financeira do consumo do serviço direto em nuvem, mas também, a economia financeira/operacional, do time que vai estar cuidando, e vai estar justamente suportando aquele ambiente. Porque eu deixo de ter mais horas investidas em manter uma infraestrutura que, em tese, não está gerando nenhum benefício ali direto para a minha solução. Eu tenho que manter, porque é um pré-requisito, né? E como reage qualquer framework de segurança, por favo, mantenha. Faça o checklist, tudo mais. Mas, se eu vou para um serviço, eu consigo consumir um serviço, e minha arquiteturas da minha aplicação, ela depende menos da minha operação, eu posso me dedicar ao meu especialista, a fazer outras interações, compartilhar o conhecimento com a consultoria especializada, que entenda aquilo ali, e dar foco no negócio. Esse tipo de benefício de economia, é direcionada a, acho que todos os gestores que estão aqui acompanhando, vendo esse episódio, ouvindo, é o que deseja. Primeiro, ter know-how de especialistas com consultoria, e também trazer esse tipo de benefício direto. Isso tudo, faz sentido, isso tudo é serverless?

Paulo: Isso tudo é serverless, e faz totalmente sentido normalmente. Porque você deixa de ter aquela pessoa reocupada em manter a sua infraestrutura, em vez dela estar fazendo isso, ela vai estar preocupada no negócio. Que é isso que interessa para a empresa, não é isso? 

Perrott: Exato, exatamente. E assim, eu fiquei impressionado com esse conceito de diminuir um custo, com um serviço que já foi explicado, que vocês explicaram superbem aqui. Já existe o serviço, está disponível. E as vezes a mudança não é recompilar o código todo, ou jogar tudo fora, né? Tem uma frase que é bem assim, não jogue a água do banho, com o bebe dentro. Tipo, não refaça toda a sua aplicação, porque você quer mudar alguma coisa. O serverless, é um bom caminho. É isso, dá para a gente implementar os times que estão aqui acompanhando. Tenho certeza que vai estar olhando com muito mais carinho, e absorver que serverless, é algo que dá para fazer parte do cotidiano do time técnico, dos gestores, e trazer benefícios. Isso é verdade.

Paulo: Sim. E uma máxima que existe no desenvolvimento, que é assim, a melhor forma de apagar um bug, é apagando o código. Então, se tem um código de 10 mil linhas, e eu consigo deixar ele mil linhas, eu deixei ele 9 mil linhas menos propício a ter bugs, porque eu apaguei. Seja lá o que pudesse existir nessas 9 mil linhas, eu tirei a capacidade de bugs acontecerem em 9 mil linhas. E agora eu reduzi em 1/10 da minha capacidade de ter bugs. E nesse caso do serverless, muitas vezes, é a mesma coisa. Então, eu diminuo a minha capacidade de ter problemas, porque eu tenho menos coisas gerenciadas. Então, eu, tem alguém gerenciando para mim o meu servidor de e-mail, não sou mais eu. Então, eu diminuí a minha capacidade de ter problemas em X% daquilo que eu teria ali. Então, faz muito sentido, muitas vezes, você mudar para o serverless, pela gestão. Eu já não tenho que gerir aquilo. Eu estou pagando uma equipe para gerir. E aí, estou pagando micro centavos por cada transação. Então, às vezes, esse custo aí, ainda que ele empate com você ter uma estancia ligada o tempo todo, eu ia facilmente para o serverless, porque é o que eu não vou precisar fazer. Muitas vezes as ofertas, elas são parciais. Isso aqui é muito mais barato, isso aqui… Mas, ele não te fala dos outros custos agregados que estão ao redor. E o serverless, ele te traz a tranquilidade de que, se é um banco de dados, tem um DBA lá cuidando daquilo para você. Se é um sistema de storage, tem um engenheiro de software, tem um engenheiro de sistemas, tem um cara que cuida do HD, tem um cara que cuida de tudo para você, que você não está… você está pagando no centavo da transação. E se tiver um problema de corromper o dado, quem tem que resolver, não é você. Ele vai te entregar a resolução do problema. Ele vai fazer nesse sistema de corresponsabilidade, em que a sua responsabilidade seja menor, e a dele maior. Isso é muito bom, porque eu estou terceirizando a responsabilidade de algo que requer uma especialização gigante, e que as vezes, eu preciso contratar profissionais escassos no mercado. E a Amazon, com a sua capacidade de tamanho, ela consegue ter pessoas extremamente mais especializadas, fazendo o mesmo papel. E você pode economizar muito, não somente com o serviço. Mas, em não precisar da especialidade de casa. E aí com isso, você pega esse orçamento, e pega os seus profissionais, para fazer algo muito mais relevante para o seu negócio. 

Perrott: Eu queria pegar um último gancho aqui com o Jean. Jean, beleza, eu quero implementar serverless. Eu vou levar 1 ano e meio para implementar esse negócio? Ou é mais ágil?

Giam: Não, geralmente é muito mais ágil. Dependendo do que for necessário, por exemplo, mudar um servidor de e-mail, muda 1 linha. Muda para um servidor My SQL serverless, é outra mudança de stream. Ou seja, ela tem um código Phyton rodando, você pode jogar aquele código Phyton no Lambda. Ele já vai rodar. Se o container já está rodando, joga no firegate, você já está serverless. Talvez, muitas pessoas estejam no serverless, e não saiba.

Paulo: Falta só o impulso.

Perrott: Exato. E só para fechar aqui. Serverless, para pequena, média, ou grande empresa? Qual o tamanho de empresa certa, para usar essa tecnologia?

Giam: Todas.

Perrott: Olha aí, bacana. Legal. Pessoal, eu queria agradecer muito a participação. Paulo, muito obrigado pelos insights, e por todo o conhecimento compartilhado aqui na nossa minissérie.

Paulo: Obrigado você, Perrot.

Perrott: Legal, até a próxima. Jean, muito obrigado aqui por compartilhar os insights, toda sua experiência, e os cases aqui na nossa minissérie. E até a próxima.

Giam: Muito obrigado você.

Perrott: Legal. E você que vem nos acompanhando em toda a nossa minissérie, aqui no Veezor PodCast, bem, não deixe de compartilhar. Se você achava que serverless era somente um serviço, você descobriu que realmente é muito mais do que um serviço. É um serviço que vai te ajudar a economizar, não somente em custos, mas, a parte operacional. Se você acha que está muito atribulado, de ações, e está fazendo vários checklists, de repente, o serverless pode ser a sua solução para desenvolver um trabalho com muito mais consciência, qualidade operacional. Deixe seu comentário, um like sempre vai bem, e até o próximo episódio.

Recomento a leitura do artigo: Análise de mídia sociais impulsionada por inteligência artificial

Podcast: Tocar em nova janela | Download

Subscribe: RSS

Tagueado como: VEEZOR Podcast.