Ainda que arquiteturas sem servidor possam ser extremamente úteis para resolver alguns problemas, elas vêm com um certo nível de complexidade, especialmente quando envolvem execução e fluxos de dados em vários Lambdas interdependentes — às vezes, isso pode resultar em uma arquitetura Lambda pinball. Nossas equipes relataram que manter e testar arquiteturas estilo Lambda pinball pode ser muito desafiador: entender a infraestrutura, implantação, diagnóstico e depuração pode se tornar difícil. A nível do código, o mapeamento simples entre os conceitos de domínio e os vários Lambdas envolvidos é praticamente impossível, tornando desafiadoras quaisquer alterações e adições. Embora acreditemos que ambientes sem servidor são a estrutura correta para alguns problemas e domínios, eles não são uma "bala de prata" para todos os problemas, e é por isso que você deve tentar evitar Lambda pinball. Um padrão que pode ajudar é fazer uma distinção entre interfaces públicas e publicadas, e aplicar delimitação de domínio, com interfaces publicadas entre eles.
Temos construído arquiteturas sem servidor em nossos projetos há alguns anos, e percebemos que é bem fácil cair na armadilha de construir um monolito distribuído. As arquiteturas Lambda pinball caracteristicamente perdem de vista importantes lógicas de domínio na rede emaranhada de lambdas, buckets e filas à medida que os requisitos oscilam em gráficos cada vez mais complexos de serviços de nuvem. Normalmente, eles são difíceis de testar como unidades, e a aplicação precisa ser testada como um todo integrado. Um padrão que podemos usar para evitar essas arquiteturas pinball é fazer uma distinção entre interfaces públicas e publicadas e aplicar os bons e velhos limites de domínio com interfaces publicadas entre eles.
