Não é mágica, apenas execução minuciosa!

Nesta semana, a AWS forneceu um aplicativo de código aberto que não parece, à primeira vista, muito útil: é uma implementação simplificada do serviço de Repositório de Aplicativos Serverless, efetivamente um site estático com um back-end CRUD. Provavelmente não é algo que você deseja implementar em seu ambiente. O aplicativo em si não é o ponto nesse caso, é claro, exceto que ele reflete um serviço em produção no mundo real e não um exemplo artificial. O valor real aqui é ver mais ou menos como a AWS estabelece o código e a configuração de um aplicativo serverless que eles implantam e operam na produção.

Você pode ler a postagem do blog e acessar o wiki do repositório para obter uma explicação detalhada de como tudo isso é organizado, e eu recomendo que você faça isso. Aqui, quero observar alguns elementos que se destacaram para mim.

Monorepo, com muitos componentes

Cada "componente" do aplicativo (back-end, front-end, pipeline de análise assíncrona, monitoramento) obtém sua própria subpasta, seu próprio modelo SAM, seu próprio CI/CD, seus próprios testes de unidade. Há também um modelo superior que aninha tudo abaixo dele. A vantagem dessa abordagem: MUITO controle sobre como você gerencia seus releases. Você pode realizar o deploy da pilha superior que irá imprimir todo a aplicação com todos os componentes na ordem correta, sem preocupações com dependências. Fazendo uma atualização de uma pilha individual, você avança rapidamente sem quebrar (muitas) coisas.

Uma interface CI/CD comum, mas "role" por componente

Você precisa procurar um pouco para encontrá-los, mas possivelmente os elementos mais úteis deste projeto não estão no repositório: eles foram publicados como aplicativos SAR separados para CI (um projeto CodeBuild para testes de unidade, integrando-se ao seu repositório no GitHub) e CD (um CodePipeline com estágios build -> test -> deploy). CI/CD plug-and-play? Sim por favor. A opção interessante aqui é manter as funções do IAM fora dos aplicativos SAR: em outras palavras, não há uma "role" de "CD" como administrador global com direitos absolutos. Ao invés disso, a AWS faz a escolha mais segura, mas muito mais trabalhosa, de passar uma função para cada componente que contém uma lista (geralmente bastante extensa) de permissões necessárias para implantar esse componente com êxito. Este é um lugar onde outras empresas acharão difícil seguir os passos da AWS.

Cada componente é seu próprio aplicativo SAR, não apenas uma pilha aninhada (nested stack)

O wiki do repositório contém um conjunto adorável e opinativo de práticas recomendadas do CloudFormation e é um ótimo argumento para o uso de pilhas aninhadas, algo de que também somos fãs no Trek10. Tecnicamente, porém, esse aplicativo não usa pilhas aninhadas do CloudFormation, mas aplicativos SAR aninhados. A mesma idéia, com o benefício adicional de publicar esses aplicativos internamente para uma maior descobertabilidade. Seu contexto pode variar se você acha que os componentes do seu aplicativo valem a pena publicar no SAR individualmente. Nesse caso, provavelmente é um exagero. Mas não podemos culpar a equipe do SAR por modelar o uso de seus próprios serviços!

Sem parâmetros na hora de deploy

O único parâmetro que você pode especificar no momento da implantação - além de um token do Github para CI/CD, que precisa ser propagado no Secrets Manager - é o descritor de estágio que cuida do namespace da sua pilha. Todo o resto é gerado dinamicamente (sem bucket S3 codificado ou nomes de tabela do DynamoDB aqui) ou compartilhado entre as pilhas aninhadas via SSM Parameter Store, como recentemente recomendado por Ryan Scott Brown, do Trek10. Isso se estende até às funções Lambda, que extraem seus parâmetros para SSM ao invés de usar variáveis ​​de ambiente.

Essa estratégia sem variáveis ​​de ambiente exige uma solução de cache na função para não sobrecarregar a taxa de transferência limitada do Parameter Store, e não tenho certeza se entendi como ela seria escalonada durante o um pico de tráfico. Tenho a sensação de que essa abordagem pode ter sido inspirada mais pelos tradeoffs de como variáveis ​​de ambiente Lambda não estão disponíveis em todas as regiões, e acho que para parâmetros não sensíveis você ainda deve considerar colocá-los em variáveis ​​de ambiente.

Qualquer configuração local de uma pilha, como o modelo de cobrança do DynamoDB, é codificada no template do SAM. Isso funciona bem, a menos que você espere que seu serviço use configurações diferentes em ambientes diferentes, o que me deixou desapontado por causa disso.

O CI/CD fornecido deixa de estar realmente pronto para produção

Todos os ingredientes estão aqui para um verdadeiro serviço de produção: há uma pilha de "operações" com algumas métricas e painéis do CloudWatch, temos pipelines para fazer o release do código... desde que você o mantenha no mesmo ambiente da AWS. Não há conceito de um pipeline de várias contas, promoção de código etc. Também fiquei desapontado ao ver que não há testes end-to-end como parte do pipeline. Tenho certeza de que essas coisas existem no serviço SAR real da AWS, mas evidentemente, é aí que eles precisam parar para criar algo de tamanho razoável de exemplo.

No geral: não é mágica, apenas execução minuciosa!

Realmente, não há nenhum molho secreto aqui. A AWS está fazendo todas as coisas que eles nos dizem para fazer há anos. O SAR provavelmente é usado em excesso sem nenhum objetivo óbvio (embora o aplicativo SAR "Deploy to S3" de Aleksandr Simovic seja útil para a parte estática do site), mas no geral é encorajador observar que Serverless não requer alguma fórmula mágica: a AWS usa o mesmos serviços da mesma maneira que seus clientes.

As partes difíceis, como sempre, estão nos detalhes: as permissões do IAM, a higiene dos parâmetros, a suavização do cold start. Esse repositório fornece um excelente plano para superar esses desafios, mas cabe a você executar.

Créditos

• Examining how AWS builds their own serverless apps, escrito originalmente por Forrest Brazeal.