Conteúdo
Nas edições anteriores desta série, explorámos passos fundamentais para estabelecer um projeto serverless, incluindo a configuração de um ambiente de desenvolvimento com ferramentas de emulação e a definição de uma arquitetura geral multicamadas. Este segmento foca-se na implementação de padrões de design adaptados ao desenvolvimento de um sistema serverless que segue o paradigma Function as a Microservice (FaaM). \n\nA questão da granularidade do serviço evoluiu juntamente com a história da computação distribuída. Nas décadas de 1970 e 80, surgiram abordagens iniciais de integração como Remote Procedure Calls (RPC), CORBA e Distributed Computing Environment (DCE), mas que frequentemente eram limitadas em escalabilidade e flexibilidade para ambientes híbridos. A meados dos anos 1990 marcou um ponto de viragem com o advento da Service Oriented Architecture (SOA), que ganhou destaque no início dos anos 2000 através de implementações baseadas em SOAP. A SOA revolucionou o design de software ao permitir serviços fracamente acoplados. A evolução continuou na década de 2010 com REST, arquiteturas orientadas a eventos (EDA) e microserviços, mas permanece um desafio persistente: determinar o tamanho e o âmbito ideais de um serviço.\n\nHistoricamente, a SOA definiu dois tipos principais de granularidade de serviço: coarse-grained e fine-grained. Serviços coarse-grained abrangem amplas capacidades de negócio, enquanto serviços fine-grained focam-se em funções de âmbito restrito. Ambos os extremos apresentam desafios; serviços coarse-grained grandes correm o risco de se tornarem "monólitos" difíceis de gerir, enquanto serviços fine-grained podem gerar um número excessivo de componentes pequenos e interdependentes, complicando a escalabilidade, modificabilidade e segurança. O Service-Oriented Modeling Framework (SOMF) oferece categorias mais nuançadas: serviços atómicos são componentes básicos e indivisíveis com processos limitados; serviços compostos agregam serviços atómicos ou outros compostos em estruturas hierárquicas; e clusters são grupos de serviços relacionados que colaboram para soluções mais amplas.\n\nTraduzir estes conceitos para o domínio da computação serverless com Serverless Framework e AWS Lambda envolve compreender três construtos centrais: Eventos, Funções e Serviços. Eventos disparam funções, que executam pedaços discretos de código realizando tarefas específicas. Serviços encapsulam grupos de funções Lambda juntamente com os seus eventos de disparo e requisitos de infraestrutura. O Serverless Framework normalmente recomenda criar funções Lambda individuais para cada operação CRUD — implicando que uma entidade como Utilizador poderia corresponder a quatro funções Lambda. Embora simples, esta abordagem escala mal: dez entidades conduzem a 40 funções, cada uma requerendo gestão e associada a instâncias separadas do AWS API Gateway, aumentando a sobrecarga operacional.\n\nPara abordar esta complexidade, propõe-se o padrão Function as a Microservice (FaaM). Aqui, cada função Lambda atua como um pequeno cluster, gerindo múltiplas capacidades de negócio relacionadas e encaminhando internamente vários eventos atómicos. Por exemplo, em vez de uma função por operação de cidade, uma função de geolocalização gere operações CRUD para países, cidades e regiões coletivamente. Para evitar o crescimento monolítico, cada função deve idealmente gerir não mais do que 7±2 entidades, em linha com os limites cognitivos descritos pela Lei de Miller. Este design assume que cada função mantém responsabilidade exclusiva pela sua fonte de dados específica.\n\nImplementar o FaaM dentro do AWS Lambda requer mecanismos eficientes de encaminhamento, dado que cada função Lambda tem um único handler de entrada. Um padrão Cliente-Despachante-Servidor pode facilitar isto ao direcionar pedidos recebidos com base nos seus caminhos URI. Por exemplo, um pedido HTTP para /movie deve ser encaminhado para a função relevante que gere operações relacionadas com filmes. Usando este padrão, múltiplos serviços lógicos — como utilizadores, geolocalização e publicações — podem partilhar o mesmo código handler mas diferenciar o processamento internamente através do encaminhamento. Esta abordagem reduz o número de funções Lambda e endpoints do API Gateway, simplificando a gestão enquanto preserva limites claros do domínio de negócio.\n\nNa prática, a configuração do Serverless Framework pode definir vários serviços com múltiplos eventos HTTP todos apontando para o mesmo handler — por exemplo, endpoints de login, logout e registo sob utilizadores, vários endpoints de localização sob geolocalização, e operações CRUD para filmes sob publicações. A lógica de encaminhamento dentro do handler partilhado inspeciona o URI e o método do evento para invocar o módulo de lógica de negócio apropriado. Esta estratégia melhora a manutenibilidade ao evitar código handler repetitivo e permite crescimento modular dentro de arquiteturas serverless.
