Hands-on AWS Serverless Application Model

This topic contains 0 replies, has 1 voice, and was last updated by touseef ahmad touseef ahmad 1 year, 5 months ago.

Viewing 1 post (of 1 total)
  • Author
    Posts
  • #100034386
    touseef ahmad
    touseef ahmad
    Participant

    Digging a little deeper into these new tools, I found one that I have been waiting for: AWS Serverless Application Model, or AWS SAM, previously known as Project Flourish.
    In the past, I’ve worked with similar tools or frameworks to have my infrastructures as code and, of course, versioned. Serverless Framework, Apex, Terraform, and Chalice are just a few of the ones I’ve tried, and I found them all useful for simplifying the creation, deployment, and management of AWS Lambdas and other resources like API Gateway, DynamoDB, etc.
    Let’s talk a little more about the AWS Serverless Application Model and then we can dive into an example of how to use it.
    What is the AWS Serverless Application Model?
    The AWS Serverless Application Model allows you to describe or define your serverless applications, including resources, in an easier way, using AWS CloudFormation syntax. In other words, AWS SAM is a CloudFormation extension optimized for serverless applications. It supports anything that CloudFormation supports. You can use YAML or JSON syntax to write your templates.
    Clear enough? Maybe not. To understand it better, let’s look at a very simple example.
    AWS SAM: Hello World
    Let’s start with the first well-known application: Hello World.
    I will use an existing blueprint that the AWS Lambda console provides: lambda-canary.
    Follow these steps to download the blueprint:
    • Open your AWS Lambda Console.
    • Click on Create a Lambda Function.
    • Select “Python 2.7” in the “Select runtime” list.
    • Click the little icon located on the bottom right. This will open an “Export blueprint” dialog box:

    • Click on “Download blueprint” button.
    You will have now a lambda-canary.zip with 2 files inside:
    • lambda_function.py
    • template.yaml
    Unzip it in a directory somewhere in your computer, and let’s examine each one.
    The first one is a simple Lambda function that will check for a string within a site. Go ahead and take a look at it. You will find another interesting and new feature in AWS Lambda: Environment Variables. In Python we use environment variables by importing first the “os” package and then using them in the following way:

    1
    2
    3
    4 import os

    SITE = os.environ[‘site’]
    EXPECTED = os.environ[‘expected’]
    This is very useful when we have different environments like development, testing, production, etc. We won’t discuss them in depth right now, but you can check it out here: AWS Lambda Supports Environment Variables.
    The second one is our blueprint or template, and this is where things get interesting:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24 AWSTemplateFormatVersion: ‘2010-09-09’
    Transform: ‘AWS::Serverless-2016-10-31’
    Description: ‘Performs a periodic check of the given site, erroring out on test failure.’
    Resources:
    lambdacanary:
    Type: ‘AWS::Serverless::Function’
    Properties:
    Handler: lambda_function.lambda_handler
    Runtime: python2.7
    CodeUri: .
    Description: >-
    Performs a periodic check of the given site, erroring out on test
    failure.
    MemorySize: 128
    Timeout: 10
    Events:
    Schedule1:
    Type: Schedule
    Properties:
    Schedule: rate(1 minute)
    Environment:
    Variables:
    site: ‘https://www.amazon.com/’
    expected: Online Shopping
    As you can see, the syntax is pretty much the CloudFormation syntax that we already know, but with a slight difference:
    Transform: ‘AWS::Serverless-2016-10-31’
    This line is used to include resources defined by AWS SAM inside a CloudFormation template.
    Note also the part where the properties of our Lambda function are:
    • Handler: This is the method that will be called when our Lambda function runs.
    • Runtime: The programming language in which our Lambda function is written.
    • Description: A brief text that describes what our function does.
    • MemorySize: How much memory our function will use.
    • Events: This describes what will trigger our function. In this case, we have a CloudWatch Scheduled event, and it will run every minute.
    • Environment: The environment variables that our function will use.
    • Timeout: The time required for the function to finish and mark it as failed.
    • CodeUri: Where our Lambda function and libraries are located… wait, a dot?
    Wait, what is that dot in CodeUri?! For now, let’s keep it that way. (We’ll come back to this later in the post.)
    So, now that we have our blueprint and our Lambda function, what’s next?
    AWS Serverless Application Model: Package and Deploy
    The first thing to do is to create a package. This package will be uploaded to an Amazon S3 bucket, and from there we are going to deploy it.
    But before going further in our guide, let’s make a little change in our template:
    • Open the template.yaml file with your favorite text editor.
    • Go to line 24, where the ‘expected’ environment variable is, and change the value from ‘Online Shopping’ to ‘About Amazon’.
    We have to make that change because the ‘Online Shopping’ string does not appear anywhere on ‘https://www.amazon.com’. Therefore, our check is going to fail every time.
    You can change the site and the expected string to your own website if you’d like.
    Now, we can continue…
    You have the AWS CLI already installed, right? No? Ok, no worries. Let’s do it right now. Go to AWS Command Line Interface, and follow the instructions for installing it.
    Or follow these easy steps:
    If you haven’t done it yet, you need to generate your Access key ID and Secret access key from the Identity and Access Management Console. Download them and store them in a safe place.
    If you are using Linux, you can run the following command to have the AWS CLI ready for action (you need Python Pip installed first though):

    1 pip install awscli
    Or, if you are using MacOS, you have the alternative to install the CLI via Homebrew:

    1 brew install awscli
    If you use Windows, you have to download the 64-bit or the 32-bit installer.
    Finally, run the following command to configure the AWS CLI:

    1 aws configure
    You will be asked for:

    1
    2
    3
    4 AWS Access Key ID [None]:
    AWS Secret Access Key [None]:
    Default region name [None]:
    Default output format [None]:
    Please fill each field with the correct values.
    Now we are ready to package and deploy!
    Let’s do this!

    1
    2
    3
    4 aws cloudformation package \
    –template-file template.yaml \
    –output-template-file output.yaml \
    –s3-bucket example-bucket
    We just created a new CloudFormation template, output.yaml, with the URI of our code to have it ready for deployment. This is actually the only difference between our original template and the one generated by the package command.
    The output will be something like this:

    1
    2
    3
    4 Uploading to cdaf78f67aefd46edeac3ceae77124ed 349733 / 349733.0 (100.00%)
    Successfully packaged artifacts and wrote output template to file output.yaml.
    Execute the following command to deploy the packaged template
    aws cloudformation deploy –template-file /Users/gsantovena/Projects/SAM/output.yaml –stack-name
    This is very useful when we are implementing continuous integration and continuous delivery. The package command will zip our code, upload it to S3, and add the correct CodeUri property to the output template. This is why the CodeUri is empty, or is set to a dot, in our original template. Each time we run the packagecommand, it will generate a different ID for our package and will fill the CodeUri field with the correct address. In this way, we can deploy new versions of our Lambda function or roll back to a previous version. Go ahead and open the AWS S3 console and see it with your own eyes.
    Now, we are ready to deploy it. Run the following command:

    1
    2
    3
    4 aws cloudformation deploy \
    –template-file output.yaml \
    –stack-name MyHTTPMonitor \
    –capabilities CAPABILITY_IAM
    The output will be something like this:

    1
    2
    3 Waiting for changeset to be created..
    Waiting for stack create/update to complete
    Successfully created/updated stack – MyHTTPMonitor
    This command will create or update a stack named MyHTTPMonitor with our serverless application based on the template we just created.
    Let’s check our AWS CloudFormation console:

    Also, take a look at the Template tab of our stack. You will see two new things:
    • View original template
    • View processed template
    The first one is obvious, it is our original template, the one we deployed. So, no changes here.
    The second one is the template that was created by transforming our original template, by explicitly adding all of the resources needed for our function to work properly.

Viewing 1 post (of 1 total)

You must be logged in to reply to this topic.

Translate »