Introduction to the AWS CDK: Infrastructure as Node

Hi, everybody. Thank you for virtually attending my talk. I'm going to be talking about the AWS CDK today, and the title of my talk is Introduction to the AWS CDK Infrastructure as Node.

So I guess the very first question to answer is, what is the CDK? So that's an abbreviation for Cloud Development Kit. It is an AWS-specific infrastructure as code tool. It's similar to tools like Terraform that you may have used in the past. It supports a variety of languages, so you can write your applications in JavaScript, TypeScript, Python, Java, and C Sharp. I believe there are plans for other languages in the future as well.

And the way that it works under the hood is that high-level JavaScript or TypeScript classes map to these things called CloudFormation templates, which I'll talk about again in a couple of minutes. If you've used the AWS SDK in the past, the CDK is not the same thing. The AWS SDK is used for making simple API calls, whereas the CDK is actually able to maintain state about your application, allowing you to update it and redeploy it without having to go through the same checks that you would if you were just making direct API calls. The CDK itself is fairly new. It reached general availability in the middle of 2019, so there are still some AWS features that are not supported yet, since AWS is quite massive. And then it's also free to use, but I've included an asterisk here because while the CDK itself is free to use, if you start using it to deploy things like EC2 instances or other AWS resources, you will be billed for those things.

So I guess next, you might be asking, why would I use this? So as I said before, there are lots of tools out there like this, things like Terraform and whatnot. So I'm going to actually reference a report from the Cloud Native Computing Foundation that surveyed approximately 17,000 developers. If you disagree with these quotes, please don't shoot me. I'm just the messenger. But JavaScript is the most popular server-side programming language among cloud-native developers. And 62% of cloud-native developers are using AWS as their cloud hosting provider. So the CDK really meets developers where they're at. There's already a lot of developers out there that are writing applications in the cloud with JavaScript and TypeScript and deploying them to AWS. By using a tool like this, you can write your infrastructure as well as your applications using the same tools and languages. And that's always been one of the upsides to Node.js was that it allowed frontend and backend developers to use the same common language. And this just extends that even further into your deployment in ops. The CDK also offers you testable infrastructure. So there is an AWS CDK-slash-assert module. It integrates really well with Jest and snapshot testing. And then the last thing I wanted to mention is you really shouldn't worry about vendor lock-in because you're probably already locked in. Unless you have the most extremely trivial app being able to go from AWS to something like Azure, it is probably going to require some effort importing.

So the CDK is not going to lock you in any more than you're kind of already locked in. And then before I dive in a little too much further, I wanted to something that I found out while I was researching the CDK that I thought was kind of interesting. What is something called the JSII, which stands for the JavaScript interoperability interface. And this is kind of the tool that sits underneath the CDK that allows it to be written in TypeScript, but still supported by all the other languages that I named earlier. And when I originally read about this, I thought that it probably worked by just generating code that was kind of language specific, but actually under the on the node.js runtime. And what it does is it will execute your TypeScript code and send it back and forth, the input and output back and forth as JSON between the node child process and whatever host process has been running your application. And so there are some generated bindings that are part of the CDK output. So you can write your code once and you'll get the same API across all of these different languages. And that does unfortunately come with a performance hit because you're spawning a node process, you're interacting with a child process instead of generating the code directly. But I just thought that that was something that was kind of cool and wanted to share as part of this talk.

So back to the overall point of this talk. So I had mentioned CloudFormation earlier. CloudFormation is a well-known AWS service that basically allows you to define your architecture, your resources that you'll be using in the cloud as a JSON or a YAML template file. And then it can be deployed to be in the CloudFormation service.

It will take care of creating all of the resources for you that you need, such as instances or lambda functions or anything like that. And it can actually manage large groups of resources as a single unit, which is called a stack. And so stacks can be created. They can be updated and modified. They can also be deleted, and everything happens to that entire group as one single entity. So it makes the maintenance overhead a lot simpler for developers.

And as I kind of alluded to earlier, the fact that it maintains state between your deployments allows it to be much more powerful than individual AWS SDK calls where you would kind of have to manage all that state yourself. And then within CloudFormation, there are basically inputs and outputs to your CloudFormation stack. The inputs are called parameters. And these are good for passing in things like sensitive information, or if you were deploying a website, maybe what the domain name is for that stack and things of that nature. And then it can also generate outputs. So if you tell it to provision an S3 bucket, you might not know what the name of that bucket is ahead of time. So that can be used as an output, which can then be imported by another CloudFormation stack. So you can see that it's kind of composable and very powerful. But the biggest drawback is that CloudFormation is very verbose. So to maintain these JSON and YAML files by hand can actually be quite a bit of work. And it's very error-prone.

So the CDK saw the power of CloudFormation and introduced this API on top of it using TypeScript. And what it does is it gives you these building blocks called constructs. Constructs are kind of the way that you build and compose together CDK applications. And there are a variety of different types of constructs at different levels. So for example, the level one construct, these are basically CloudFormation resources. CFN here stands for CloudFormation in shorthand. So for an example, there is a CDK construct called CloudFormation bucket. And this is just, as bare bones as a wrapper around CloudFormation as you can get. But then level two constructs kind of take that up a level to introduce an intent based API.

So, building on the same example, instead of a CloudFormation bucket, you might use an S3 bucket. And this has a much more kind of user-friendly API. And then finally, there are what are called patterns, which are even higher level and can compose a lot of different components together. These can really accelerate your productivity.

So, for example, you can, instead of having to create Lambda functions, wire them up to an API gateway and things like that, you can just use the Lambda REST API pattern. And like I said, it can really accelerate productivity. And so the way that these applications work are you take your various constructs and you compose them into what's called a construct tree. And then it's also worth pointing out that AWS provides a large number of constructs from their library, but it's also possible for user land to create their own constructs to be more tailored to their needs.

So there are, I guess two special kinds of constructs that are worth discussing a little bit. There's our apps and stacks. So the root of the construct tree is always going to be an app component. The reason it's called an app is because CDK applications are referred to as apps. Like I said, this is always going to be the root, but then stacks are constructs that map to CloudFormation stacks. So I mentioned that, in CloudFormation, groups of resources are kind of grouped together as a stack and this is kind of a one-to-one mapping there. So apps contain stacks. You can have more than one in a single app, and then the stacks are usually what contain the other constructs. One thing worth pointing out is that each stack is configured by an environment, and I'll talk about that right now.

So an environment is an AWS account ID plus a region where the stack is going to be deployed. So this is basically saying this user is deploying to this region in the cloud. And so, an environment has to be provided for every region that you're trying to deploy to, and for every separate account that might want to deploy your stack. If you don't specify an environment, then the stack is what's considered to be environment agnostic, but these are pretty limited use. And then to provide the environment, if you've ever worked with any of the AWS tools before, there's a variety of ways to do this. In the code itself, you can pass in values to the stack constructor, but you can also pass in a profile flag from the command line or specify different environment variables, and it will automatically pick those up in the code and know where to deploy your stuff. You can also set up your AWS profile so that you have a default environment. But that's more of a local development type of use case.

So with all of that, I think we can actually generate our first CDK application. So I've added a simple command line up here using mpx, so you don't actually have to install anything yet. mpx aws-cdk, that is the name of the the module. init, app, and then we're passing the language. We want to use JavaScript here, but you can pass any of the other supported languages.

And so this will create a full application skeleton for you. One note is that you have to run this from inside of an empty directory so that it doesn't accidentally overwrite anything that might exist. And so this creates a bin folder, and so you can actually run this file directly. You can see the little shebang at the top of the code here that most node binaries include. So what this does is it imports a test stack that was also generated for you, instantiates your application with the new cdk.app constructor, and then it just creates a new test stack, and within the test stack you can see it passes the app as the first argument. So that is how the construct tree keeps track of which constructs are children of which other constructs.

And then we're going to be calling this one test stack, so that's what the second option is there. So looking at the stack itself, you can see this is the code that was generated. I left in some of the comments and other things that were automatically generated, but in future examples I'll be removing those to save space. So the first thing that we do is import the CDK itself, and then we create a test stack class, which extends the CDK stack base class. The constructor for a class takes a scope, an ID, and props. The scope is the parent construct, as I mentioned before. The logical idea of the construct is going to be when we synthesize and deploy these applications. And then props are an optional map that can be passed in that are used to define other properties of your construct. So if we wanted to add more constructs, then we could do something like this. NPM install dash dash save AWS CDK slash AWS EC2. This will basically install the CDK constructs for the EC2 service. In this simple example I'm adding a VPC to our stack. The reason I'm doing this is because VPCs can be deployed at no additional charge. So if you wanted to experiment with this at all and deploy it, you should be able to run this without actually incurring any charges.

So next I wanted to talk about how these applications are kind of synthesized and deployed. So you can see we have the overall workflow here. You'll see cdk-cli at the top. cdk-deploy is one of the CLI commands. I'll talk about what some of the other ones are later. And what it does is it reads in your application source code. It goes through what's called the construct phase, where user code is run and all the constructor chain is executed, so it's basically building the construct tree. The prepare and validate phases are hooks that are available to constructs, but they're generally not needed and sometimes they're actively discouraged. And then next comes the synthesis phase, which generates something called a cloud assembly. The cloud assembly is going to be your cloud formation template as well as any other deployment artifacts that are needed to deploy your app to the cloud.

And I'll talk about what those other deployment artifacts are in a little while. And then the deploy will actually take your cloud assembly and upload anything that needs to be uploaded to the cloud and start a cloud formation deployment. And once that succeeds then you have a CDK app that is actually deployed to the cloud. You can actually do the synthesizing step as a separate step without needing to deploy it, which is nice for like local testing and unit tests. So you would do that via the MPX AWS CDK synth and then the name of your stack.

So in this case test stack, this will generate, it'll translate your CDK app into a cloud formation template. It'll generate any of the deployment artifacts such as Docker images, if you're deploying any lambdas, it will bundle those up for you. And then it'll write everything to both standard outputs, since this is just a synthesis and not a deployment. But we'll also create your cdk.out directory, which is where everything is kind of stored before it's deployed. And then you can see to the right here, I actually have captured what the cloud formation template looks like. And you can see that it's taking up the entire height of the slide and is very unreadable. And that's based on a cdk app that was roughly a dozen lines of JavaScript. So you can see where the increased verbosity comes from with cloud formation as well as the expressive power of the cdk.

Next, I wanted to talk about assets and bootstrapping. So any local files or directories that need to be uploaded to S3 or any local Docker images that need to be uploaded to the Elastic Container Registry are known as assets. If your application uses any of these assets, then you'll have to do something called bootstrapping which is something that has to be done per environment. So per user and region combination. It will also create an additional cloud formation stack for you called cdk-toolkit. And it consists of an S3 bucket and an IAM set of resources for deploying the assets to the cloud.

One thing to note is that you will likely be charged for this because you'll be storing assets in AWS. So I wanted to look at a more realistic example now where we'll deploy a static S3 site. I included an asterisk here because again you will be charged by AWS if you run this. I've created a new stack here called the website stack which extends the CDK stack class and then inside I'm creating a new S3 bucket. So I'm going to call my bucket website bucket. I'm going to make index.html the the index page for my site that I'm deploying and I'm going to grant public read access to the world so that anybody can can come and view my site. And then to deploy it I'll use the S3 deployment bucket deployment construct so I'm attaching it to the stack I'm calling this deployment my website. The sources are going to come from a local directory that I'm calling www that will actually create assets as I mentioned in the previous slide, that's the part that you're going to be charged for and then it will upload everything to the bucket that we just created website bucket.

One thing that's worth pointing out here you know this is kind of a small example because it needs to fit on a slide but you can take this further and add things like DNS or CDN to really make a nice static site for yourself. So then to actually deploy the site we would say mpx awscdk deploy the website stack and then I'm actually going to pass in my aws profile from the command line so that it knows what environment to deploy to. But the first time that I run this I'm going to see the following error it says this stack uses assets so the toolkit stack must be deployed to the environment. So what that means is I have to bootstrap this environment first and you can see below I've added the mpx awscdk bootstrap and then passed my profile that will create the you know the bootstrapping infrastructure that I spoke about before. Then I can rerun the same deploy and everything should work according to plan this time. So if you want to see what those deployed resources look like in the top left here I have the CloudFormation console that shows the app and the bootstrap stacks. The top right hand corner is the S3 console that's showing the app and bootstraps buckets. Bottom left is the app bucket containing the static assets and the bottom right is the site actually deployed and running in production. Like I said, if you wanted to make this a little fancier you could do something like add DNS in the CDN so you could have a more user-friendly URL there. And then to clean up you'll use the CDK destroy website stack. I also recommend that you go into the web console for AWS and look around S3 and CloudFormation to see that all the resources are cleaned up. I've linked to a CDK issue below where bootstrapping does not always clean up after itself. I wanted to provide you with commands here that you can use to clean up. Or just click through the web console and you should be able to do the same cleanup by hand. And then I wanted to wrap up by talking about the CLI. These are all basically the commands that we used to do the deployment.

You can install the CDK locally. If you do that, then it becomes known as CDK and not AWS CDK. So that's one thing to note. You can also install it globally with the dash G flag, but I don't really recommend it. Global dependencies are usually not the best thing. So I recommend adding it to your package JSON and calling it from one of your NPM scripts.

So there are also a handful of other commands here that I didn't touch on. CDK-LS will list the stacks that are in the application. Diff will compare the stack with the deployed version or local CloudFormation template. Metadata can display metadata that has been attached to a stack. Similarly, you can pass in key-value pairs called a run-time context to your application using CDK context. There's a doctor command which can look at your project and kind of link it for potential problems. And then CDK-doc can just be used to open up the official documentation in the browser. It's kind of a nice shortcut.

And then finally, I wanted to include some additional resources here. So the first link is the official documentation, the second link is the CDK source code, and then the remaining links are a combination of AWS and community created resources for learning the CDK and providing reference examples. So it can really get you started and up and running pretty quickly. And that's all I had. Thank you again for coming to my talk and have a nice day everyone.

Colin, welcome. Welcome to your Q&A here. First of all, let's have a look at the poll. We asked the folks, you asked the folks, have you used the AWS Cloud Development Kit? And most people said no. Well, why do you think that? I would like to hear your comment on this. It's really not surprising at all. It's, like I said, fairly new. It just went, I guess, production-ready a couple of years ago. I think it's actually starting to catch on though, so I'm hoping to spread the good word of the CDK and hopefully some JavaScript developers out there get a chance to give it a try, take it for a test run. I feel like it really does just knock down one of the last barriers that's there for JavaScript developers to be able to do the entire stack themselves. Exactly, exactly.

And I still remember the day when I saw the first email about CDK within the company. Somebody just emailed, hey, I have this great idea, how about doing this? Wonderful thing. So I do think that the growth of usage of CDK on AWS will grow in time because it just makes things so simple.

One of the points you made in your talk was that it takes a lot of the effort from writing a declarative infrastructure as code to a more sensible, defaulty way of writing infrastructure as code. So what makes you use CDK over CloudFormation, for example? So CloudFormation, to me, it's great because it gives you the ability to deploy and it handles updates and everything like that. It's just a lot of text to manage and sweat through, and it's just very error-prone. To me, the CDK was nice because I'm writing JavaScript, which I'm already doing as I'm application. If there's a syntax error in there, it's a familiar syntax error instead of trying to dig through a large YAML or JSON file. It's so much more compact. On my one side, I showed on the right-hand side, it was like the entire CloudFormation text, and you couldn't read it at all compared to a dozen lines of CDK JavaScript. To me, that's a big win.

I agree. Sometimes, if you want to do something really quick, like create a VPC, on CDK, it's a single line of code. On CloudFormation, it's 87 lines of code.

Let's get to some of the questions we have from the audience. A question from Lara. Is it possible to use the Cloud Development Kit to automate rollbacks based on custom conditions? For example, failed smoke tests or something like that. That's a good question. I don't know that one off the top of my head. It does handle rollbacks, but I don't know that it handles it based on custom conditions or not. That's something I would have to imagine itself. So, let me try to kind of answer this question from my experience. If you are deploying your Cloud Development Kit through a proper CI CD pipeline, you absolutely can fail it. If something happens, you can just trigger a fail rollback on the CloudFormation side, because as Colin says, CDK just uses CloudFormation for a lot of its parts. So, in essence, yeah.

Okay. Question. And these are very common questions that I hear as well when talking about this is, a question from Marc. Are there any benefits in using the Cloud Development Kit over the serverless framework or the serverless.com framework? So, I think there are tradeoffs, as with everything. So, with the CDK, it's a first-class citizen in AWS.

So, you know, it's built by AWS engineers, supported by AWS engineers. It's guaranteed to work there. The serverless framework, you know, it might work with other clouds a little bit better. But, you know, that's kind of by design. So, I guess, in my opinion, if you're deploying to AWS, using official AWS tools is probably the best-case scenario.

I agree. So, a fair point. You know, serverless framework has its own benefits, especially for serverless applications. You also have SAM on AWS, which is kind of a transformation of CloudFormation. But, CDK, again, like, one of the things that CDK has, and you prove this in your talk, is that it has this ability to use a native programming language to build things out. So, if you're a JavaScript developer, I mean, it's much more easier to write this than try to hash out some JSON or YAML, in this case.

Okay, we have more questions. One coming from AO. For one of us that is already building our infrastructure in CloudFormation, is it possible to import current resources, like a production database or something static, into the Cloud Development Kit? Yes, you should be able to do that. So, I'm working on a somewhat large AWS project right now that's built on top of CloudFormation and you can chip away at it by porting bits of it to the CDK a little bit at a time. So you don't necessarily have to make the whole big bang transition, if that's what you're asking, if that makes sense.

Right, so you're saying that potentially you don't have to transfer your entire thing into CDK at once, you know, you can leave some things and other ways of provisioning things. Right. I'm also definitely not advocating for, you know, if you have a working solution to just completely drop everything and try to re-architect it just because, you'll probably end up with more headaches than times. Yeah, you know, I was one of the things, one of the infinite wisdoms I hear heard out there is the best framework slash programming language is the one you're good at. So that's what that's the one you should use.

Okay, we have a question from SB. Why is CDK so heavily based on classes rather than more usual constructs in JavaScript like functions? So it's just a way of looking at the cloud as a collection of objects that kind of interact together via different properties. So, you know, for example, you have a lambda function, I think it's easy to think of that as a clash, you have an instance of a lambda, it has specific properties on it, like an ARN and things of that nature. Whereas if you were to try to make it more functional, I think the code would be a little less clean in that fashion. Got it. Got it. Okay. Okay. Yeah.

Like I use my CDK mostly in TypeScript or in Python, but I'm by no means a great developer. I just use it like a utility, so I wouldn't even know how to answer this question. But speaking of programming languages and the ability of CDK to use your generic programming languages, is there a way we can somehow test if we actually deploy things? Because we chatted a bit before in the lightning talks that testing is really important. Can we do the same with CDK code? Is there a way we can test the code before we do?

Yes. So CDK was actually, I don't know if it was an original design goal, but it has been designed such that it integrates really well with Jest and kind of has its own assertion library built into it. So I think I referenced it in my slides. But so basically you can take a CDK stack and you can say expect stack to, and then there are some helper functions. So include a specific resource or include this set of resources or match this pattern. So there's all types of useful utility functions that you can then unit test your stack with before you even go about trying to deploy it and then trying to debug it in the cloud. The more you can do locally, the better.

Yeah. So basically writing your unit test for CDK and have set expecting expectations. I remember once a long time ago, I've done the same thing with Jest. And Jest is this just framework for testing. I've used, instead of doing assertions, I actually use the snapshot feature. So you can also make like snapshots of the thing you want to happen, and if anything changes, it just doesn't work. Excellent. I think CDK also has functions to integrate with snapshots. You can say like the snapshot should mean something. Okay. Excellent. There you go.

Last question for you. We have 71% of people here answering that have not tried CDK or do not use CDK. What is your advice to novice CDK users? So for somebody who just after your talk goes ahead, you know what? I'm going to do something in CDK. What is your advice to them? My advice to them would be, you know, if you have an existing setup already, you can just try out little bits of the CDK and see if it's matching what's already there. If you're lucky enough to be doing greenfield development, then there's lots of tutorials out there and whatnot. You can go through those and make sure that you're basically getting it right the first time. But just take your time. It's actually really straightforward.

As long as you understand the language that you're programming in and understand what you're trying to build on AWS, then I think you should find that the friction is pretty low. If you're not entirely sure what you want to build on AWS first, I think it would be helpful to get that background understanding so you understand what a Lambda function is or what type of EC2 instance you want. Something like that.

Yeah. Excellent. Thank you very much, Colin. I appreciate all the questions, all the answers to the questions, and everybody, I appreciate your questions. Thank you very much for your talk. It was amazing, and thank you very much for your time. Thanks.