9 minutos de leitura

Arquiteturas Serverless são padrões de design de sistemas que incorporam serviços terceirizados “Back-end as a Service” (BaaS), e/ou incluem ambientes de execução de código customizados em containers efêmeros gerenciados numa plataforma de “Functions as a Service” (FaaS). Usando estas ideias em conjunto com padrões de design de front-end como “Single Page Applications” (SPA), essas arquiteturas removem grande parte (se não toda) a necessidade de servidores always-on tradicionais. Arquiteturas Serverless podem reduzir significativamente o custo operacional, complexidade e tempo de engenharia (DevOps), com o custo de maior dependência do provedor (lock-in) e seus serviços relacionados, além de suporte comparavelmente “imaturo”.

Um dos, se não o mais relevante tópico no mundo de arquitetura de software atualmente é Serverless Computing. Os três maiores provedores de soluções em cloud (Amazon, Google e Microsoft) estão investindo de forma agressiva em Serverless, onde a Amazon foi pioneira com seu serviço AWS Lambda. Para entender melhor o porquê, primeiro é necessário entender:

O que é Serverless?

Como tudo no mundo de software, não há uma definição precisa sobre o que é Serverless. Nas últimas décadas, houve uma transição grande no mundo da arquitetura e infraestrutura de servidores, de on-premise (máquinas físicas localizadas dentro da empresa, administradas e gerenciadas pelas mesmas), para Infrastructure as a Service (serviços que te oferecem uma máquina real/virtual, gerenciada pelo usuário mas administrada pela provedora de serviço), para Platform as a Service e/ou Containers as a Service (serviços que oferecem gerenciamento e provisionamento de máquinas virtuais baseadas em containers).

Mais recentemente, também surgiu o formato Back-end as a Service (ecossistema com serviços de autenticação de usuário, armazenamento de arquivos, bancos de dados, real-time messaging, entre outros), que dispensou o trabalho de gerenciamento de servidores e infraestrutura quanto aos serviços atrelados, mas não dispensava completamente a necessidade de um servidor always-on para processamento de requisições, jobs, aplicações das regras de negócio, entre outros. Este formato foi a primeira parte do que é chamado hoje de Serverless Computing.

Além disso, surgiu também um outro formato: aplicações onde a lógica de servidor é escrita por desenvolvedores(as), mas tal código é executado apenas quando acionado por eventos (como uma requisição HTTP), em containers sem estado e efêmeros (podem durar por apenas uma invocação) que são gerenciados e administrados pelo provedor. Este formato é denominado Functions as a Service, e é a segunda parte de Serverless Computing. Um exemplo simples seria o processamento de imagens: uma requisição POST HTTP com um payload contendo uma imagem é feita a um endpoint do serviço FaaS, que invoca um container para executar uma única função — a de processar aquela imagem (seja alterando seu tamanho, aplicando filtros, classificando-a) e salvar o resultado em um armazenamento externo. Se muitas requisições forem feitas ao mesmo tempo, o serviço invoca mais containers.

Este formato é um grande passo. Enquanto Containers as a Service pode ser considerado uma evolução do paradigma já existente (um nível de abstração maior), FaaS é um novo paradigma por inteiro. No início, a maioria das pessoas imaginava FaaS como um complemento para os modelos atuais, e seu principal uso eram jobs esporádicos — processamento de imagens, busca, organização, filtros. Porém, com a difusão do serviço no mercado, mais e mais pessoas viram no mesmo uma maneira de substituir os modelos atuais de servidores por completo. Afinal, tudo o que o seu servidor em Express faz é mapear rotas a funções e middlewares e executá-las, não é mesmo?

A utilização destes dois modelos (BaaS e FaaS) implica que toda a infraestrutura da sua aplicação será gerenciada pelos provedores dos serviços escolhidos, e a sua única preocupação como desenvolvedor agora é o código e sua implementação. Isto é Serverless Computing.

Note que a tradução literal de Serverless é sem servidor. Isto não significa que sua aplicação não irá mais necessitar de um (ou mais) servidor(es), mas que tal infraestrutura não é mais sua responsabilidade. Serverless = sem administração de recursos operacionais.

E por que isto pode significar uma redução de custos?

Os provedores destes serviços só te cobram pelos recursos que sua aplicação utilizar. Se seu site tem poucos (ou nenhum) acesso, o provedor diminui os recursos atrelados à ele (podendo escalar à zero) e só te cobra pelo usado (incluindo nada, se ninguém utilizou). O contrário também é válido: se o seu site teve muitos acessos na Black Friday, o provedor cria mais containers (escalonamento horizontal) em máquinas gerenciadas por eles para atender todas as requisições e irá te cobrar mais por isso. É o melhor dos dois mundos: você não paga mais por ter uma ou mais máquinas mais potentes rodando 100% do tempo para atender seus picos de uso e ficando ociosas em momentos de baixa utilização, e ainda assim atende seus usuários em momentos de pico.

Além dos custos, quais são as outras vantagens e desvantagens?

Modelar uma aplicação utilizando FaaS e BaaS também implica em:
● um processo mais simples de DevOps: o deploy envolve apenas enviar a nova versão do código para o provedor, ele cuida do resto;
● código desacoplado: suas funções (que podem ser micro serviços por si só) não dependem mais de código compartilhado. Seu time pode trabalhar separadamente em partes diferentes da aplicação sem se preocupar em quebrar alguma funcionalidade externa (desde que as interfaces entre tais se mantenham);
● escalabilidade: o céu é o limite para escalabilidade de aplicações que fazem bom uso de FaaS e BaaS, já que toda a responsabilidade de infraestrutura é do provedor (a maioria tem até SLAs!)
● heterogeneidade tecnológica: código desacoplado e independente também significa que você pode fazer uso de diferentes tecnologias na sua aplicação (a interface é o segredo). Você tem uma solução que precisa fazer uso de bibliotecas só disponíveis em python, mas sua aplicação está em NodeJS? Sem problemas!
● resiliência: como as partes da sua aplicação serão auto-suficientes e desacopladas, a falha em uma parte dela não significa falha geral. Aplicações podem fazer uso disso para planejar falhas parciais e como lidar com elas.

Porém, nem tudo são flores. Existem algumas desvantagens também:
● você tende a se tornar dependente do seu provedor (sofrendo lock-in);
● existe a possibilidade de lidar com um suporte mais “imaturo”, dado que estes serviços estão constantemente em mudanças e há menos conteúdo disponível sobre os mesmos;
● a fragmentação do código, se em conjunto com desorganização, pode muito bem ser um caos maior do que lidar com os problemas de aplicações tradicionais.

A melhor opção para a sua aplicação é sempre discutir com o seu time os pesos de cada um dos pontos levantados acima. Tendo tais pontos em mente, eu considero que este tipo de arquitetura tende a se destacar (já está!) e se tornar um padrão de mercado moderno.