Serverless Development and Deployment - How does it actually work with CDK?

👉 You don’t know what serverless is? Then you can find everything you need to know about Serverless here.

Today we want to take a closer look at the development process in the area of serverless, local development and the deployment process. The goal is to develop and deploy a serverless application on AWS hands-on.

The idea

We would like to look at and try out different IaC (Infrastructure-as-Code) provisioning tools to build, develop and deploy small serverless applications as an example.

How to start?

In Raffi’s TechUp on Serverless Patterns, we have already learned about different blueprints that help us get started in the serverless world. Before we jump into the serverless world, however, we have to make some decisions.

Which Infrastructure-as-Code (IaC) tool do we want to use? Basically, Serverless Land offers us the following IaC tools for provisioning serverless components:

• AWS Cloud Development Kit (CDK): The AWS Cloud Development Kit is an open source software development framework from AWS that helps developers write and deploy IaC in various programming languages.
• AWS Serverless Application Model (SAM): The AWS Serverless Application Model (SAM) is a framework for developing serverless applications on AWS that is based on AWS CloudFormation and uses a simplified syntax to define and deploy serverless resources.
• Serverless Framework: The Serverless Framework is an open source development framework for building serverless applications on various cloud platforms such as AWS, Azure and Google Cloud Platform. It provides a simplified way to define and deploy Serverless functions, APIs and other resources.
• Terraform: Terraform is an open source tool from HashiCorp that allows developers to write and manage IaC. It supports various cloud platforms such as AWS, Azure and Google Cloud Platform as well as on-premises environments and provides a declarative language for infrastructure definition.
• Pulumi: Pulumi is an open source tool that helps developers write and deploy IaC in various programming languages. Unlike other IaC tools, Pulumi uses an imperative language that gives developers more flexibility to create and manage infrastructure.

AWS Cloud Development Kit (CDK).

AWS CDK is an open source framework that allows developers to write and deploy infrastructure as-code. Below are some of the key features of AWS CDK:

• Supports a variety of programming languages such as TypeScript, Python, Java, C# and Go.
• Allows infrastructure to be defined at a higher level of abstraction by providing constructs such as AWS Lambda, Amazon S3, Amazon DynamoDB, Amazon API Gateway and many others.
• Enables the creation of AWS Cloudformation Templates that are automatically generated and updated when the infrastructure is changed.
• Provides the ability to create and manage Stacks, which are aggregations of AWS resources that are grouped together for a specific purpose.
• Provides a library of reusable and customisable constructs that developers can use to create their own stacks.
• Allows developers to use a local development environment to test their IaC before deploying it to the cloud.
• Supports integration with CI/CD tools to automate the deployment of IaC.

With these features, AWS CDK provides a flexible and effective way for developers to define and deploy their AWS infrastructure, reducing development, testing and deployment time and simplifying infrastructure management.

Hands-On

Objective: A Rest API is to write something to a DynamoDB via API Gateway & Lambda Function. Serverless Land Pattern: API Gateway REST API to Lambda to DynamoDB IaC Tool: AWS Cloud Development Kit (CDK) Language: Golang AWS Services: API Gateway, Lambda, DynamoDB

Setup

At the beginning we install CDK via NPM.

1
2

npm install -g aws-cdk
cdk --version

Then we need to deploy certain CDK resources to make our AWS account ready for CDK, this process is called bootstrapping.

1

cdk bootstrap

According to the AWS documentation, the following resources are now created:

• Amazon S3 Bucket
• AWS KMS Key
• IAM roles
• Amazon ECR repository
• SSM Parameters for Versioning

Without the boostrapping we would get stuck and get the following error:

Development

At this point we encounter the first big question mark! If you use the quickstart commands from Serverless Land 1:1, you end up in a DotNet project. We don’t want that, so let’s start from the beginning!

First we want to clone the repository of Serverless Land and look at the Go variant.

1
2
3

git clone https://github.com/aws-samples/serverless-patterns/ 
cd serverless-patterns/apigw-lambda-dynamodb-cdk-go
code .

Immediately two folders are visible, cdk and function which both contain a main.go. Which one is our programme then? Why are there two main.go files?

CDK uses programming languages like GoLang to create the resources via IaC in the cloud. These are always located in the CDK folder. Instructions on how to deploy the CDK subproject and other configurations can be found in the file cdk/cdk.json.

Local Development

Of course, we could simply start the function/main.go file, but unfortunately this takes a context and an APIGatewayProxyRequest as input parameters. Unfortunately, CDK does not offer a practical solution to generate this input parameter. A Test-Driven-Development approach would be useful here to develop the function and test it locally.

Deployment

First we need to build our Go function, this is done via go build.

1
2

cd function
GOOS=linux go build -o my-func main.go && zip function.zip my-func

Note here that we have to tell Go that we want to build for Linux, since our lambda function runs on Linux. Then we see the function-zip which contains the code for our lambda function. Now we can deploy the CDK project.

1
2

cd ../cdk
cdk deploy

In the output we get directly the relevant URL of our API gateway, we copy this immediately and set it as environment variable.

1

export APIGW_REST_ENDPOINT=https://<api-id>.execute-api.<region>.amazonaws.com/prod/

If we run cdk deploy again, CDK automatically detects that there are no changes, handy!

Other useful commands with CDK are:

• cdk diff: Compares the current state of the infrastructure with the previously deployed state and prints the differences.
• cdk synth: Generates the CloudFormation template used by AWS CDK to provision the infrastructure.
• cdk ls: Lists all stacks that exist in the application.
• cdk init: Creates a new AWS CDK project with the selected programming language and template.
• cdk doctor: Checks if the AWS CDK setup is working properly on the system and gives troubleshooting suggestions.

Testing

Via AWS console we can see that an API gateway, a Lambda Function and a DynamoDB table have been created.

First, let’s create two users as an example:

1
2
3

curl -i -X POST -d '{"email": "tom.trapp@b-nova.com", "username": "ttrapp"}' $APIGW_REST_ENDPOINT

curl -i -X POST -d '{"email": "hello@b-nova.com", "username": "hello"}' $APIGW_REST_ENDPOINT

Disillusionment again, both calls return a 502 internal server error. What happened? As with CloudWatch, we quickly see the following error in our ServerlessCDK stack:

1
2
3
4
5
6
7

2023-05-01T15:27:57.236+02:00 START RequestId: e29bb8c1-a4ac-4b75-9776-43608219c867 Version: $LATEST

2023-05-01T15:27:57.236+02:00 fork/exec /var/task/my-func: exec format error: PathError null

2023-05-01T15:27:57.294+02:00 END RequestId: e29bb8c1-a4ac-4b75-9776-43608219c867

2023-05-01T15:27:57.294+02:00 REPORT RequestId: e29bb8c1-a4ac-4b75-9776-43608219c867 Duration: 58.21 ms Billed Duration: 59 ms Memory Size: 128 MB Max Memory Used: 20 MB

Unfortunately, our serverless land pattern has once again manoeuvred us into a rift here. We have to set our GOOS as well as our GOARCH. This is necessary because we are working on an aarch64 Apple M1 architecture. But we need to set the target architecture to amd64 because our Lambda function runs on an Intel architecture. Now build and deploy again.

1
2
3
4

$ cd ../function
$ GOOS=linux GOARCH=amd64 go build -o my-func main.go && zip function.zip my-func
$ cd ../cdk
$ cdk deploy

After that, our curl commands work too, yay! 🎉

Now we see that our entries have been correctly created in DynamoDB:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

$ aws dynamodb scan --table-name users-table

---
{
    "items": [
        {
            "email": {
                "S": [ { "hello@b-nova.com" ]
            },
            "user_name": {
                "S": "hello"
            }
        },
        {
            "email": {
                "S": "tom.trapp@b-nova.com"
            },
            "user_name": {
                "S": "ttrapp"
            }
        }
    ],
    "count": 2,
    "ScannedCount": 2,
    }, "ConsumedCapacity": null
}
(END]

And with this we have deployed our first small serverless application! Of course, this is a simple example, we were able to get to know CDK a bit and deployed a small Go function.

Cleanup

To delete all resources again, we can execute the following command:

1

$ cdk destroy

TLDR

After SAM, CDK is the second most used IaC tool on Serverless Land with over 210 patterns.

Advantages

• No need to learn a new language, infrastructure components are simply created via e.g. Golang
• Clear project structure
• High customizability, since theoretically you can develop anything in Go
• Supports various programming languages
• Offers an object-oriented API for defining infrastructure
• Integrates seamlessly with other AWS services

Disadvantage

• No declarative approach, but imperative programming
• Outdated dependencies, GoLang version, again a go.mod in own responsibility
• Serverless Land Pattern outdated and thus no longer usable 1:1
• Not testable locally

Now that we’ve learned about the first IaC tool in our Serverless series, we’ll look at the AWS Serverless Application Model (SAM) in the next blogpost of the series. Stay Tuned! 🚀

Translated by our automatic markdown translator! 🙌