Some months ago I joined a new team, they were on AWS and using cloudformation for some stuff and, a lot of changes were made directly in the console.
After some discussion we’ve decided to start fresh on a new infrastructure code, with some constraint in mind:
- We are not an OPS team but we are managing the infrastructure by our self.
- We want no manual action in the AWS console.
- The languages we are using in the team are
GOfor the backend andscala/pythonfor data.
We have considered to re-work with Cloudformation and also with Terraform, but since no-one wanted to written thousands of lines of YAML we’ve decided to use AWS CDK.
After all this journey of building our new stack, I can give you these 10 things to know before starting a CDK project (but I can already tell you that this is awesome).
1. Write code in a real language, not YAML
You probably know that if you have ever looked to CDK, but despite other infra-as-code technology you can write your stack in real language.
Why this is better?
- You can keep your favorite tools to monitor your code, such as your IDE, your linters, quality checks …
- Describe your infra using an object model.
- You can do unit test your code. (This one is the awesome part 🙌 🙌 🙌)
2. CDK support multi-language based on JSII
JSII is a framework developed by the technology that enables the CDK to deliver polyglot libraries from a single codebase!
Currently AWS CDK is supporting:
- Typescript / Javascript
- Java
- Python
- .NET
- GO
This is awesome you can choose your favorite language in the list and start building your stack.
⚠️ This is not that easy!
In my team, since there is no GO support in CDK we’ve decided to use Python because this is our second language.
To be honest, this is not a bad choice everything works fine but it has some limits of not using Typescript/Javascript.
Why typescript / javascript is better?
All components are written with typescript at first, so you are sure that they will work for you. With other languages, it works perfectly if you are using default CDK constructs but as soon as you are using 3rd party constructs it less certain that it will work.
And you can also have some weird documentation problems (see issues below).
3. CDK hides complexity
Despite cloudformation or terraform where you have to write everything you want to have, CDK provides high-level constructs that do the work for you.
For example, if you want to create a VPC with a set of subnets and associate Nat Gateways it can end up with a thousand lines of code CF or TF.
With CDK most of the stuff is done automatically for you and you, as you can see with the code below.
subnet_configuration[0] = ec2.SubnetConfiguration(
name='Public',
subnet_type=ec2.SubnetType['PUBLIC'],
cidr_mask=21
)subnet_configuration[1] = ec2.SubnetConfiguration(
name=name,
subnet_type=ec2.SubnetType['PRIVATE'],
cidr_mask=21
)vpc = ec2.Vpc(scope=self,
id='test-vpc',
subnet_configuration=subnet_configuration,
max_azs=3,
cidr='10.0.0.0/16',
nat_gateway_subnets='Public',
enable_dns_hostnames=True,
enable_dns_support=True,
)
4. CDK is based on cloud formation
This one is really important to understand, CDK outputs some cloudformation code and apply it to your AWS account. So if something is not available in cloudformation it means that there is no chance you will be able to do it with CDK.
But if like us you had a cloudformation stack before or if you want to import a 3rd party cloudformation script, you can do it.
# This code use a datadog CF template in a CDK stack.
cfn.CfnStack(
scope=self,
id='PolicyMacroStack',
template_url='https://datadog-cloudformation-template.s3.amazonaws.com/aws/datadog_policy_macro.yaml'
)
5. 🌬 CDK has a fast release cycle
I’ve started my CDK project 4 months ago using version v1.42.0 of CDK.
The actual version (when I write this article) is v1.74.0, which means that I have made 32 version updates on my actual stack.
So be prepared to upgrade your dependencies all the time.
6. Experimental higher-level constructs
Related to point 5, be warned that if you are using Experimental constructs you can expect some breaking changes.
Experimental: Higher level constructs in this module that are marked as experimental are under active development. They are subject to non-backward compatible changes or removal in any future version. These are not subject to the Semantic Versioning model and breaking changes will be announced in the release notes. This means that while you may use them, you may need to update your source code when upgrading to a newer version of this package.
The good thing is that for every construct available (even if they are experimental) you still have access to CFN Resources which is basically a wrapper over cloudformation and these resources are always stable and safe to use.
7. Fine-grained assertions are only available for Typescript
As I said before you can unit-test your infrastructure. That being said if you want to use the full power of testing with CDK, you are kind of stuck using javascript or typescript because you can use the fine-grained assertions framework.
Fine-grained assertions test specific aspects of the generated AWS CloudFormation template, such as “this resource has this property with this value.”
These tests help when you’re developing new features, since any code you add will cause your snapshot test to fail even if existing features still work. When this happens, your fine-grained tests will reassure you that the existing functionality is unaffected.
These fine-grained assertions are awesome because this makes it easy to test for real your expected stack.
https://docs.aws.amazon.com/cdk/latest/guide/testing.html
8. Nested stack vs Construct
If you have a lot of components in your stack at some point the question will be how to structure it.
You can use a lot of classes that extend Construct this the way most people are doing because before last week it was impossible to run a proper cdk diff to see what will be changed in your stack before deploying it.
The problem with using Construct is that you can reach the 460,800 bytes limit from CloudFormation, and you can reach this limit quickly because CDK is doing a lot of stuff for you behind the scene.
So in that case you can use some Nested Stacks, the problem was that when you were using nested stacks you were totally blind before applying changes. But last week Cloudformation has announced that changesets now support nested stacks.
So if you want to split your stack, please use nested stacks now.
9. CDK is multicloud
CDK is a project from AWS, but now you can use it as a multi-cloud tool since Hashicorp has released CDK for terraforming.
What it changes is that your CDK build will output some TF files, so it can apply in any cloud provider because terraform supports most of them.
CDK for Terraform: Enabling Python & TypeScript Support
Today, we are pleased to announce the community preview of the Cloud Development Kit for Terraform, a collaboration…
As you can see this project is really new, but it gives hope in the future of CDK and fingers crossed🤞 that it will become a standard even outside of AWS.
10. CDK everywhere (CDK8s, projen …)
CDK is such a good idea that eladb (the creator of CDK) uses the CDK philosophy everywhere.
cdk8s is in beta and this is CDK for kubernetes, it is AWS agnostic and can be used on any K8S project.
Even if this is a beta, you can already use it in production, the only visible tradeoff is that all kubernetes features are not implemented yet.
eladb has also a side project called projen that allows you to create typescript/javascript project with a init script that maintains your config files (package.json, tsconfig.json, .gitignore …).
Conclusion
I don’t regret to decide to use CDK instead of other technologies, it makes the work WAY easier and all the team understands what we are doing (not only the ops part of the team like before).
This is a work in progress tools, but almost all major AWS component are already well covered so you don’t have to worry when you start building your stack and with less than 10k lines of codes we have built a complete infra where we managed a lot of components (VPC, subnets, security groups, EKS, Elasticsearch, secrets, IAM, monitoring …).
My advice is to test CDK if you want a build a new stack, you will be convinced by your self after a few hours of using it.
Top comments (3)
From having worked on a number of CDK projects, I will say the
Restriction is a deceptively hard one to aspire too. I've often found that for our circumstances, it's most optimal to have very very few things manually created in an account, prior to launching the CDK project. If you've managed to stick to that, congrats! However I've often found binary restrictions like that to be more of a self-implied challenge than something that returns value.
I also like it! Compared to Terraform, I still like the fact you can easily rollback changes (since it's based on CFN) whenever something was broken. Also implementing AWS custom resources (e.g. for creating SecureString typed SSM parameters) with CDK and Lambda is really easy.
Whats the difference with Pulumi?