I just started using CDK for a project, and after having fought with terraform and trying pulumi, I have to say CDK is a breath of fresh air. Really well thought out, makes doing things the right way easy as well.<p>The biggest difference I can see between CDK and pulumi (other than CDK only being for AWS) is that the CDK is more opinionated. When you spawn a new database, it'll automatically create a secret in secretsmanager, and set up rotation etc. And since it can assume IAM, it generates granular policies for you easily with calls like `dbInstance.grantRead(lambdaInstance)` etc, instead of you having to manually construct a JSON policy.<p>I really think the pulumi / CDK method of "Use a real programming language to generate a declarative spec" is the right way to go.<p>For those keeping score:<p>- chef/puppet: imperative language, imperative effects<p>- ansible: declarative language, imperative effects<p>- terraform: declarative language, declarative effects<p>- CDK/Pulumi: imperative language, declarative effects<p>Not to mention, CloudFormation actually allows ~transactions, which is something you can't really get without cooperation from the cloud provider<p>Edit: I incorrectly mentioned that terraform uses cloudformation to get transactions, but it does not
Honestly, always surprised I don't see more about CDK. As far as I am concerned, this is the future of software development. Object oriented infrastructure, where you create abstractions over pieces of infrastructure, put them into a library, and then use them as composable components is incredibly powerful. We are just scratching the surface, and through libraries like constructs, large swaths of development will be automated.<p>Again, this is incredibly powerful.<p>For those that don't know, cloudformation is now often thought as the assembly language of cloud development, with CDK the higher level language.<p>I work at Amazon, and here we have a growing library of internal CDK constructs that make creating internally facing infrastructure, that works with other infra, incredibly easy. Even the databases that other teams have, their queues, etc, can be vended as common infrastructure packages, and then consumed, attaching your own AWS resources to theirs via library imports.
I'm pretty happy to see this. I just inherited a bunch of projects that all have entire tf stacks inside them, and I'm itching to just replace it all with some actual code.<p>Terraform was great, once, but over time as general cloud complexity got above a handful of some ec2 machines and some networking rules, it becomes a real burden to manage. Now all our devs are struggling to manage kenesis or ecs/fargate stuff with terraform. HCL is <i>so close</i> yet so far from an actual language that it's infuriating to use as a developer.<p>I think I'll bite the bullet and go all in on this, since the rest of our codebase is all ts anyway. Pulumi would be the other option, but at this point we're so sucked in to aws anyway, the only reason to use that over this (not locked to aws) is moot for us.
CDK is absolutely brilliant. My eyes glaze over when I see lines and lines and pages and pages of CloudFormation/Terraform config... sometimes spread over multiple files and having to manually join them in them head to get the full view of the infrastructure.<p>But CDK reads so beautifully and gets rid of so much noise in these templates that I don't care about. Unfortunately... the devops people and those who hold they keys to cloud resources at my current company (and many other companies) are so all in on Terraform that most won't even consider CDK/Pulumi as an option despite the CDK/Pulumi paradigm being objectively better than CloudFormation/Terrform paradigm.
CDK is quite great.<p>My only gripe I have with it: even though you can synthesize raw CloudFormation templates from a CDK project using `cdk synth`, you can't upload the artifacts without running `cdk deploy` (so you can't actually use the synthesized templates to deploy, because the artifacts aren't there).<p>This is in contrast to SAM which does exactly this with the `sam package` command. Generates raw CloudFormation and uploads all assets to S3 in the right place.
This is great if you only target AWS and only have a small scope, but for anything else it sucks (just like CloudFormation itself).<p>This is one the main problems with most of the CDK-abstracted SDKs for clouds in general where you're essentially just going to re-implement Terraform or SaltStack or Ansible but with your own code that doesn't have the same portability in technical and human terms.<p>That knowledge about the in-house system is useless elsewhere, and anyone coming in from the outside can't use any pre-existing knowledge. This is of course only a problem in larger scopes, say a larger company with an internal team that does the Ops-leaning side of DevOps.<p>A company that is larger might simply delegate an entire set of accounts and infrastructure to individual teams where they have to sort everything out themselves, and a company that is smaller is essentially the same as a small division in a large company.<p>And then you still have the problem if the glue between your AWS cloud, Google cloud, Cloudflare and whatever Git provider you use. No CDK covers that the way something like Terraform with delegation to providers does where you have a standard data format where you can transport information between providers. If you want to create a repo in GitHub, preset some configuration and contents, add that repo to a CD solution that you run on Kubernetes on EKS in AWS with delegated accounts per EKS workload and then connect Cloudflare to ingress ALBs, that's at least 4 different APIs you're talking to with incompatible interfaces. Most of them have CDK's so your interface becomes your own implementation that you now have to maintain. Delegating that to a specialised tool works much better.