DEV Community

Cover image for ⚡️Combining Serverless Framework & AWS CDK
Sebastian Bille for AWS Community Builders

Posted on

⚡️Combining Serverless Framework & AWS CDK

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
Enter fullscreen mode Exit fullscreen mode

and then, in an empty folder, run the generator with:

yo sls-node
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Next, navigate to the created folder and initialize a CDK project:

cd infrastructure
npx cdk init --language typescript
Enter fullscreen mode Exit fullscreen mode

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

Enter fullscreen mode Exit fullscreen mode

🔨 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.

architecture diagram

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
Enter fullscreen mode Exit fullscreen mode

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'
    });
  }
}
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
});
Enter fullscreen mode Exit fullscreen mode

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}
Enter fullscreen mode Exit fullscreen mode

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}
Enter fullscreen mode Exit fullscreen mode

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();
};
Enter fullscreen mode Exit fullscreen mode

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);
};
Enter fullscreen mode Exit fullscreen mode

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",
...
Enter fullscreen mode Exit fullscreen mode

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",
...
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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)

Collapse
 
fredericbarthelet profile image
Frédéric Barthelet • Edited

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 the resources key of your serverless.yml file. You then only need to run sls deploy to deploy both Serverless framework resources and CDK resources. Take a look at twitter.com/bartheletf/status/1382... to know more !

Collapse
 
tastefulelk profile image
Sebastian Bille

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! 🙌

Collapse
 
adityanair102001 profile image
AdityaNair102001

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.

Collapse
 
fredericbarthelet profile image
Frédéric Barthelet

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 :)

Collapse
 
andrenbrandao profile image
André Brandão

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:

      MESSAGE_PROCESSING_QUEUE_URL: {
        'Fn::Join': [
          '',
          [
            'https://sqs.',
            { Ref: 'AWS::Region' },
            '.',
            { Ref: 'AWS::URLSuffix' },
            '/',
            { Ref: 'AWS::AccountId' },
            '/',
            { 'Fn::GetAtt': ['MessageProcessingQueue', 'QueueName'] },
          ],
        ],
      }
Enter fullscreen mode Exit fullscreen mode
Collapse
 
tastefulelk profile image
Sebastian Bille

Ah, I've had my fair share of those! Happy you found it useful! 🙌

Collapse
 
memark profile image
Magnus Markling

The "cd infrastructure && yarn cdk" trick was nice!

Collapse
 
janvanthoor profile image
janvt

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.

Collapse
 
tastefulelk profile image
Sebastian Bille

Glad you liked it! 🙌

Collapse
 
grenguar profile image
Igor Soroka

Sounds interesting! I think it could be helpful if you want to eventually migrate to CDK completely.

Collapse
 
tastefulelk profile image
Sebastian Bille

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!