Enter CDK: What this Means for the World of IaC

Hey everyone, I'm Roy and today I'm going to talk to you about AWS CDK and what does it mean for the world of infrastructure as code using AWS CDK. Today I'm an engineering team leader at Firefly and what we do at Firefly is to take your entire cloud footprint along with your Kubernetes clusters infrastructure and on the other end to take your infrastructures code if it's CDK or even Terraform, Pulumi, CloudFormation and even Helm and to combine them and to show you a merged inventory that shows your entire cloud asset footprint in the means of your infrastructure as code.

Also as you can see I like Schnitzel call of duty and infrastructure as code, I guess the same as all of you. What is actually CDK and what is the huge hype about CDK so when I was visiting the last AWS event I couldn't stop noticing that everyone is asking about CDK. They asked how to start working with CDK and in what languages they wanted to know how they migrate their own CloudFormation stacks into CDK and I think that with all these questions I started investigating as part of what we do at Firefly which is to use the best infrastructure as code and to supply our customers the best infrastructure as code and after a quick run over CDK I discovered an amazing new tool by AWS that you must be familiar with and an even easier way to migrate your CloudFormation into CDK so what is actually CDK?

CDK aka Cloud Development Kit is a concept not only by Amazon also by Kubernetes and also by Terraform themselves. CDK means that you're not using any config language to create your infrastructure as code such as the JSONs, HCLs and even YAMLs but you're using coding languages in the AWS CDK, they now support TypeScript of course and JavaScript. TypeScript by the way is the language that it was written in so it works best in TypeScript but also JavaScript Python and even Golang. Besides CDK is the CloudFormation successor. CDK is the brand-new fully-oriented AWS tool to create resources with and it's much better than CloudFormation.

In let's say three major points. The first one is that CloudFormation is messy. If you're gonna write lots of resources because of its super explicit way of approach even CloudFormation is going to be a super huge YAML or JSON. Depends on your benefit but it's gonna if you have much resources, it's going to be a heavy file and not so likeable to work with.

Also, if you're gonna create relations in your CloudFormation it's going to be a hell because it's making it super messy super buggy and not even understandable for anyone that doesn't know it. CDK solves all of these notes because CDK uses classes and variables such as any other coding language to create the resources with it.

Also another major point is the multi-regional way of working with CloudFormation. As you already know, CloudFormation does not support multi-regional and if you want to deploy your CloudFormation stack in some, in multiple regions, you'll need to use stack set, a kind of patch that AWS wrote to deploy one CloudFormation stack in multiple regions. With CDK it's basically solved because CDK supports the stack out of the code. You can create as much stacks as you can inside your code and just deploy them one by one into each region you wish.

Also, CDK is basically now the native experience of AWS, which means that it's not only 100% AWS-orient, it's the only way to, the only way, the only thing you can write with CDK is basically AWS, so it's not fit to any other providers, it's full AWS service so it means it works best with AWS and only AWS. Even more than this, as I already said, CDK supports multiple languages. The most typical one is TypeScript but you can write also JavaScript and much more languages with it, which is amazing because basically, if you think about it, you can write one repo, put in this repo your already existing coding or programming functions. On the other hand, you can put in the same repo your infrastructure as code, such as in CDK, and then if you, let's say, deploy an instance with some code, you can define the instance itself in the same repo, which is basically a branding amazing way to work with infrastructure as code.

So, how does CDK work? CDK turns code into cloud formation stacks, which basically means that AWS wrote CDK on top of the old cloud formation mechanism. You're going to write it in each language you wish, as we already described, and you're going to write constructs, which means creating an S3 bucket resource or a instance resource, for example. After writing this in these resources, you're going to use the command CDK synth, which is basically a dry run of what you already wrote, and it will generate automatically the cloud formation template that describes exactly the resources you wrote in any other coding language you used. So, creating the CDK synth created a template, and then following that, you're going to use CDK deploy to deploy the stacks by actually creating cloud formation stacks with this template inside, and creating out of the stacks the resources on your AWS specified region or regions, for example.

Deploying will create two artifacts, one, an S3 bucket files that run the state, let's say, of your CDK code. It saves the resources that were created, the changes that it made, and you can track over there and see the state of the lately deployed stack. Beside, it's going to create the CloudFormation stack itself, which creates the resources out of it. Into your cloud.

So who should use CDK and when? It's a pretty typical question because the who is basically everyone, everyone that uses AWS because CDK is the 100% oriental way to approach, let's say, to create infrastructure as code over Amazon. And especially CloudFormation users that wish to migrate the CloudFormation old stacks into CDK. It's gonna be a pretty easy process to go through and we'll do it in the example following that. Another group is like any DevOps or SRE teams that are working with AWS. And besides, if you can think about it, even your developers can use CDK because now it's not a knowledge you need to experience with YAMLs or config. It's just coding, the same as any other programmatic coding you do. And besides, all of the infrastructure code users who work over AWS, it's best to work with CDK.

When? When is, I think, every time because if you're already using any infrastructure as code, it's always a good way and always a good time to start working with a tool that is officially working with AWS.

And besides, if you're a CloudFormation user, then you needed to do it yesterday, basically, because CDK will, let's say, spare you lots of suffering and hardship working with CloudFormation.

The pros and cons about working with CDK. I think the pros are pretty straightforward and we already talked about them. It's the support of multiple languages. It doesn't require any config language. The multi-regional benefit and the AWS orientation that is basically building.

Who should not use CDK? Not using CDK is, in my opinion, when you only use, instead of working with only AWS as your provider, you use multiple providers, let's say Datadog and Ops0. If you're working with more than one provider, as we said, because CDK is the AWS tool, you need to work with another infrastructure as code language. And at this point, it gets a bit messy. So, if you're working with AWS, I think the best approach is to use CDK, but besides, you should think about it and maybe use one of the other solutions for working with infrastructure as code. Instead, maybe Terraform or Pulumi or any third-party that doesn't stick into one cloud specifically.

In this part, I'm going to show you a bit about how to migrate your cloud formation into CDK and besides, how to create resources with your new CDK stack.

So, as you can see here, I demonstrate a pretty basic stack that creates a cloud for CDK resources and alongside includes an old cloud formation stack that I already deployed on AWS before and now I want to migrate it into my CDK project.

The stack, as you can see, contains an instance, a basic instance that doesn't do too much, but already deployed on my AWS account and at this point, I will need to migrate it into my CDK. Alongside, I created an S3 bucket and an SQS queue that all of them are newly resources, that created inside my CDK stack.

By running the basic command, CDK sync, I'm basically planning this into... I'm basically planning this into my... into my S3 bucket and creating a plan of the dry run of what we're going to deploy soon.

After the plan finished, I can just run CDK deploy. And in a heartbeat, these three resources alongside the already migrated CloudFormation stack are gonna be deployed to a new CloudFormation stack that is described by my CDK stack in this code.

You can see it in my AWS account that when I create a stack, it has three resources inside. The example instance that was migrated for the CFT stack that I imported and also the bucket I configured and the queue I created newly.

After doing this thing, I basically can just create another includes as much as I can and also create new resources alongside. And I have here my first TypeScript CDK project. So this is basically the entire CDK hello world.

And I think that the two key takeaways you should consider after this talk is the first one, CDK is a rising and amazing technology that will probably be the best tool to manage infrastructure and score over AWS soon. Not if not even now. And you should consider working with it.

The second one is that each day you're using cloud formation is a waste and you should totally consider working with CDK. And as you can see, the importing of all cloud formation is super easy. So I think you should basically work with CDK at this point.

Thank you all. I was Roy, and this is my mail. Feel free to contact me with each question you have if it's infrastructures code or AWS management. And let's keep in touch. Thanks.

Hey, Sharon. Maybe a little bit more surprising than I thought. I mean, I knew that Terraform would be the large majority, but 76% and zero percent, a big zero on CDK. So it's a very, very new, I'm guessing. Yeah, well, it's not even surprising because I knew the Terraform is gonna be the major here and the zero percentage of CDK just showing us how much a CDK is new and it's not still being fully fulfilled of its potential.

Yeah, it's not well adopted yet. But what's actually interesting is take a look at that number two is other. So I wonder what that is like homegrown tools. Folks, feel free to drop in the chat, in the discord, what the other is. Let's find out what other tools you're using besides Terraform and say like the one other ones that are on the list. And that AWS cloud formation is more popular than Pulumi actually did surprise me as well. Felt like people had moved on from cloud formation once Terraform and Pulumi were around. So that's interesting.

Alright, cool. Those are our results, but I'm waiting to hear what folks have to say about their other. Oh, here I see Pulumi's rising now. So okay, I take it back. And other has gone down a little bit, but I really don't want to know what that other is. It's very intriguing to me. Yeah, so let's take a second and see what the community has to ask and what they want to know. So first and foremost, I guess one thing that's really interesting about AWS and CDK in the context of infrastructure in general is how does it handle things like drift detection that maybe Terraform is a little bit more well-equipped and is known to have kind of guardrails for. So what are your thoughts on that?

Well, it's a pretty good question because as CDK successor of the CloudFormation is dealing in the same. The CloudFormation way to deal with drifts is to show on all the supported AWS assets the complete drift that would happen if you're gonna run a stock deploy or a stock plan. Can you hear me, sorry. And in this case, if you're gonna run any stock deploy or stock plan, you can see the drift through the CloudFormation and CDK acts the same way exactly. It supports all of the AWS-supported assets and it shows the drift completely. It can help you analyze the drift in the inner property of the assets, which is a really cool feature, Terraform doesn't support it yet. Another great advantage to the CDK and through this feature, you can basically monitor drifts and see the current state of your infrastructure as code regarding the resources that it was created. So it's a really cool and nice feature you have with CDK, another great advantage here. Awesome, that's cool.

I was actually thinking about it in the context of Terraform, but you actually enlightened me. I didn't know that CloudFormation had that kind of drift detection as well. I've only really heard about it in like kind of Terraform context. But I'd also, if you wanna kind of allude to a little bit of that Terraform Pulumi in that context as well, I'd love to hear like how they handle it, just interesting to me.

Of course, and then Terraform has also a way to show drifts, it's a pretty brand Terraform plugin that they developed. Pulumi as well supports it because Pulumi as we said, is based on Terraform. And it's also showing the drifts and you can basically take the Terraform output to fix them. It's not gonna do it automatically as AWS-CDK does. This is the biggest advantage and it's also not gonna be that specific as the CDK can get into if it's showing the CIDRs of a security group, if it's getting into policies and roles and it can open the JSON and show the difference completely and it can help you fix it. Pulumi and Terraform do support drifts but it's not that good as a CDK of course because it's originally been created by AWS, so.

Yeah, that makes a lot of sense. Well, you've got folks intrigued, that's for sure. I have a question coming in from the crowd. CC Miller asks, well, got me interested in CDK and he wants to understand how complete newbie friendly is it really? He says he teaches a 16 week intensive bootcamp for full-step JavaScript called School of Code but he wants to know even for him how easily adoptable it is. Well, as you saw in the demo over there, I think it's pretty adoptable. Let's call it, yeah, it's newbie friendly. And the usage of CDK is pretty straightforward. You can basically pick any, this was a demonstration in TypeScript but you can basically pick any coding language you can think of and getting into it even if you already have a project in your needed language is gonna be super straightforward. You can just start by commanding the CDK in it which basically creates the infrastructure that it needs, the supported infrastructure on the AWS console side. And then you can just start writing resources and CDK sync and deploy will in a second, in a heartbeat will deploy them into the cloud. I guarantee that the Hello World example is gonna take no longer than five minutes. And if you're gonna start migrating cloud formation for example, or getting into a bit harder resources it's also gonna be a super, super easy way to go in.

That's cool. Julie chimes in saying she thinks that the other is probably Azure arm or bicep. But I wonder what anybody else is thinking. If you are using Azure resources or other maybe Google Cloud feel free to chime in and let us know. We really, really want to know what that other is. Don't keep us in suspense. More questions. In which way does AWS CDK prevent usage of AWS Stack Set for example? Of course, so that's a good question actually.

Stack Set is basically Amazon's answer to the usage of CloudFormation if you need to use it in a multi-region way. Stack Set is a patch let's call it that was built over Amazon CloudFormation and you can use Stack Set to deploy the same CloudFormation stack in different regions as much as you want, but it's also meaning that you need to control another resource and to support another resource and it's gonna price. It has a price and it says maintenance value.

With AWS CDK, you're basically creating the stack let's call it or the component that is gonna be deployed in your code. By doing that, you can create as much stacks as you wish, you can create them in the same project or create them in different projects and by that, you can basically take the same component or the same bunch of resources, you can unify them as a simple stack and then you can deploy the stack in several regions by doing it through the code. So it's a great advantage, doing it is a super, super easy way. With CDK. Yeah, with CDK, of course. And by that, you can basically prevent usage of stack set or cloud formation. Specifically, you can just migrate your cloud formation into your CDK and with CDK, deploy it in several regions and then prevent the usage of stack set, which is basically the right way to go these days.

Cool, I mean, I was gonna ask, but you kind of maybe covered it, like how complex is that? What's the complexity with actually with running it in multi region is it like, so it's not so hard, you're saying? It's super, super, super. Pretty straightforward? Yeah, super straightforward. You just gonna need to create several components and give each other different regions to go with and connect them to the component you wish to deploy. That's it. That's cool. Awesome, it sounds really cool. Also, I'd love to ask the folks after this talk, how likely are you to check out CDK and see how it runs and try and make your own examples? I think this was actually a very enlightening talk. I heard that it was like all the buzz that AWS Reinvent CDK, everyone was talking about it. You were there? I'd love to hear.

Yeah, so part of the reinvent was like, as Firefly, most of what we do is to handle infrastructure as code. And by that, when people stopped at our booth and started asking question, most of the question were related to CDK and when are we going to support it and how deep are we going to support it? And by that, after we started investigate about AWS CDK, when we saw the huge benefits of using it. And since then, I keep hearing about AWS CDK and people trying to migrate into it from CloudFormation, from Terraform even, which is like crazy. And we keep getting questioned about how to do it well and how to migrate well and what's basically the complexity as we talked before doing that.

Yeah, I mean, I've been seeing a lot of like Terraform for CDK, CDK-8 projects, like CDK for Kubernetes. What's there like kind of maturity? What do you know about these projects, if anything? So basically the concept of CDK as we talked before, it's pretty new. The K9 CDK, the Kubernetes CDK and the Terraform CDK are a pretty new project. They're not still developed like completely. You can use them. And I know about companies that do use them, but the AWS CDK on that point is much more mature and much more suitable for usage. It also took some time, but it started a few months earlier and with the AWS, very coverage, and just basically the creating it over the cloud formation, which it's already a prepped up technology, just made it much faster and created the maturity of it much more higher.

It sounds almost like it's like competitive or a contradictory Terraform for CDK. How does that work? I'm trying to understand how like Terraform for CDK works. So, yeah, it's not that of a competition between them because always there's the huge difference about the multiple providers Terraform can hold. Right. And AWS CDK is like basically created- Not AWS specific. To AWS. In the manners of using it over AWS, there's no doubt that the AWS CDK is the right choice with the originality and the way deeper understanding of AWS resources. And on the other end, if you're gonna use like several providers and you need the versatility, then the Terraform CDK is a great choice for you. Still, as I said, not much matured and I still see a lot of pros about using the Terraform, the classic Terraform and not the CDK Terraform, but it's already on the way. And I guess in the next months, we're gonna hear much more about it.