GuruSumário
O que é Arquitetura serverless?
Fala pessoal, beleza?!
Quando nós, desenvolvedores, recebemos a missão de colocar um sistema em produção, pensamos logo na dificuldade da escolha de um servidor. Além disso, pensamos também sua capacidade, poder de processamento, disco, o quanto de requisições o sistema terá que aguentar e o quão complexo e cansativo é o processo de refinamento até conseguir chegar no cenário ideal. Ainda, sem contar que, quando pensamos em cloud, um servidor com capacidade X custa um preço, um X2 custa outro, um X3 custa outro e assim vai. Assim, isso exige bastante nas decisões do que será preciso vs o cenário ideal vs o que podemos ter.
Em uma startup com foco em tecnologia, não podemos aceitar esse tipo de cenário. Então, seja pelo custo em si, onde não podemos desperdiçar nada do nosso budget limitado, ou pelo tempo que perdemos com manutenções, atualizações de S.O e etc. Assim, precisamos pensar fora da caixa e nos levar ao limite da inovação, nos desafiar com o que é possível e o que não é.
Somos Serverless!
Na Guru, optamos por ter a maior parte do nosso backend em arquitetura serverless, ou seja, sem servidores. Legal, né?! Mas dá um baita trabalho pensar o tempo inteiro em como isso vai funcionar. Dessa forma, para conseguir explicar, precisamos passar por vários contextos até entender de fato o que é uma arquitetura serverless.
Vamos começar do básico:
Arquitetura Serverless – O básico
1 – Contêineres.
Com o advento da virtualização, diversas empresas começaram a dividir grandes servidores em pequenas máquinas virtuais através de uma tecnologia Hypervisor. É exatamente isso que você tem quando coloca seu blog ou site em uma dessas plataformas de hospedagem pela internet.
Então, com o passar dos anos, o dinamismo desses ambientes virtualizados começou a ser questionado, seja na questão de disponibilidade: por que para ajustar mais CPU ou memória para uma máquina virtual, é necessário reiniciá-la e tudo o que está sendo executado nela, necessariamente fica indisponível; ou pela necessidade de grandes times de infraestrutura para administrar.
Desde 2006, diversas empresas começaram a pensar em como essa virtualização poderia ser diferente. Process Containers de 2006, LXC de 2008, Warden de 2011, LMCTFY de 2012, são exemplos de projetos que foram criados com a intenção de dinamizar e dar mais escalabilidade as virtualizações, mas nenhum deles se popularizou.
Até que, em meados de 2013, nasceu uma tecnologia que assumiu a liderança e começou a ditar como trabalhariamos com virtualizações a partir daquele momento: o Docker.
Assim, containers Docker nada mais são do que um ambiente mínimo virtualizado, que compartilha recursos com o servidor hospedeiro e possui somente a função de executar a aplicação que estiver dentro dele.
A própria Docker Inc, disponibiliza um desenho que exemplifica a comparação com Hypervisor:
Então, o que isso significa?
Significa que antes, para rodar uma aplicação web em produção, eu precisava ter uma máquina virtual com acesso a internet. Além disso, precisava que essa máquina tivesse um servidor web executando o encapsulamento e interpretação da minha aplicação, e que toda atualização, precisaria configurar essa máquina, o servidor web e tudo mais o que fosse necessário para que pudesse disponibilizar o acesso a ela.
Assim, a partir de 2013, com o docker, para fazer a mesma coisa só é preciso executar o comando: docker run -p 80:80 repositório/imagem:versão na máquina em questão e pronto. Então, o ambiente estará no ar. E se por um acaso, for necessário escalar, é só montar um cluster e duplicar a imagem com um load balancer e pronto.
Mais rápido, dinâmico e escalável.
2 – Contêineres Efêmeros
Contêineres efêmeros diferentes de contêineres convencionais são conhecidos por terem pouquíssimo tempo de vida. Dessa forma, um contêiner efêmero nasce com o objetivo de executar determinada ação, a após executá-la é desligado e destruído.
3 – Stateless vs Stateful
Outro conceito importante que precisa ser discutido antes de entrarmos a fundo em arquitetura serverless, é o conceito de stateful e stateless de aplicações.
Aplicações stateful são aplicações que o controle de estado da interação e permite que os dados sejam mantidos entre diferentes requisições. Assim, tem como principal vantagem a fluidez das interações, uma vez que toda a jornada do usuário é armazenada em memória. Além disso, tem como sua principal desvantagem o alto consumo de recursos computacionais.
Aplicações stateless são aplicações que não armazenam nenhuma informação de controle de estado de interação e trabalham somente com o que está disponível naquele contexto. Assim, acabam exigindo algumas informações extras do lado cliente para conseguir um processamento eficiente, mas tem como principal vantagem o baixíssimo consumo de recursos computacionais.
4 – Configurações Remotas
Ainda, o penúltimo conceito a ser explorado para entendermos a eficiência de uma arquitetura serverless é o conceito de configuração remota.
Uma aplicação que roda em um ambiente serverless não tem um arquivo de configuração para ler, logo, ela deve buscar as informações que precisa de outro lugar no momento do startup. Então, é aí que um servidor de configuração remoto entra em ação. Um servidor de configuração remoto deve fornecer tudo o que a aplicação precisa para seu funcionamento básico: ambiente e contexto.
5 – Service Discovery
Service discovery é um processo de detecção automática de aplicações dentro de um mesmo contexto de rede. Ou seja, assim que uma nova aplicação começa a operar em uma rede fechada, automaticamente ela é mapeada e registrada como “disponível” para ser utilizada.
A Arquitetura Serverless
Agora que já entendemos os 5 princípios básicos, podemos dar vida ao conceito de arquitetura serverless na cabeça de todo mundo que está lendo com uma simples conta matemática:
Aplicações Stateless + Configurações Remotas + Service Discovery + Contêineres Efêmeros
Então, parafraseando meu amigo Jefferson Fernando do LinuxTips: “Simples como voar!”
FaaS e BaaS
Todos os provedores de cloud atualmente possuem diversos serviços que podem ser “costurado” com pouquíssimas linhas de código e que facilitam bastante a vida dos desenvolvedores.
BaaS – Backend as a Service
O conceito de Backend as a Service existe graças a infinidade de APIs e SDKs disponíveis no mercado que “já fazem o que você quer fazer”. É um organismo vivo que cresce minuto a minuto para facilitar a vida do desenvolvedor de software.
Exemplo de provedores de BaaS:
- Amazon RDS – Banco de Dados
- Amazon API Gateway – API Gateway
- Mulesoft – API Gateway
- Google OAuth – Autenticação
- Ethereum – Blockchain
FaaS – Function as a Service
O conceito de Function as a Service já abstrai completamente a gestão de recursos computacionais e gestão de contêineres efêmeros, deixando para o desenvolvedor somente o trabalho de “codar” sua aplicação (como se isso já não fosse problemático o suficiente).
Exemplo de provedores de FaaS:
- Amazon Lambda
- Google Cloud Functions
- Microsoft Azure Functions
Com todos esses conceitos complicados, por que escolhemos ter uma Arquitetura Serverless?
Assim, a resposta é simples: A relação custo x benefício
Vamos começar falando do custo:
Exemplo a tabela da Amazon para FaaS:
USD 0.0000002 para o processamento de uma requisição… acho que não será preciso explicar muito mais, não é?
Agora, vamos falar do ponto chave e mais importante para nós: Escalabilidade
Vantagens da Arquitetura Serverless
A principal vantagem de uma arquitetura serverless é a possibilidade de se escalar horizontalmente de acordo com a necessidade daquele momento.
Assim, vamos supor que uma única instância do meu FaaS esteja executando para processar o login de 100 usuários simultâneos. No segundo seguinte, 1 milhão de usuários resolvem fazer login ao mesmo tempo. O que aconteceria se tivéssemos uma infraestrutura tradicional? Geraria uma fila de requisições a serem atendidas e quem chegou por último ficaria esperando um tempo até conseguir ser atendido. Então, no dia seguinte, iríamos atrás de mais servidores para fazer um cluster robusto para aguentar essa demanda novamente caso ela acontecesse.
Dessa forma, com Arquitetura Serverless, nossos provedores detectam a enxurrada de requisições e começam a subir mais instâncias do meu FaaS para que esse processamento seja feito o mais rápido possível. E, no momento seguinte em que as requisições foram feitas, as instâncias adicionais morrem e tudo volta ao normal. Assim, temos usuários atendidos e sem custos adicionais com servidores.
Cliente atendido e feliz, Startup feliz.
Temos um belo desafio pela frente de construir mais e mais aplicações serverless que atendam nossos usuários. Ainda, estamos no caminho e aceitamos ideias e sugestões para melhorarmos cada vez mais.
#VemPraAção
Abraços!
