Uma breve introdução a Serverless
Estou pretendo publicar alguns posts para falar sobre os meus estudos e práticas sobre a arquitetura Serverless no desenvolvimento de aplicativos.
Nesse post, veremos:
- O que é Serverless
- Por que utilizar
- Vantagens e desvantagens
- Alguns provedores serverless
- AWS Serverless
- Conclusão
O que é Serverless?
Primeiramente, o termo “sem servidor” (serverless) é confuso, pois com tais aplicativos desenvolvidos com essa arquitetura há hardware de servidor e processos de servidor em execução em algum lugar, mas a diferença em comparação com as abordagens “normais” é que a equipe que cria e oferece suporte a um aplicativo serverless não está cuidando desse hardware ou desses processos . Eles estão terceirizando essa responsabilidade para outra pessoa, no caso, o fornecedor do serviço.
As arquiteturas sem servidor são designs de aplicativos que incorporam serviços de “Backend as a Service” (BaaS) de terceiros e/ou que incluem código personalizado executado em containers efêmeros gerenciados em uma plataforma de “Functions as a Service” (FaaS). Ao usar essas idéias, e outras relacionadas, como aplicativos SPA (single-page applications), essas arquiteturas eliminam grande parte da necessidade de um componente de servidor sempre ativo tradicional. As arquiteturas serverless podem se beneficiar de custos operacionais, complexidade e lead time de engenharia significativamente reduzidos, a um custo de maior confiança nas dependências do fornecedor e serviços de suporte comparativamente imaturos.
Os primeiros usos do termo parecem ter surgido por volta de 2012, incluindo neste artigo de Ken Fromm.
O termo se tornou mais popular em 2015, após o lançamento do AWS Lambda em 2014, e cresceu ainda mais em popularidade depois que o API Gateway da Amazon foi lançado em julho de 2015. Aqui está um exemplo em que Ant Stanley escreve sobre Serverless após o anúncio do API Gateway. Em outubro de 2015, houve uma palestra na conferência re:Invent da Amazon intitulada “The Serverless Company using AWS Lambda”, referindo-se ao PlayOn! Sports. No final de 2015, o projeto de código aberto ‘Javascript Amazon Web Services (JAWS)’ foi renomeado para Serverless Framework , continuando a tendência.
Em meados de 2016, Serverless havia se tornado um nome dominante, dando lugar ao nascimento da série Serverless Conference, e vários fornecedores de Serverless adotando o termo em tudo, desde marketing de produto até descrições de cargos. Serverless como um termo veio para ficar.
Por que utilizar?
A arquitetura severless permite que você crie softwares com maior agilidade e com um menor custo.
A criação de aplicativos serverless significa que os desenvolvedores podem se concentrar no desenvolvimento do produto, sem se preocupar com o gerenciamento e a operação de servidores nem tempos de execução, seja na nuvem ou no ambiente local. Essa sobrecarga de conhecimentos e orquestração reduzida permite que os desenvolvedores recuperem o tempo e a energia que podem ser gastos no desenvolvimento de excelentes produtos com escala e confiáveis.
Além disso, como mencionado anteriormente, você delega a responsabilidade de hardware para o fornecedor do serviço, eliminando as tarefas de gerenciamento de infraestrutura, como provisionamento de servidores ou de clusters, patches, manutenção do sistema operacional e provisionamento de capacidade.
Sendo assim, você não terá que se preocupar com assuntos do tipo:
- Quantas instâncias do meu aplicativo preciso ter?
- Devo “criar” ou “destruir” uma instância quando?
- Será que já devo configurar um load balancer?
- Como esta o consumo de CPU e demais das minhas instâncias?
- Aprender Terraform ou outro para provisionar suas instâncias
- Etc
Vantagens
Custo operacional reduzido e produtividade
Devido serverless “delegar” a responsabilidade de orquestração para o fornecedor, você consegue ter reduções de custos tanto em questão de RH sem a necessidade imediata de contratar algum recurso com conhecimentos de servidores e afins.
Como os desenvolvedores não precisam se preocupar com todas as questões de hardware, eles conseguem se focar no desenvolvimento do produto, assim podendo realizar entregas mais rápidas e eficientes.
Tecnologias
Com serverless você tem a possibilidade de utilizar diversas linguagens de programação no seu aplicativo de uma forma muito simples. Como a orquestração é realizada pelo provedor, toda a questão de instalação das tecnologias, configurações e etc são da responsabilidade dele. Consequentemente você pode utilizar a linguagem para cada parte do seu aplicativo desde que o provedor tenha suporte para a mesma.
Flexibilidade
Como existe a possibilidade de utilizar diversas tecnologias no mesmo aplicativo de uma forma muito simples, isso te permite construir seu aplicativo serverless de forma gradual caso queira migrar para essa arquitetura ou o contrário. Caso você tenha um aplicativo serverless e chegou em um ponto de uso onde faça mais sentido sair dessa arquitetura, você pode começar a construir sua arquitetura “normal” e aos poucos “desligando” seus serviços disponibilizados no aplicativo serverless.
Escala
Você delegar a orquestração do seu aplicativo para o provedor, se torna uma das maiores vantagens também da arquitetura serveless, porque com isso, você não irá precisar se preocupar com o provisionamento e configuração do mesmo. Sendo assim, seu aplicativo “cresce” automaticamente de acordo com a necessidade e você paga somente pelo tempo de computação que esta sendo consumido.
Desvantagens
Controle de fornecedores
Como qualquer estratégia de terceirização, você está cedendo o controle de parte do seu sistema a um fornecedor terceirizado. Essa falta de controle pode se manifestar como tempo de inatividade do sistema, limites inesperados, alterações de custo, perda de funcionalidade, atualizações de API forçadas e assim por diante.
Bloqueio do fornecedor
Caso você queira realizar a troca de fornecedor, ou seja, sair da AWS e ir para o Google por exemplo, talvez você possa ter problemas com a diferença de recursos entre os fornecedores. Com isso, provavelmente se você vier a realizar a troca de fornecedor, você terá que realizar alterações no seu sistema referente a tecnologias e a forma que são implementadas.
Monitoramento
Como você não tem um controle total do provisionamento e seus serviços FaaS, por muitas vezes, realizar o monitoramento do seu aplicativo se torna algo penoso.
Mas preciso monitorar algo? Se você utilizar, por exemplo, AWS Lambda (que veremos mais para frente), seria interessante você realizar o monitoramento de perto do consumo de memória, tamanho e tempo de execução de cada function do seu aplicativo
Alguns provedores serverless
AWS Serverless
De todos os provedores mencionados acima ou que existem, irei falar sobre o AWS Serverless.
Na AWS para você construir seus aplicativos basicamente você irá utilizar de 3 formas:
- AWS Fargate
- AWS Lambda@Edge
- AWS Lambda
AWS Fargate
O AWS Fargate é um mecanismo de computação sem servidor especialmente desenvolvido para containers que funciona com o Amazon Elastic Container Service (ECS) e com o Amazon Elastic Kubernetes Service (EKS). O Fargate escalona e gerencia a infraestrutura necessária para executar seus containers. Além disso, elimina a necessidade de provisionar e gerenciar servidores, permite que você especifique e pague pelos recursos por aplicativo, além de aumentar a segurança ao conceber aplicativos isolados.
O Fargate aloca a quantidade certa de computação, eliminando a necessidade de escolher instâncias e ajustar a escala da capacidade do cluster. Você só paga pelos recursos exigidos para a execução dos containers, por isso, não há excesso de provisionamento nem pagamento por servidores adicionais.
Segue uma imagem que ilustra como funciona:
Definição de preço do AWS Fargate
A definição de preço do AWS Fargate é calculada de acordo com os recursos de vCPU e memória usados do momento em que você começa a fazer download da imagem do container até que a tarefa do Amazon ECS ou pod do Amazon EKS* sejam encerrados, arredondado para o segundo mais próximo.
Duração
A duração da definição de preço é por segundo com o mínimo de um minuto. Onde a mesma é calculada do momento em que o download da imagens de container (pull do docker) é iniciado até o término da tarefa, arredondado para o segundo mais próximo.
Exemplo de definição de preço da região Leste dos EUA (Norte da Virgínia):
Por exemplo, se o seu serviço usa 10 tarefas ECS em execução por 1 hora (3600 segundos) todos os dias por um mês (30 dias) onde cada tarefa ECS usa 0,25 vCPU e 1 GB de memória.
Cobranças mensais de CPU
Total de cobranças de vCPU = nº de tarefas x nº de vCPUs x preço por segundo de CPU x duração de CPU por dia (segundos) x nº de dias
Total de cobranças de vCPU = 10 x 0,25 x 0,000011244 x 3600 x 30 = 3,04 USD
Cobranças mensais de memória
Total de cobranças de memória = nº de tarefas x memória em GB x preço por GB x duração da memória por dia (segundos) x nº de dias
Total de cobranças de memória = 10 x 1 x 0,000001235 x 3600 x 30 = 1,33 USD
Cobranças mensais de computação Fargate
Cobranças mensais de computação Fargate = cobranças mensais de CPU + cobranças mensais de memória
Cobranças mensais de computação Fargate = 3,04 USD + 1,33 USD = 4,37 USD
AWS Lambda@Edge
O Lambda@Edge permite a execução de funções do Lambda em pontos de presença da AWS como resposta a eventos do Amazon CloudFront.
Lambda@Edge é um recurso do Amazon CloudFront que permite executar o código mais próximo dos usuários do seu aplicativo, o que melhora o desempenho e reduz a latência. Com o Lambda@Edge, você não precisa provisionar ou gerenciar a infraestrutura em vários locais ao redor do mundo.
Basta fazer upload do código no AWS Lambda que ele cuidará de tudo o que é necessário para executar e dimensionar seu código com alta disponibilidade em um local da AWS mais próximo de seu usuário final.
Segue uma imagem que ilustra como funciona:
AWS Lambda
O AWS Lambda e Lambda@Edge no fundo são a mesma coisa, mas possuem somente uma leve diferença onde o API Gateway e o Lambda são serviços regionais. O uso do Lambda@Edge e do Amazon CloudFront permite executar lógica em vários locais da AWS de acordo com o posicionamento dos visualizadores finais.
O AWS Lambda permite executar códigos sem provisionar ou gerenciar servidores. Você paga apenas pelo tempo de computação utilizado. Não haverá cobranças quando o código não estiver em execução.
Com o Lambda, você pode executar o código para praticamente qualquer tipo de aplicativo ou serviço de back-end, tudo sem precisar de administração. Basta carregar o código e o Lambda se encarrega de todos os itens necessários para executar e alterar a escala do código com alta disponibilidade. Você pode configurar seu código para que ele seja acionado automaticamente por outros serviços da AWS ou chamá-lo diretamente usando qualquer aplicação móvel ou da web.
O AWS Lambda pode executar automaticamente código em resposta a vários eventos, como solicitações HTTP por meio do Amazon API Gateway, modificações de objetos em buckets do Amazon S3, atualizações de tabela no Amazon DynamoDB e transições de estado no AWS Step Functions.
O código que você executa no AWS Lambda é chamado de “função do Lambda” (lambda function). Depois de criar sua função do Lambda, ela está sempre pronta para execução assim que acionada.
As funções do Lambda são “stateless”, sem nenhuma afinidade com a infraestrutura adjacente, para que o Lambda possa lançar rapidamente quantas cópias da função forem necessárias para escalar de acordo com o volume de eventos recebidos.
Segue uma imagem que ilustra como funciona:
Definição de preço do AWS Lambda
Com o AWS Lambda, pague somente pelo que for usado. Você é cobrado pelo número de solicitações de suas funções e pela duração, o tempo que leva para que seu código seja executado.
O Lambda conta uma solicitação cada vez que começa a executar em resposta a uma notificação de evento ou chamada de invocação, incluindo invocações de teste do console.
O preço também depende da quantidade de memória que você alocar para sua função.
Capacidade de CPU e outros recursos são alocados de forma proporcional. Um aumento no tamanho da memória aciona um aumento equivalente na CPU disponível para sua função
Duração
A duração é calculada a partir do momento em que seu código começa a ser executado até ele retornar ou encerrar, arredondando para os 100 ms mais próximos.
Free tier
AWS Lambda esta no AWS Free Tier com 1.000.000 solicitações gratuitas por mês e até 3,2 milhões de segundos de tempo de computação por mês.
O que provavelmente será mais do que suficiente para seu aplicativo no início e por um bom tempo.
Exemplo de definição de preço da região Leste dos EUA (Norte da Virgínia):
Se você alocou 512 MB de memória para sua função, a executou 3 milhões de vezes em um mês e ela foi executada 1 segundo, por vez, suas cobranças serão calculadas desta forma:
Cobranças mensais por computação
O preço mensal calculado é de 0,00001667 USD por GB-s e o nível gratuito oferece 400.000 GB-s.
Cálculo total (segundos) = 3 milhões * (1 s) = 3.000.000 segundos
Cálculo total (GB-s) = 3.000.000 * 512 MB/1024 = 1.500.000 GB-s
Cálculo total − cálculo do nível gratuito = cálculo mensal de GB/s faturáveis
1.500.000 GB-s − 400.000 GB-s do nível gratuito = 1.100.000 GB-s
Cobrança mensal de computação = 1.100.000 * 0,00001667 USD = 18,34 USD
Cobrança mensal de solicitações
O preço de solicitações mensais é 0,20 USD por 1 milhão de solicitações e o nível gratuito oferece 1 milhão de solicitações por mês.
Solicitações totais − solicitações do nível gratuito = solicitações mensais faturáveis
3 milhões de solicitações − 1 milhão de solicitações do nível gratuito = 2 milhões de solicitações mensais faturáveis
Cobrança de solicitações mensais = 2 milhões * 0,2 USD/milhão = 0,40 USD
Total de cobranças mensais
Cobrança totais = cobrança de computação + cobrança de solicitações = 18,34 USD + 0,40 USD = 18,74 USD por mês
Conclusão
Cada vez mais se tem falado sobre serverless e com isso o estudo e entendimento do mesmo se torna fundamental, se não for para aplicar em seu projeto atual, para saber da existência, de como funciona e poder tomar melhores decisões em projetos futuros.
Recentemente tenho me envolvido em novos projetos com o uso de AWS Lambda e Amazon DynamoDB.
Através desses projetos posso garantir que a produtividade no desenvolvimento desses aplicativos se tornam muito maiores devido não existir a necessidade de orquestração e etc do mesmo, o que é excelente para equipes pequenas.
Também, os custos relacionados aos projetos se tornaram extremamente baixos, o que é ideal para um projeto recém nascido e com o budget reduzido.
Mais para frente, realizarei a criação de mais posts falando de como utilizar na prática AWS Lambda através do Serverless Framework e como a utilização dessas tecnologias podem acelerar o lançamento dos seus produtos.
Acredito que essa arquitetura irá ganhar cada vez mais força e utilização nos próximos anos, então estudar e se envolver com ela é algo interessante que você possa fazer.
Espero que esse post tenha lhe ajudado a compreender um pouco sobre universo que envolve essa tecnologia e que possa ter despertado o seu interesse em saber mais sobre a arquitetura serverless.
Obrigado, abraços.
