SAM and SAR

SAM has two major components: SAM template and SAM CLI.

SAM template

SAM template provides short-hand syntax to define the resources and event source mappings. It is built on top of CloudFormation.

We define the SAM template in template.yml file. It typically has the following sections:

• Transform (required): This section is used to identify a CloudFormation template as a SAM template.

• Globals (optional): This section defines the properties common to serverless tables, APIs, and functions. Properties or configuration settings defined in globals are inherited by multiple resources. It’s helpful in avoiding repetition in SAM templates.

• Parameters (optional): This section is used to pass values to the template during stack creation or modification. We can use these values to customize the resources at runtime. It’s similar in functionality and structure to the Parameters section in CloudFormation. Parameters defined in the SAM template are overridden by the parameters described with the --parameter-overrides flag in the sam deploy command. We’ll learn more about sam deploy in the next task.

• Resources (required): This section is the main part of the SAM template. Like the CloudFormation template, it defines the resources to be set up using the template. SAM template supports a variety of serverless resources offered by AWS. However, we can define other resources using the CloudFormation template within the SAM template. We’ll explore this property in the upcoming tasks.

• Outputs (optional): This section allows us to return the desired values related to the stack. The returned values are listed under properties. It’s similar in functionality to the Outputs section in CloudFormation.

Let's see the SAM template used to deploy a Lambda function:

Notice the Transform on line 2. When we deploy this template on a stack, this line indicates the CloudFormation to transform and expand the serverless resources to Cloud formation equivalent. This enables us to add a cloud formation template to our SAM file. Thus, we can create non-serverless resources such as IAM roles, IAM policies, buckets, and more.

SAM offers templates for nine types of serverless resources, including Lambda function, DynamoDB table, APIs, and more. Besides these resources, we can use the CloudFormation template to define other resources in the same template. In addition, we can configure 16 types of event sources and include 75+ prebuilt IAM policies for common use cases.

SAM CLI

The AWS SAM CLI is a command-line tool that provides a set of commands for developing, testing, and deploying serverless applications defined by AWS SAM templates. It enhances the development workflow for serverless applications by offering local testing capabilities, debugging features, and simplified deployment commands.

The SAM CLI commands can be broadly divided into development and management commands. These commands are used to test, package, deploy, secure, and monitor the serverless applications in a few commands.

Update and package the application

While creating serverless applications, we may reiterate the template code to add new resources or update the configuration for existing ones. It can get difficult and time-consuming to deploy and package changes iteratively. However, commands such as accelerate, package, build, and deploy allow us to rapidly build and update resources.

Testing and debugging the application

To confirm that a developed serverless application serves the desired service, it is necessary to perform unit and functional testing. Testing serverless architectures can be difficult as it requires events to invoke the integrated services. SAM CLI simplifies this task by providing local and validate commands. These commands enable developers to test the application locally on docker containers before deploying them over the cloud. Some commonly used commands are:

• sam local start-api: This command allows us to test and debug your serverless APIs locally by emulating API Gateway.

• sam local invoke: This command invokes the Lambda function, emulating a service emitting an event and the Lambda function reacting to it.

• sam local generate-event: This command generates a JSON formatted sample event payload for testing AWS Lambda functions locally.

Monitoring the application

All serverless resources can publish their action in Amazon CloudWatch. We can use these insights to generate alarms. SAM allows us to generate application insights of the serverless application using sam init --application-insights.

The AWS Serverless Application Model (SAM) CLI and template provide a powerful and streamlined approach to developing, testing, and deploying serverless applications on the AWS cloud. The SAM CLI offers a local development environment, enabling developers to simulate AWS Lambda functions, API Gateway, and other resources on their machines. The SAM template, defined in YAML, serves as a declarative and version-controlled blueprint for describing the architecture of serverless applications.

Serverless Application Repository

The Serverless Application Repository (SAR) is a managed repository provided by AWS where you can find and deploy serverless applications published by the community and AWS partners. It allows developers to share and discover reusable serverless components and applications, making it easier to get started with building serverless architectures.

The SAR allows us to use a serverless application within another application called Nested Structures. This architectural approach allows developers to create modular and reusable components, fostering a more efficient and organized application development process. We can work with SAR in two ways:

Publish applications

We can share our applications with the public through a straightforward four-step process:

1. Begin by initializing your project. Download a sample application template using sam init.

2. Conduct local testing of the application using commands like sam local invoke and/or sam local start-api. Keep in mind that, even in local invocation, your Lambda function interacts with AWS resources in the AWS Cloud.

3. Once satisfied with the local testing, package the Lambda function, AWS SAM template, and dependencies into an AWS CloudFormation deployment package using sam package. This step also includes information for the application that will be uploaded to the AWS Serverless Application Repository.

4. Publish the application to the AWS Serverless Application Repository with the command sam publish. Upon completion, you can view your application in the AWS Serverless Application Repository and deploy it to the AWS Cloud using the AWS Serverless Application Repository.

Deploy applications

We can browse through the publically available applications on the official AWS site. We can deploy any application by following the steps:

1. Browse and search for the application that suits the requirements using keywords. Make sure you have permission to deploy applications as per the visibility type of the applications. Also, ensure the application does not contain a nested application that is not publicly accessible.

2. Check for the IAM permissions in the SAM template to avoid creating resources in the account with escalated permissions.

3. Configure the settings of the application. For example, configuration specifications could involve indicating the name of a resource that the application needs access to. This resource could be an Amazon DynamoDB table, an Amazon S3 bucket, or an Amazon API Gateway API. Deploy the application.

Benefits of using SAR

Here are some benefits of using SAR:

• Reusability: SAR allows developers to share and discover pre-built, serverless applications, promoting the creation of reusable components that can be easily integrated into new projects. This, in turn accelerates the development of applications.

• Versioning and updates: Applications in SAR support versioning, allowing developers to publish updates and improvements. Users can choose specific versions during deployment, ensuring stability and compatibility with their existing setups.

• Cross-account deployment: SAR supports the deployment of applications across multiple AWS accounts. This feature is valuable for organizations managing applications in different environments or for sharing applications across teams.

• Integrated with AWS CloudFormation: SAR seamlessly integrates with AWS CloudFormation, enabling users to deploy applications using CloudFormation stacks. This integration ensures a streamlined and managed life cycle for serverless applications.

These benefits collectively make AWS SAR a valuable resource for developers seeking to efficiently build, share, and discover serverless applications.

Best practices

Here are some best practices for using SAM and SAR:

• Use nested applications: To avoid reinventing the wheel and wasting effort, it is best to use nested applications. It helps avoid conflict and speeds up the development of commonly used patterns in serverless architectures.

• Modular design: Structure your SAM templates in a modular way, promoting reusability and maintainability. Break down complex applications into smaller, manageable components.

• Use globals: Using globals in our application ensures consistency and avoids replicated lines in the template. For example, while configuring multiple Lambda functions, repeating a similar configuration in the template file would be redundant.

• Utilize policy templates: AWS offers around 75+ policy templates that include commonly required permissions, for example, performing CRUD operations on a DynamoDB table. We can utilize these policies to secure the applications through two simple lines in the SAM template.

These best practices aim to enhance serverless application development, deployment, and maintenance using AWS SAM and SAR.