CDK - under Construction - should we use it for the next project?



Should we use CDK for the next project?

The AWS CDK (Cloud Development Kit) is great - and still in beta - so the question for the next project would be:

Should we use cdk or not?

This post will look at the state of the cdk. Also we provide our CDK Templates updated to the CDK Version 0.38 if you want to get started.

See this diagramm for the number of features, bugs and breaking changes of the CDK this year.

CDK convergion

The y scale show us the breaking changes. If a breaking change affects your CDK project, you have to update our code. But how breaking are these changes? Should they stop us from using the CDK?

To get an answer we also have to look at the number of features but also on the number of bugs. If the CDK is stabilizing, my assumption is, that we want to have:

  • small bubbles, because that would mean the main work of implementing constructs is done and only the new CloudFormation features will be added
  • dark bubbles, which means less bugfixes which hopefully means less bugs :)
  • bubbles at the bottom, so less breaking features

But what means “breaking change” in ammount of time we need to update a project to a new CDK version? Let’s have a look!

A few examples for that from our CDK Templates:

Some “breaking changes”

Change in 0.36: rename core module

This is an easy one. Text in changelog says:

" core: the @aws-cdk/cdk module was renamed to @aws-cdk/core, python: aws_cdk.core, java: the artifact cdk in groupId software.amazon.awscdk was renamed to core "

old

import cdk = require('@aws-cdk/cdk');

new

import cdk = require('@aws-cdk/core');

0.35 rename managedPolicyArn

This gives you a small task to think. The changelog says:

" iam: managedPolicyArns renamed to managedPolicies, takes return value from ManagedPolicy.fromAwsManagedPolicyName(). "

To solve this, you go to the CDK TypeScript Reference

and goto aws-iam/ManagedPolicy.

(Just searching for ManagedPolicy.fromAwsManagedPolicyName gives no result.)

The documentation shows you how to change the code.

old

   managedPolicyArns: ['arn:aws:iam::aws:policy/service-role/AmazonEC2RoleforSSM'],

new

 managedPolicies: [ManagedPolicy.fromAwsManagedPolicyName('service-role/AmazonEC2RoleforSSM')],

0.37 EC2 instance Autoscaling Group

This is one of the tiny number of small changes, which did not make it into the changelog 0.37, but 0.38:

" chore: fix build by conflict introduced with parallel PRs (#2992)

new InstanceTypePair was renamed to InstanceType.of. "

old

   const asg = new autoscaling.AutoScalingGroup(this, 'ASG', {
      vpc,
      instanceType: new ec2.InstanceTypePair(ec2.InstanceClass.Burstable2, ec2.InstanceSize.Micro),
      machineImage: new ec2.AmazonLinuxImage({generation: AmazonLinuxGeneration.AmazonLinux2}),

New

 const asg = new autoscaling.AutoScalingGroup(this, 'ASG', {
      vpc: albVpc,
      instanceType: InstanceType.of(InstanceClass.BURSTABLE2, InstanceSize.MICRO),
      machineImage: new AmazonLinuxImage({generation: AmazonLinuxGeneration.AMAZON_LINUX_2}),
      role: instanceRole,
    });

Breaking Workaround

Another possibility is to just use a fixed version of the cdk. But it is recommended that you update to a newer version soon. Because it is less work updaten minor breaking changes than to update a lot of changes.

Why CDK is better than pure CloudFormation

(and most other IaC frameworks)

  • Abstract constructs give you bundles of ressources with less code
  • e.g. you do not have to implement each resource of a test VPC, you just add a VPC
  • You can really code:
    • import data files
    • loops
    • AutoCompletion from editor
  • integrate with assets like lambda functions or Docker containers
  • write your own extensions
  • Embedded CLI to manage multiple stacks

and so on…

Bottom Line

If you just look at the number of breaking changes you could say the CDK is not stable enough. But if you compare the benefits i would still say:

Use it! (personal opinion)

[Update] Some comments said i was ignoring the evidence when coming to this conclusion:

What i meant is - compare for yourself the cost of the refactoring (which i thought is relatively easy) against the benefits of using the tool (which i think is good). The conclusion is different for each project and person.

Similar Posts You Might Enjoy

tRick: simple network 1 - Abstraktion und LoC

Vergleich Infrastructure as Code (IaC) Frameworks - tRick Ein Toolvergleich für Infrastructure as Code. Um effektiv AWS oder generell Cloud Ressourcen zu erzeugen, verwendet man zur Erhöhung des Automatisierungsgrades “Infrastracture as Code”, d.h. die Server, Datenbanken usw. werden in einer Sprache kodiert. Dieser Vorgang wird sinvollerweise über ein Framework, welches Tools dafür zur Verfügung stellt unterstützt. Aber für welches Tool/Framework entscheidet man sich? Hier werden wir mit Dimensionen für den tRick Benchmark Entscheidungshilfen geben. - by Gernot Glawe

More Tools - CDK Examples

We need more CDK examples In this github repo we focus on examples for every day work. While there are some nice examples for the fancy stuff like fargate, ecs and so on in aws-cdk-examples/typescript at master · aws-samples/aws-cdk-examples · GitHub, i felt that basic examples where missing. So we created GitHub - tecracer/cdk-templates: Templates for aws cdk - by Gernot Glawe

Getting around circular CloudFormation Dependencies: S3-Event-Lambda-Role

Getting around circular CloudFormation dependencies Several posts complain about the inability of CloudFormation to apply a Lambda event function to an S3 Bucket with an dynamically generated name. The standard UseCase is an S3 Bucket with a Lambda event notification. In this special case the Bucket has a dynamically generated name. This cannot be done by pure CloudFormation! How to work around this circular depency? Let me show you an easy way: - by Gernot Glawe