Uma Arquitetura Serverless (ou, em tradução livre, Arquitetura sem Servidor) é uma estrutura de aplicativos que hospeda serviços do tipo “Backend-as-a-Service” (BaaS) de terceiros e pode executar ou incluir código personalizado em containers gerenciados a partir de uma plataforma “Function-as-a-Service” (FaaS). Isso significa que a computação sem servidor permite que os desenvolvedores comprem serviços de backend em um modelo flexível, baseado na uberização do “pague conforme o uso”. Em outras palavras, os desenvolvedores só precisam pagar pelos serviços que usam, e gerenciar seu uso e sua disponibilidade para os usuários.

O preço é baseado na quantidade real de recursos consumidos por um aplicativo. “Sem servidor” é apenas uma metáfora, claro, na medida em que os servidores ainda são usados pelos provedores de serviços em nuvem, a fim de executar os códigos para os desenvolvedores. No entanto, neste modelo, os desenvolvedores não estão preocupados com o planejamento de: capacidade, configuração, gerenciamento, manutenção, operação ou dimensionamento de containers, máquinas virtuais (VMs) ou servidores físicos – algo bastante atraente para as operações de TI, já que podem simplesmente abstrair essa parte. Os servidores, contudo, não são eliminados; apenas permanecem sob a responsabilidade do provedor de serviços.

Em um artigo de 20 de junho de 2016, Badri Janakiraman, desenvolvedor da Apple, comentou sobre o conceito de serverless computing:

“Arquiteturas sem servidor são sistemas baseados na Internet em que o desenvolvimento de aplicativos não usa o processo de servidor normal. Em vez disso, eles dependem exclusivamente de uma combinação de serviços de terceiros, lógica do lado do cliente e chamadas de procedimento remoto hospedadas como serviço (FaaS ou Function-as-a-Service).”

É fato que as arquiteturas sem servidor podem se beneficiar de custos operacionais, complexidade e tempo de execução de engenharia significativamente reduzidos – razão pela qual tendem a se popularizar cada vez mais. Mas, qual o custo disso em termos de confiança nas dependências do fornecedor e dos serviços de suporte que ele oferece? É preciso entender que funções simples isoladas facilitam o desenvolvimento de aplicativos, enquanto a execução orientada a eventos torna as operações mais baratas. Mas, será que existem também desvantagens nesse modelo?

Desvantagens da Arquitetura Serverless

A resposta para essa pergunta é: sim! O modelo serverless requer muita cautela e profissionalismo em sua implementação, sendo alguns pontos de atenção:

• Vendor lock-in pode ser um risco

Permitir que um único provedor forneça todos os serviços de backend para um aplicativo – conhecido como vendor lock-in – inevitavelmente fará com que a confiança nesse fornecedor aumente. Configurar uma arquitetura sem servidor amarrado a apenas um provedor pode dificultar a troca de fornecedores futuramente, caso haja necessidade, e isso ocorre porque cada fornecedor oferece recursos e workflows levemente diferentes um do outro. Além disso, construir funções do tipo serverless em uma plataforma pode significar dor de cabeça quando, por alguma razão, houver a migração para outra plataforma. O código pode precisar ser reescrito, APIs que existem em uma plataforma podem não existir na outra e muito mais horas de desenvolvimento extras podem acabar comprometidas para mover, por exemplo, da AWS para Microsoft Azure ou Google Cloud.

• Problemas devido a sistemas de API de terceiros

O uso de APIs de terceiros requer muita cautela quanto a questões envolvendo: controle de fornecedor, multi-tenancy – quando uma única instância do software e sua infraestrutura de suporte atende a vários clientes – dependência de fornecedor (vendor lock-in) e questões de segurança. Por exemplo, abrir mão do controle do sistema durante a implementação de APIs pode levar ao tempo de inatividade do sistema, atualizações de API forçadas, perda de recursos, limites inesperados e, principalmente, alterações de custo.

• O teste e o debug são mais desafiadores

Os desenvolvedores dependem de fornecedores para ferramentas de debug e monitoramento. O debug é mais complicado porque os desenvolvedores não têm visibilidade dos processos de backend e porque o aplicativo é dividido em funções menores e separadas. Fazer o debug de funções serverless é possível, mas não é uma tarefa simples e pode consumir muito tempo e recursos.

• Arquiteturas serverless não são construídas para processos de longa duração

Isso limita os tipos de aplicativos que podem ser executados de forma econômica e otimizada em uma arquitetura sem servidor. Como os provedores sem servidor cobram pelo espaço de tempo em que o código fica disponível em execução, pode custar mais executar um aplicativo com processos de longa execução em uma infraestrutura sem servidor do que, por exemplo, em uma infraestrutura tradicional.

• O desempenho pode ser afetado

Como não está em execução durante todo o tempo, mas por intervalos específicos, o código serverless pode precisar ser “inicializado” quando for ativado. Esse tempo de inicialização, por outro lado, pode prejudicar o desempenho. No entanto, se um pedaço de código for usado regularmente, o provedor serverless o manterá pronto para ser ativado – uma solicitação para esse código pronto para uso é chamada de “warm start”. Já um request para um código que não é usado há algum tempo é chamado de “cold start”.

• Complexidade arquitetônica

Decisões sobre o quão granular uma função serverless deve ser levam tempo para aferir, implementar e testar. Precisa haver um equilíbrio quanto ao número de funções serverless que um aplicativo pode chamar. Como é bastante complicado gerenciar muitas funções serverless, ignorar questões associadas à granularidade da aplicação pode acabar levando à criação de mini-monólitos.

• Problemas de implementação

O teste de integração de aplicativos serverless não é tarefa fácil. As unidades de integração com um FaaS serverless (ou seja, cada função serverless) são muito menores do que com outras arquiteturas. Portanto, conta-se com muito mais testes de integração do que podemos se é possível fazer com outros estilos de arquitetura; problemas relacionados ao deploy, controle de versão e empacotamento também existir.

• Preocupações com segurança

Os provedores sem servidor frequentemente executarão código de vários de seus clientes em um único servidor a qualquer momento. Como as empresas não possuem servidores físicos próprios, a computação sem servidor acaba apresentando novas preocupações no que se refere à segurança. Questões associadas ao compartilhamento de máquinas com outras partes são chamadas de multi-tenancy. Essas questões podem afetar o desempenho do aplicativo; se os servidores multi-tenant não estiverem configurados corretamente, poderá resultar na exposição de dados. Por outro lado, essas questões têm pouco ou nenhum impacto para as redes com uma infraestrutura à altura, onde a sandbox funciona corretamente.

Portanto, se você for investir em uma plataforma sem servidor, certifique-se de que o fornecedor que você está considerando tenha tudo o que você precisa, pois ficar insatisfeito com seu provedor de computação sem servidor após alguns meses ou anos de serviço pode ser um grande problema lá na frente. 

Um pouco de história

Lançado por Austen Collins em outubro de 2015, e mantido por uma equipe com dedicação full-time, o Serverless Framework é uma plataforma web de código aberto escrita em Node.js. Desenvolvido com o objetivo de construir aplicativos no AWS Lambda – plataforma de computação sem servidor fornecida pela Amazon Web Services – os aplicativos criados com Serverless podem ser implementados para outras funções como provedores de serviços. Entre eles, destacam-se: Google Cloud usando Google Cloud Functions, Microsoft Azure com Azure Functions, IBM Bluemix com IBM Cloud Functions, baseado no Apache OpenWhisk, Oracle Cloud usando Oracle Fn e Kubeless baseado em Kubernetes, entre outros.

Um aplicativo sem servidor pode incluir algumas funções lambda para realizar tarefas específicas ou mesmo um backend inteiro formado por centenas de funções lambda. O framework Serverless oferece suporte a todos os tempos de execução oferecidos pelo fornecedor de nuvem escolhido.

—