Hacker News Reader

Comment by kennu | Hacker News Reader

That's right - use AWS CDK instead. You don't have to worry about the low-level CloudFormation syntax and details. I switched a few years ago and haven't looked back. CDK keeps getting better and better, also handling things like asset deployments (Docker images, S3 content, bundling), quick Lambda updates with --hotswap, quick stack debugging with --no-rollback, etc.

View on HN

I've developed cdk for about 6 months now and it seems to me like a great idea.

However, the implementation is quite lackluster.

- It's very slow. Deploying our app from scratch takes >30 minues. An update of a single lambda (implementation, not permissions) takes about 3-5 minutes.

- Bad error information. On an error, cdk usually just reports which component couldn't be created. Not why it couldn't be created. That information you 'might' find in the aws cloudformation console, or not.

- It's buggy. Some deployments randomly fail because cdk couldn't find your cli credentials. Sometimes resources can't be created. In each case it works if you deploy again...

I suspect that most shortcomings that I experience are due to cloudformation. I'd really be interested in a 2.0 version that is either highly optimized or polished, or works with a different intermediate abstraction entirely. Updating and validating a tree of resources and policies should not be that difficult, at least not for AWS.

I think that the --hotswap option does what you are hoping for speedier updates. It allows CDK to update some cloud resources directly (e.g. Lambda function code) so that they "drift" away from the CloudFormation template definition. It's good for quick development.

CDK is terrible and way too low level for most apps, and worst of both worlds for code/declarative IaC (verbose & cognitive overhead heavy way to try to author code that generates a CF template - that still may not work).

Use AWS Copilot, it's like a reboot of Elastic Beanstalk complete with good CLI, made for the Fargate age and lets you extend it with bits of CF. (https://aws.github.io/copilot-cli/)

It sounds like your development is focused on containers, and perhaps Copilot is best for that. AWS CDK works very well when your application is based on many different kinds of cloud resources that need to be connected together, utilizing all the serverless and managed features of AWS.

Copilot supports serverless too (App Runner, serverless Aurora, DynamoDB, S3, CodePipeline etc). But if your app is using a huge nr of AWS features, you're probably over engineering it.

Sure it's opinionated enough that it won't fit every use case people have on AWS, but in most cases for new apps it's good.

I agree, and have the same experience. CDK is so much easier, much less verbose, and unit testable (at least to some degree).

Since resource importing is possible in CDK (not nice, but possible) you can even start using it if you already have resources that you do not want to recreate.

I'm always surprised that more people arent aware of CDK. Its an extremely powerful way to write software. Especially once you get good at it. CFN pales in comparison, CDK to me feels like the future of software development.

Maybe CloudFormation is too entrenched at the moment? I think CDK became publicly available in late 2019 or early 2020. I haven't used it because I'm currently working on a project using Serverless (thin layer on top of CloudFormation) with no easy way to slip any CDK in.

My comments are my own and don't represent my employer.

Almost every new service built inside Amazon uses CDK. I too am surprised that more people aren't aware of it. And you're right once you get good at it you can spin up infrastructure incredibly quickly with minimal guess work.

CDK was not used extensively at my org a couple of months ago. I agree it’s light years ahead of everything else though.

Oh that's interesting, in my experience across the Books Org and InfoSec its being widely used.

I was at a point willing to try it and what dissuade me was just that I also needed to have nodejs added as a dependency to my project.

Yea the nodejs dependency is an abomination. The cdk also requires a nodejs version newer than what comes on many linux distributions so you end up installing a custom nodejs version just to run cdk.

I don’t know why they picked nodejs over a more sensible language such as python3 which comes installed almost anywhere or golang which is easy to distribute in binary form and relatively reverse compatible.

The aws cli really got it right: just let me install a standalone binary and call it a day.

AWS CDK also works with Python. However, in my experience, TypeScript-based CDK projects are more productive to develop, due to all the built-in error checking and autocompletion features in Visual Studio Code. Node.js also provides a more coherent environment with the package.json structure, which defines all the scripts and dependencies etc. Python-based CDK projects seem to include more "custom hacks". Because of all this, I prefer to use TypeScript for CDK even if the actual application to deploy is based on Python.

Regardless of what language you use to write your cdk stacks, the cdk cli application which transpiles your cdk stacks into cloudformation requires nodejs. So in reality cdk requires nodejs — always — and then whatever language you are writing the stacks in as well. It becomes a pain in the ass when you have a python application which is defined in a python cdk stack, but you still need nodejs to transpile your python cdk stack into cloudformation.

My main gripe is that the cdk cli should be distributed as a standalone binary so I don’t need to install nodejs to deploy my project.

Ok thanks for clarifying. I guess we already have Node.js everywhere where CDK is used, so never noticed it. I can see it's uncomfortable when that is not the case.

Terraform CDK does this, but instead for just AWS it does it for everything.

CDK is great but because it compiles down to CloudFormation it is slow slow slow.

That's very true. :-( I really don't understand why AWS doesn't optimize the CloudFormation backend. I don't see any reason why it couldn't update resources basically as fast as the APIs allow.

... or faster.

Yuck - the CDK is everything I dislike about IaaS. Not everything needs to be actual code.

Complexity management is an often overlooked parameter of reliable infrastructure.

YEah but have you ever managed a large CFN project. You'll wish you had something more expressive than YAML

Yes, I have. Strongly prefer plain CF.

The purpose of CDK is exactly to reduce the complexity of your IaC. It automatically sets up all kinds of defaults, such as required permissions between different cloud resources that need to talk to each other. The underlying complex things are handled by AWS-managed library code.

This doesn't even include one of the most useful features of CDK: truly modular components. I can create a module used 100 times and all you have to worry about is the constructor and inputs instead of the nightmarish lack of reusability in other IaC.

You can also dump the CloudFormation template to a file to inspect it or feed it into other tooling.

How does that differ from terraform modules?

Same here. I used TF for about 2 years and switched to CDK early 2020.

It used to have a lot of rough edges, but that's (mostly) not the case anymore.

Pulumi is also nice for non-AWS related stuff.

Reply on news.ycombinator.com