Serverless Framework is a fantastic tool for defining and managing your Lambda functions. But let's face it; it's not very good at handling other types of resources and infrastructure. CDK is though. This post will take a look at how we can combine the two!
Serverless has excellent utility for describing and managing Lambda functions, but as soon as you need basically any other type of infrastructure, you'll have to resort to raw CloudFormation. Using the CDK with its declarative and straightforward constructs to define infrastructure is more expressive and easy to understand once the infrastructure stack grows. What if we could use them together and utilize each of them for its respective strengths, and what it does best? Unfortunately, there's no native way to use the two tools together, like there is for SAM.
Let's look at how we can work around that and whether or not it makes sense!
TL;DR - give me the code!
🏗 Setting up the project
Let's start by initializing a Typescript Serverless app. To keep things simple, we'll use a Yeoman generator to get us started with a project. Install it with:
npm install -g yo generator-sls-node
and then, in an empty folder, run the generator with:
yo sls-node
Since we'll be using CDK to manage our infrastructure, we'll want to manage CDK, its dependencies, and transpiling the infrastructure code separately from our actual application. Therefore, let's create a folder called infrastructure
in the root of our project.
mkdir infrastructure
Next, navigate to the created folder and initialize a CDK project:
cd infrastructure
npx cdk init --language typescript
You should now have a project with the following structure:
- infrastructure # Our CDK infrastructure
↳ bin # CDK executable
↳ lib # infrastructure stack definition
↳ test # infrastructure tests
- src # application code
- tests # application tests
- serverless.yml # Serverless config
🔨 Building our app
The app we're building will contain a Lambda function, exposed in a HTTP API, which will put an item on an SQS queue for another Lambda to finally process the item.
Let's start by adding an SQS queue to our CDK stack. To do that, we need to first add the @aws-cdk/aws-sqs
package:
yarn add @aws-cdk/aws-sqs
I prefer Yarn over NPM, which is the default of the CDK init boilerplate. If you prefer to use Yarn too, remove the
package-lock.json
so you don't get conflicting lock files.
Then add a queue to infrastructure/lib/infrastructure-stack.ts
// infrastructure/lib/infrastructure-stack.ts
import * as cdk from '@aws-cdk/core';
import { Queue } from '@aws-cdk/aws-sqs';
export class InfrastructureStack extends cdk.Stack {
constructor(scope: cdk.Construct, id: string, props?: cdk.StackProps) {
super(scope, id, props);
const sqs = new Queue(this, 'SQS', {
queueName: 'sls-cdk-demo-queue'
});
}
}
As discussed earlier, we want to use Serverless and CDK for what they do best respectively. That means our API and Lambda functions will be defined in our serverless.yml
, seeing as Serverless handles those very capably and brings lots of functionality to interact with them once deployed. They're also the resources most likely to change often, meaning they don't really belong in our more long-living infrastructure stack.
For this simple demo use case, all we need to do to set up our API Gateway, Lambda function and to map the function to the /todo
path, is to add the following to our serverless.yml
, using the events
mapping:
# serverless.yml
...
functions:
createTodo:
handler: src/createTodo.handler
events:
- http:
path: /todos
method: post
For the createTodo
function to send anything to our SQS buffer, it's going to need the URL of the queue. It's also going to need the queue's ARN to set up the necessary sqs:SendMessage
IAM permission. However, since the SQS queue is not defined in the same CloudFormation stack as our Lambda function, we'll need to export those two properties from our CDK stack so that we can reference them in our Serverless stack.
Cross Stack References
CloudFormation stacks can export a set of properties, as "Outputs" which can then be referenced in other CloudFormation stacks. Conveniently, Serverless has built-in support to reference Outputs of other stacks, which means we can use this to easily transfer information from our CDK stack to our Serverless stack.
In the CDK stack, we start by creating our output variables:
// infrastructure/lib/infrastructure-stack.ts
...
new cdk.CfnOutput(this, 'queueUrl', {
value: sqs.queueUrl
});
new cdk.CfnOutput(this, 'queueArn', {
value: sqs.queueArn
});
Now, back in our serverless.yml
, we can reference those two variables with the ${cf:stackName.variableName}
syntax:
# serverless.yml
...
provider:
name: aws
region: eu-north-1
runtime: nodejs14.x
iam: # Set up IAM permission for sending messages to the queue
role:
statements:
- Effect: Allow
Action: sqs:SendMessage
Resource: ${cf:InfrastructureStack.queueArn}
functions:
createTodo:
handler: src/createTodo.handler
events:
- http:
path: /todos
method: post
environment: # Set environment variable with the queue URL
QUEUE_URL: ${cf:InfrastructureStack.queueUrl}
and while we're at it, lets also add the definition for our second Lambda, the queue processor, again by using the cross stack reference to the queue ARN:
# serverless.yml
...
functions:
createTodo:
...
queueProcessor:
handler: src/queueProcessor.handler
events:
- sqs:
arn: ${cf:InfrastructureStack.queueArn}
That should be all we need for the infrastructure, all that's left is writing the actual Lambda code.
Lambda Code
Our Lambda code is going to be very simple. The createTodo
handler, the one exposed in the API, will take the body
of the request and put it directly on the SQS queue. The queueProcessor
will then automatically consume the queue. Starting with the createTodo
function, add the following:
// src/createTodo.js
import { SQS } from 'aws-sdk';
export const handler = async (event) => {
const sqs = new SQS();
const payload = event.body || '';
await sqs
.sendMessage({
QueueUrl: process.env.QUEUE_URL,
MessageBody: payload,
})
.promise();
};
and then let's just pretend to do some processing of the item in the queueProcessor.js
:
// src/queueProcessor.js
export const handler = (event) => {
console.log('Doing some heavy processing right now. I promise! Don\'t come in!', event);
};
That's it, now all we need is to be able to deploy our app along with the infrastructure!
🚀 Deploying
Since our application will live in two separate CloudFormation stacks, we need to do two separate deployments. The Serverless stack will depend on our infrastructure stack, but never the other way around - meaning we should always deploy the infrastructure stack first.
To be able to deploy our app in one step, rather than manually first having to navigate to the infrastructure folder, deploy it, navigate back to the project root and then deploy our Serverless app, we can add a script to our root package.json
that does us for us in one swift motion:
// package.json
...
"scripts": {
"deploy": "cd infrastructure && yarn cdk deploy && cd .. && yarn sls deploy",
...
We can also add a CDK wrapper script that lets us easily run any CDK command without having to navigate to the infrastructure folder.
// package.json
...
"scripts": {
"cdk": "cd infrastructure && yarn cdk",
...
The cdk
script utilizes the fact that Yarn forwards arguments, and thus we can run, for example, yarn cdk diff
from the root of our app, even though CDK isn't actually in the root. Neat! 👵
What's even neater, though, is that we can now just run yarn deploy
. Since it's the first time we're deploying the app, it'll take a little longer than on subsequent deploys but after about half the time it takes refill your coffee, the app will be up and running! We can verify that it works by sending a POST
request to the API Gateway endpoint printed in the output, and by then looking at the logs of the final queueProcessor
lambda:
curl -X POST -H 'Content-type: application/json' --data '{"text":"Hello, World!"}' https://abcdefghij.execute-api.eu-north-1.amazonaws.com/dev/todos
yarn serverless logs --function queueProcessor
Conclusions
CDK is excellent at defining and making sense of complex infrastructure and resources. However it does come with quite a bit of overhead. The CDK project itself has dependencies that you'll need to manage, and, most importantly; the infrastructure code is, well, code, which you'll need to maintain, lint and test. On the other hand, being able to test it, is definitely also one of the strengths. It's also generally a good idea to separate your more long-living infrastructure into a separate CloudFormation stack. It minimizes the risk of accidentally modifying, or even deleting, important stateful resources such as a DynamoDB table.
There are ongoing projects that tries to bring CDK constructs natively right into Serverless via plugins, one example being Lift, and other frameworks that are built on top of the CDK, such as Serverless Stack. Lift looks promising, but it doesn't yet support using custom constructs, and many organizations and projects have invested a lot into Serverless Framework and aren't ready to jump ship to an alternative like Serverless Stack.
For smaller projects, or projects where the infrastructure and/or the interaction between the infrastructure isn't complex, using CDK and Serverless together is unlikely to be worth the overhead. For larger, more complex apps, though, where you might want to unit test your resources or just be able to describe them better than with CloudFormation, which quickly gets very messy - it might be worth considering!
If you enjoyed this post and want to see more, follow me on Twitter at @TastefulElk where I frequently write about serverless tech, AWS, and developer productivity!
Top comments (11)
Nice article ! Thanks for sharing.
In addition, if your CDK stack does not require any assets to be uploaded (understand does not contain any lambda, which should be taken care of by Serverless framework definition), you can use CDK programmatic API
synth
to inject generated Cloudformation resources directly within theresources
key of your serverless.yml file. You then only need to runsls deploy
to deploy both Serverless framework resources and CDK resources. Take a look at twitter.com/bartheletf/status/1382... to know more !Ooh, that's a great point I didn't consider! It does make it a bit simpler but you also lose a few of the benefits of having the separate stacks and being able to
cdk diff
for example, I suppose.Thanks for the tip! 🙌
Hi @Frédéric, excellent idea but I had a question:
What if the exported values are tokens? Cause the token values are alloted actual values only after deployment through cdk.
Hi @adityanair102001 , I wrote an article to explain in more detail what can be achieved in terms of CDK provisioning through Serverless framework lifecycle. You can have a look at dev.to/kumo/serverless-framework-a... to learn more. Token can be resolved using the resolve API available on the CDK stack :)
Thanks for sharing! Having to reference the queue with a simple
{cf:InfrastructureStack.queueUrl}
is much better than making complex Joins in CloudFormation.In one of my projects, I was having to reference a queue like this:
Ah, I've had my fair share of those! Happy you found it useful! 🙌
The "cd infrastructure && yarn cdk" trick was nice!
Fantastic! Cleverly combines 2 awesome things :) Bookmarked for later, this actually is a wheel I have invented many times before with varying levels of pain.
Glad you liked it! 🙌
Sounds interesting! I think it could be helpful if you want to eventually migrate to CDK completely.
I agree! And if not, in one way or another we'll likely some kind of support in Serverless to use CDK constructs in the future and this could bridge the gap until then!