Serverless

Arquitetura para aplicações baseadas em eventos que não necessitam de um servidor rodando para sempre

Publicado por Lohan Bodevan 30 de Dezembro de 2017 às 18:58

Você já deve ter ouvido falar desse termo por aí e ficou se perguntando: Qual a aplicabilidade disso no meu dia a dia? Como eu desenvolvo uma aplicação "sem servidores"? E quais as vantagens disso?

Serverless

O intuito desse post é trazer o conceito e mostrar sua aplicabilidade no dia a dia. O assunto é bem extenso então vou tentar ser bem sucinto.

O nome nos induz a pensar que, com a arquitetura serverless, uma aplicação irá existir sem servidores ou máquinas virtuais, o que não é verdade.

O que ocorre de fato é que toda a operação, provisionamento, dimensionamento e manutenção fica a cargo do provedor cloud. Aos desenvolvedores cabe, codificar e configurar quais eventos irão invocar tal código. Daí pra frente fica a cargo da cloud instanciar uma máquina virtual, ou container, com capacidade para executar seu código e depois destruí-lo ou interromper sua execução. 

Perceba que o código ainda irá rodar em um servidor porém esses servidores não ficam "ligados" o tempo inteiro de forma ociosa.

É um paradigma diferente de desenvolvimento que exige certa adaptação e desconstrução do modelo tradicional que criamos aplicações. 

Exemplo prático

Vamos utilizar um exemplo bem simples. Imagine que temos um sistema que em um determinado momento do dia, todos os dias, faz upload do relatório de vendas em formato CSV. Nosso suposto sistema roda em um provedor cloud e nós seguimos as boas práticas de software escalável na nuvem. Sendo assim, todo upload de arquivo é armazenado em sistema de storage também na nuvem, algo como o S3 da Amazon AWS.

Pois bem, esse relatório diário enviado para o storage é utilizado por diversas outras aplicações e além disso, todo relatório deve ser armazenado em uma base de dados isolada para fins de auditoria.

Tradicionalmente uma das opções que temos para resolver este problema seria, feito o upload no storage, mandar o CSV também para outra aplicação web que teríamos que construir, cujo a tarefa seria:

  • Receber um request com o arquivo CSV;
  • Interpretá-lo;
  • E armazená-lo no banco de dados.

Note porém, que teriamos que provisionar um servidor para tal operação, uma máquina virtual que iria rodar 24x7 esperando o dia inteiro por um arquivo CSV para então executar poucas linhas de código.

De cara parece um bom exemplo de micro-serviço se não fosse o custo financeiro e operacional de manter permanentemente essas poucas linhas de código no médio/longo prazo. 

Este é um ótimo exemplo de aplicabilidade da arquitetura serverless, pois o fato de utilizarmos um provedor cloud e a ocorrência de um upload no storage ser um evento nesse provedor cloud, é tudo o que precisamos para executar nossas poucas linhas de código.

O que quero dizer é, nosso sistema consistem em um única função que só precisa existir quando um relatório for enviado, e não precisamos de um servidor rodando 24 horas por dia para isso. Precisamos apenas de um evento que invoque nossa função.

Para tal podemos utilizar a solução serverless do nosso provedor cloud. Se você estiver utilizando Amazon AWS, existe o serviço chamado Lambda. Ou se você estiver utilizando o Google Cloud, existe o serviço chamado Cloud Functions.

O que precisamos entender é o conceito, sabendo disso, fica fácil utilizar um desses dois ou até outros existentes no mercado. 

Tudo o que precisamos fazer é criar esse trecho de código que lê um arquivo CSV e salve seu conteúdo numa base de dados. Após isso, nosso código pode ser "desligado" até um novo evento ocorrer. As operações de provisionamento são automatizadas pelo provedor cloud.

Ao configurar nossa aplicação serverless, temos que dizer qual evento irá invocar nosso código, e para isso cada cloud tem sua forma de configurar, entrarei em mais detalhes em um post futuro dedicado a cada serviço.

O interessante é que caso esse evento seja invocado uma ou mil vezes no dia, não teremos que nos preocupar com a infraestrutura para atender tal demanda.

Além disso iremos pagar apenas pelo tempo de execução e consumo de recursos, enquanto nossa função permanecer executando. Num cenário onde somos cobrados por hora ou minutos, como no Google Cloud ou Amazon AWS, a execução de uma única função em alguns segundos ou até milisegundos pode trazer grande economia versus deixar uma máquina virtual ligada 24 horas por dia.

Conclusão

Neste exemplo simples, o evento de invocação foi o upload de um arquivo no storage mas, é possível utilizar muitos outros eventos, tanto no Lambda quanto no Cloud Functions.

É possível inclusive utilizar um request HTTP como evento e ter uma API Web serverless. Por exemplo, se você tem um sistema de autenticação que só é chamado quando houver um HTTP POST na url /login, isso pode ser o trigger para invocar uma função que autentica o usuário.

Existem muitas outras aplicabilidades para a arquitetura serverless, seja para aplicações web, seja para tarefas isoladas, seja para operações de infraestrutura.

Call for contributors

Inicie recentemente um projeto open source cujo intuito é ligar ou desligar servidores de aplicações que não foram pensados para arquitetura serverless, mas que não precisam estar ligados 24 horas por dia.

Como o intuito é economizar não faria sentido esse projeto rodar em uma máquina virtual, portanto ele foi pensado para rodar baseado em eventos utilizando arquitetura serverless.

Imagina que a sua empresa utilize como provedor a Amazon AWS e seu time tenha uma EC2 rodando o Jenkins para fazer o trabalho de integração contínua. O Jenkins é uma ótima ferramenta porém não faz sentido a EC2 que ele roda ficar ligada as 2 da manhã sendo que o não tem (ou quase nunca tem) ninguém na empresa nesse horário.

O projeto Light Switch permite que você agende o ligamento ou desligamento de servidores, fazendo com que serviços como o Jenkins só rode nos horários que sua equipe está trabalhando.

O projeto consiste em poucas linhas de código que são invocadas a partir de um evento. Chegado o horário agendado, esse evento é disparado e o código é executado. Os servidores registrados nele serão desligado ou ligados, dependendo do seu estado atual. Como um interruptor, se estiver ligado, o servidor será desligado e vice-versa. 

Você pode então configurar o agendamento para as 8 da manhã e as 10 da noite, então ganhará 10 horas de economia diária. Outros casos de uso para o projeto são servidores GIT, servidores de testes, servidores para sistemas internos, entre outros. 

O projeto está bem no início e se sentir que pode ajudar na sua empresa, fique a vontade para criticar, enviar mais funcionalidades e melhorias.

Grande abraço!


Comentários