Cloud applications are built using multiple components, such as virtual servers, containers, serverless functions, storage buckets, and databases. Being able to provision and configure these resources in a safe, repeatable way is incredibly important to automate your processes and let you focus on the unique parts of your implementation.
With the AWS Cloud Development Kit, you can leverage the expressive power of your favorite programming languages to model your applications. You can use high-level components called constructs, preconfigured with “sensible defaults” that you can customize, to quickly build a new application. The CDK provisions your resources using AWS CloudFormation to get all the benefits of managing your infrastructure as code. One of the reasons I like the CDK, is that you can compose and share your own custom components as higher-level constructs.
As you can imagine, there are recurring patterns that can be useful to more than one customer. For this reason, today we are launching the AWS Solutions Constructs, an open source extension library for the CDK that provides well-architected patterns to help you build your unique solutions. CDK constructs mostly cover single services. AWS Solutions Constructs provide multi-service patterns that combine two or more CDK resources, and implement best practices such as logging and encryption.
Using AWS Solutions Constructs
To see the power of a pattern-based approach, let’s take a look at how that works when building a new application. As an example, I want to build an HTTP API to store data in a Amazon DynamoDB table. To keep the content of the table small, I can use DynamoDB Time to Live (TTL) to expire items after a few days. After the TTL expires, data is deleted from the table and sent, via DynamoDB Streams, to a AWS Lambda function to archive the expired data on Amazon Simple Storage Service (S3).
To build this application, I can use a few components:
Can I make it simpler? Looking at the available patterns in the AWS Solutions Constructs, I find two that can help me build my app:
To build the final architecture, I simply connect those two Constructs together:
I am using TypeScript to define the CDK stack, and Node.js for the Lambda functions. Let’s start with the CDK stack:
At the beginning of the stack, I import the standard CDK constructs for the Lambda function, the API Gateway endpoint, and the DynamoDB table. Then, I add the two patterns from the AWS Solutions Constructs, ApiGatewayToLambda
and DynamoDBStreamToLambda
.
After declaring the two ApiGatewayToLambda
and DynamoDBStreamToLambda
constructs, I store the Lambda function, created by the ApiGatewayToLambda
constructs, and the DynamoDB table, created by DynamoDBStreamToLambda
, in two variables.
At the end of the stack, I “connect” the two patterns together by granting permissions to the Lambda function to read/write in the DynamoDB table, and add the name of the DynamoDB table to the environment of the Lambda function, so that it can be used in the function code to store data in the table.
The code of the two Lambda functions is in the lambda
folder of the CDK application. I am using the Node.js 12 runtime.
The restApi.js
function implements the API and writes data to the DynamoDB table. The URL path is used as partition key, all the query string parameters in the URL are stored as attributes. The TTL for the item is computed adding a time window of 7 days to the current time.
const { DynamoDB } = require("aws-sdk");
const docClient = new DynamoDB.DocumentClient();
const TABLE_NAME = process.env.TABLE_NAME;
const TTL_WINDOW = 7 * 24 * 60 * 60; // 7 days expressed in seconds
exports.handler = async function (event) {
const item = event.queryStringParameters;
item.id = event.pathParameters.proxy;
const now = new Date();
item.ttl = Math.round(now.getTime() / 1000) + TTL_WINDOW;
const response = await docClient.put({
TableName: TABLE_NAME,
Item: item
}).promise();
let statusCode = 204;
if (response.err != null) {
console.error('request: ', JSON.stringify(event, undefined, 2));
console.error('error: ', response.err);
statusCode = 500
}
return {
statusCode: statusCode
};
};
The processStream.js
function is processing data capture records from the DynamoDB Stream, looking for the items deleted by TTL. The archive functionality is not implemented in this sample code.
exports.handler = async function (event) {
event.Records.forEach((record) => {
console.log('Stream record: ', JSON.stringify(record, null, 2));
if (record.userIdentity.type == "Service" &&
record.userIdentity.principalId == "dynamodb.amazonaws.com") {
// Record deleted by DynamoDB Time to Live (TTL)
// I can archive the record to S3, for example using Kinesis Data Firehose.
}
}
};
Let’s see if this works! First, I need to install all dependencies. To simplify dependencies, each release of AWS Solutions Constructs is linked to the corresponding version of the CDK. I this case, I am using version 1.46.0 for both the CDK and the AWS Solutions Constructs patterns. The first three commands are installing plain CDK constructs. The last two commands are installing the AWS Solutions Constructs patterns I am using for this application.
Now, I build the application and use the CDK to deploy the application.
Towards the end of the output of the cdk deploy
command, a green light is telling me that the deployment of the stack is completed. Just next, in the Outputs
, I find the endpoint of the API Gateway.
I can now use curl to test the API:
Let’s have a look at the DynamoDB table:
The item is stored, and the TTL is set. After a week, the item will be deleted and sent via DynamoDB Streams to the processStream.js
function.
After I complete my testing, I use the CDK again to quickly delete all resources created for this application:
Available Now
The AWS Solutions Constructs are available now for TypeScript and Python. The AWS Solutions Builders team is working to make these constructs also available when using Java and C# with the CDK, stay tuned. There is no cost in using the AWS Solutions Constructs, or the CDK, you only pay for the resources created when deploying the stack.
In this first release, 25 patterns are included, covering lots of different use cases. Which new patterns and features should we focus now? Give use your feedback in the open source project repository!
— Danilo
Source: AWS News