Introdução ao modelo de aplicativo sem servidor da AWS

CloudFormation é um serviço da AWS para o provisionamento automático de recursos de infraestrutura da AWS. Um usuário define todos os recursos necessários em um blueprint (chamado modelo), e a AWS cuida do provisionamento e da configuração.

Os seguintes termos e conceitos são essenciais para entender o CloudFormation e o SAM:

A template is a description of an application, como deve ser estruturado em tempo de execução. Podemos definir um conjunto de recursos necessários, bem como a forma como esses recursos devem ser configurados. O CloudFormation fornece uma linguagem comum para definir modelos, suportando JSON e YAML como um formato.

Resources are the building blocks in CloudFormation. Um recurso pode ser qualquer coisa, como RestApi, Stage of a RestApi, Batch Job, tabela DynamoDB, instância EC2, interface de rede, função IAM e muito mais. The official documentation lista atualmente cerca de 300 tipos de recursos para CloudFormation.

A stack is the instantiation of a template. CloudFormation cuida do provisionamento e configuração da pilha.

Como tantas vezes, o uso de ferramentas poderosas pode se tornar muito complexo e impraticável, o que também é o caso do CloudFormation.

Por isso, a Amazon introduziu o SAM (Serverless Application Model). SAM started with the claim to provide a clean and straightforward syntax for defining serverless applications. Currently, it has only three resource types, which are Lambda functions, DynamoDB tables, and APIs.

O SAM é baseado na sintaxe do modelo CloudFormation, para que possamos definir nosso modelo usando a sintaxe simples do SAM, e o CloudFormation processará ainda mais esse modelo.

Mais detalhes estão disponíveisat the official GitHub repository, bem como emAWS documentation.

Primeiro, vamos dar uma olhada na estrutura geral do nosso modelo:

Como podemos ver, o modelo consiste em um cabeçalho e um corpo:

O cabeçalho especifica a versão do modelo CloudFormation (AWSTemplateFormatVersion), bem como a versão do nosso modelo SAM (Transform). Também podemos especificar umDescription.

O corpo consiste em um conjunto de recursos: cada recurso possui um nome, um recursoType e um conjunto deProperties.

A especificação SAM suporta atualmente três tipos:AWS::Serverless::Api,AWS::Serverless::Function, bem comoAWS::Serverless::SimpleTable.

Como queremos implantar nossoexample application, temos que definir umSimpleTable, doisFunctions, bem como umApi em nosso corpo-modelo.

Vamos definir nossa tabela DynamoDB agora:

Precisamos apenas definir duas propriedades para nossoSimpleTable: o nome da tabela, bem como uma chave primária, que é chamadaide tem o tipoNumber no nosso caso.

Uma lista completa de propriedadesSimpleTable suportadas pode ser encontradain the official specification.

Nota: Como só queremos acessar a tabela usando a chave primária, oAWS::Serverless::SimpleTable é suficiente para nós. Para requisitos mais complexos, o tipo de CloudFormation nativoAWS::DynamoDB::Table pode ser usado.

A seguir, vamos definir nossas duas funções:

Como podemos ver, cada função tem as mesmas propriedades:

Handler defines the logic of the function. Como estamos usando Java, é o nome da classe incluindo o pacote, em conexão com o nome do método.

Runtime defines how the function was implemented, que é Java 8 em nosso caso.

Timeout defines how long the execution of the code may take at most antes de AWS encerrar a execução.

MemorySizedefines the size of the assigned memory in MB. É importante saber que a AWS atribui recursos de CPU proporcionalmente aMemorySize. Portanto, no caso de uma função com uso intensivo de CPU, pode ser necessário aumentarMemorySize, mesmo se a função não precisar de tanta memória.

CodeUridefines the location of the function code. Atualmente faz referência à pasta de destino em nosso espaço de trabalho local. Quando carregamos nossa função posteriormente usando CloudFormation, obteremos um arquivo atualizado com uma referência a um objeto S3.

Policiescan hold a set of AWS-managed IAM policies or SAM-specific policy templates. Usamos as políticas específicas do SAMDynamoDBCrudPolicy paraStorePersonFunctioneDynamoDBReadPolicy paraGetPersonByPathParamFunctioneGetPersonByQueryParamFunction.

Environmentdefines environment properties at runtime. Usamos uma variável de ambiente para armazenar o nome de nossa tabela DynamoDB.

Eventscan hold a set of AWS events, which shall be able to trigger the function. Em nosso caso, definimos umEvent do tipoApi. A combinação única depath, um HTTPMethod e umRestApiId vincula a função a um método de nossa API, que definiremos na próxima seção.

Uma lista completa de propriedadesFunction suportadas pode ser encontradain the official specification.

Depois de definir a tabela e as funções do DynamoDB, agora podemos definir a API.

A primeira possibilidade é definir nossa API inline usando o formato Swagger:

NossoApi  tem três propriedades:StageNamedefine o estágio da API,EndpointConfiguration define se a API é regional ou otimizada por borda eDefinitionBody não contém a estrutura real da API.

EmDefinitionBody, definimos três parâmetros: a versãoswagger  como“2.0”, ainfo:title: como“TestAPI”, bem como um conjunto depaths .

Como podemos ver, opaths representa a estrutura da API, que tivemos que definir manualmentebefore. Ospaths no Swagger são equivalentes aos recursos no Console da AWS. Assim, cadapath pode ter um ou mais verbos HTTP, que são equivalentes aos métodos no console da AWS.

Cada método pode ter um ou mais parâmetros, bem como um validador de solicitação.

A parte mais interessante é o atributox-amazon-apigateway-integration, que é uma extensão específica da AWS para Swagger:

uri especifica qual função Lambda deve ser chamada.

responses especifica regras de como transformar as respostas retornadas pela função. Como estamos usando a Integração Lambda Proxy, não precisamos de nenhuma regra específica.

type define que queremos usar Integração Lambda Proxy e, portanto, temos que definirhttpMethod para“POST”, pois é isso que as funções Lambda esperam.

Uma lista completa de propriedadesApi suportadas pode ser encontradain the official specification.

Uma segunda opção é definir a API implicitamente nos recursos da função:

Como podemos ver, nosso modelo é um pouco diferente agora: Não há maisAWS::Serverless::Api resource.

No entanto, CloudFormation pega os atributosEvents do tipoApi como uma definição implícita e cria uma API de qualquer maneira. Assim que testarmos nosso aplicativo, veremos que ele se comporta da mesma forma que ao definir a API explicitamente usando Swagger.

Além disso, existe uma seçãoGlobals, onde podemos definir o nome de nossa API, bem como que nosso endpoint deve ser regional.

Apenas uma limitação ocorre: ao definir a API implicitamente, não podemos definir um nome de estágio. É por isso que a AWS criará um estágio chamadoProd em qualquer caso.

Em uma primeira etapa, precisamos fazer o upload do código da função para o S3.

Podemos fazer isso chamando CloudFormation por meio da CLI da AWS:

Com este comando, acionamos o CloudFormation para obter o código de função especificado emCodeUri:e carregá-lo para S3. O CloudFormation criará um arquivopackaged-template.yml, que tem o mesmo conteúdo, exceto queCodeUri: agora aponta para o objeto S3.

Vamos dar uma olhada na saída da CLI:

Agora, podemos acionar a implantação real:

Como nossa pilha também precisa de papéis IAM (como os papéis das funções para acessar nossa tabela do DynamoDB), devemos reconhecer explicitamente isso especificando–capabilities parameter.

E a saída da CLI deve se parecer com:

Após a implantação, podemos revisar o resultado:

O CloudFormation listará todos os recursos que fazem parte da nossa pilha.

Finalmente, podemos testar nosso aplicativo usando qualquer cliente HTTP.

Vamos ver alguns exemplos de comandoscURL que podemos usar para esses testes.

StorePersonFunction:

GetPersonByPathParamFunction:

GetPersonByQueryParamFunction:

No final, podemos limpar removendo a pilha e todos os recursos incluídos: