Serverless: uma introdução

Tradicionalmente as aplicações eram desenvolvidas e então publicadas em máquinas físicas. O desenvolvedor tinha que ter o controle de todas as nuances, desde o sistema operacional, suas configurações de segurança, quais portas seriam abertas, quais serviços rodariam em background, qual stack de software seria instalada, quais softwares seriam compilados etc.

Além disso, atualizar software se faz necessário de tempo em tempo, o que implica em outra preocupação para o desenvolvedor, ademais, quebrar um ambiente devido a algum update indevido ou problemático não é tão difícil de acontecer. Nesse modelo, o desenvolvedor sempre gastou muito tempo com infraestrutura, sendo que ele poderia estar focado no desenvolvimento do produto.

Curso Kubernetes - Health Check, Resources, Automação e Administração de cluster

Conhecer o curso

O advento da computação em nuvem

O surgimento das máquinas virtuais e do hypervisor inseriu um novo paradigma, onde é possível criar uma unidade de computação em minutos. Posteriormente os containers elevaram ainda mais o nível, realizando essa mesma tarefa em segundos.

Com isso, passamos a ter uma abundância de provedores de IaaS (Infrastructure as a Service - infraestrutura como serviço) e PaaS (Platform as a Service - Plataforma como serviço). Essas plataformas libertam o desenvolvedor (em parte) de ter toda a responsabilidade que tradicionalmente lhe era imputada, a de manter uma infraestrutura com todos os detalhes técnicos que comentamos anteriormente.

Mas, ainda assim, não é tão simples operar um produto na nuvem, a preocupação e o trabalho em administrar e orquestrar todas as partes da engrenagem ainda existe. Ter que provisionar, cuidar da escalabilidade etc.

Serverless

As plataformas de IaaS e PaaS existentes atualmente (AWS, Google Cloud, Azure, Heroku etc) são extremamente robustas e resolvem a maioria dos problemas que anteriormente tínhamos com escalabilidade e gerenciamento de hardware.

Mas, a grande novidade ainda estava por vir: as FaaS (Functions as a Service - Funções como serviço).

A pirâmide da evolução da computação em nuvem:

               '
              /=
             /=== 
            /=====' 
           / FaaS  '' 
          /========= ' '
         /=== PaaS ==''   
        /============= ' '  
       /===============   ''  
      /== Containers ===' ' ' ' 
     /===================' ' '  ' 
    /=====================' '   ' ' 
   /== Máquinas Virtuais ==  '   ' /
  /=========================   ' /
 /==========================='  /
/====== Máquinas Físicas =====/

A arquitetura Serverless é sobre delegar a responsabilidade de cuidar de uma infraestrutura para serviços que fazem isso com expertise e conhecimento de causa, como a AWS, Google Cloud etc. Também é sobre não se preocupar com limites e escalabilidade (sem bem arquitetado). Você paga pelo tempo de processamento que usa.

É muito comum ler que pregam que um dos principais pontos de Serverless refere-se ao corte de custos, ou seja, você não paga pelo tempo ocioso do servidor. Isso é verdade se a arquitetura da solução for bem desenvolvida. Mas, Serverless não é apenas sobre cortar custos (mesmo que possível), é mais que isso. Se escolhe Serverless por todos os outros benefícios que essa arquitetura pode trazer: ela tira a necessidade de provisionamento explícito / alocação de recursos e escala automaticamente. Há de ressaltar, inclusive, que dependendo do caso de uso e do projeto, Serverless pode ser uma solução que agrega mais custos ao invés de diminuí-los.

Serverless “FaaS”

Functions as a Service (FaaS) nos habilita publicar e invocar funções de curto período de vida (efêmeras). Ao invés de pensarmos em aplicações e processos, passamos a pensar em funções (também conhecidas como lambdas). Escrevemos a função e o provedor FaaS fica na responsabilidade de executá-la. Veja que o foco aqui é na construção da solução, no desenvolvimento.

A plataforma FaaS que “revolucionou” e trouxe ainda mais à tona o conceito Serverless foi a AWS Lambda, com a premissa:

Execute códigos sem pensar sobre os servidores. Pague apenas pelo tempo de computação que você utilizar.

Nesse serviço, Lambdas são invocadas por eventos (Event-driven), que podem ser:

• Uma requisição HTTP (Ex: quando uma rota GET /filmes for executada, uma lambda pode ser disparada para retornar os resultados);
• Uma mensagem numa fila (queue);
• Um novo arquivo que foi armazenado num serviço de storage (S3 da AWS, por exemplo);
• Etc;

Todos os exemplos acima são eventos e para cada um deles, poderíamos ter uma lambda sendo disparada para lidar com algum tipo de processamento.

No primeiro exemplo da requisição HTTP, se usarmos a AWS como nosso provedor FaaS, a parte da requisição HTTP e sua rota seria configurada pelo serviço API Gateway e a execução da função seria feita pelo AWS Lambda (que é o serviço FaaS da AWS).

Como funciona o AWS Lambda:

(Fonte: AWS)

O AWS Lambda tem uma integração magnífica com os outros serviços da própria AWS, sendo possível, por exemplo, termos uma lambda configurada para responder ao evento de um objeto salvo num bucket S3 (num disco de armazenamento) e então realizar um processamento sobre esse objeto. Vamos supor que o objeto seja a foto de um usuário que foi upada, poderíamos ter uma lambda respondendo a esse evento para que assim que ela for salva, a lambda seja invocada para compactar/otimizar essa imagem ou até mesmo gerar novas versões dela, como thumbs, por exemplo.

Curso Amazon Web Services (AWS) - S3 - Fundamentos

Conhecer o curso

Inclusive, é possível encontrar diversas funções já desenvolvidas pela comunidade, como essa aqui, a aws-lambda-image, que faz algo muito parecido com o cenário anteriormente comentado.

Outro exemplo da combinação do AWS Lambda com outros serviços da AWS para um aplicativo web altamente disponível e integrado:

(Fonte: AWS)

Nesse exemplo, uma aplicação web (o seu front-end, HTML/CSS/JS) estão hospedados num bucket S3, o usuário clica para obter as últimas informações sobre o tempo, o API Gateway responderá à uma requisição HTTP, isso gerará um evento que fará com que uma Lambda seja executada, e ela é responsável por consultar o DynamoDB que é onde os dados meteorológicos estão salvos.

Nesse modelo temos [Eventos] que são gatilhos para executar [Funções] que se comunicam com [Recursos].

Os benefícios de FaaS destacados pela AWS:

• Não há servidores para serem gerenciados: O AWS Lambda executa automaticamente o seu código sem exigir que você provisione ou gerencie servidores. Basta escrever o código e carregá-lo no Lambda.
• Escalabilidade contínua: O AWS Lambda escala automaticamente os aplicativos executando código em resposta a cada acionamento. O código é executado em paralelo e processa cada acionamento individualmente, escalando precisamente de acordo com o tamanho da carga de trabalho.
• Medidor de fração de segundo: Com o AWS Lambda, você é cobrado a cada 100 ms de execução do código e pelo número de vezes que o código é acionado. Você não paga nada quando o seu código não está em execução.

Pesquisadores da Universidade de Berkley (Califórnia) afirmam categoricamente que Serverless será o paradigma da computação em nuvem no futuro próximo. Lançaram nessa semana um paper intitulado: Cloud Programming Simplified: A Berkeley View on Serverless Computing. Muitos insights nesse documento sobre Serverless, as falácias envolvidas, as limitações (o fato de ser stateless traz alguns desafios; debugar ainda não é tão simples; etc) e o futuro dessa tecnologia na “nova era” Cloud.

Um quadro de comparação que fizeram entre AWS Serverful Cloud (Uma instância EC2. Onde o desenvolvedor tem que se preocupar com o provisionamento, sistema operacional, escalabilidade etc) e AWS Serverless Cloud (que no caso estão se referindo ao AWS Lambda):

(Fonte: Cloud Programming Simplified: A Berkeley View on Serverless Computing)

Essa tabela é perfeita pois ela exemplifica muito bem as responsabilidades em cada uma das abordagens, sendo que em Serverless elas são delegadas ao provedor (nesse caso, AWS).

Nesse momento você também já deve ter notado que Serverless desacopla computação e armazenamento. Para lidar com armazenamento, deve-se usar outro serviço oferecido pelo provedor. É aqui que entram os BaaS (Backend as a Service), que são serviços “complementares” oferecidos pelos provedores. No caso da AWS temos, por exemplo:

• Dynamo DB (banco de dados não relacional);
• RDS (bancos de dados relacionais);
• S3 (storage)
• SQS (queue);
• Etc;

Esses serviços são os maiores aliados das FaaS, é com eles que a “mágica acontece”, que toda a integração é feita e que a Cloud é simplificada (no sentido da não administração de servidores).

Isso é muito bem representado nesse diagrama (do próprio documento da Universidade de Berkley):

Concluindo

Espero que esse artigo introdutório acenda uma “chama” no seu interesse em pesquisar e estudar um pouco mais sobre Serverless.

A abordagem Serverless exige que mudemos a forma com que desenvolvemos as nossas aplicações. Impacta diretamente em como o código é construído, ademais, deixamos de lidar diretamente com os servidores. Uma questão importante é que Serverless não veio para substituir (de imediato) toda a forma com que desenvolvemos atualmente na nuvem, é apenas uma opção escalável, confiável e que, atualmente, tem seus prós e contras, como qualquer outra tecnologia.

Não é porque Serverless existe que devemos migrar toda a forma com que nossas aplicações são desenvolvidas. Esse tipo decisão não é tão simples, passa por uma análise do todo, da engenharia do software, de como ele poderia ser decomposto, da necessidade dele ser menos acoplado, de como a escalabilidade dele afeta o negócio etc.

Mas, de fato, Serverless é um caminho sem volta. Investimentos vultuosos estão feitos pelos principais provedores de nuvem para tornar essa tecnologia ainda mais acessível e mais expansiva. Estamos diante de um novo capítulo da era Cloud.