Moving Away from CDK
sst.dev
sst.dev
Unfortunately, we're in a weird position at this point in time. You're forced to make trade-offs, and none of them feel good.
- Writing JSON/YAML to model IaC via plain CloudFormation or SAM is an absolute non-starter. Just suffering and pain.
- Modeling IaC using HCL for Terraform isn't any better. I'm done writing configs in pseudo-languages. It sucks.
- CDK solves a lot of problems. But it's not without issue, and there's no denying that CloudFormation is dragging it down. I still think the self-mutating pipelines being themselves managed as IaC through the CDK app is how all CI/CD should be done.
- CDKTF is promising, but in infancy and doesn't seem all that mature for production apps. But if you're a heavy user of AWS, the lack of support for higher level L2/L3 AWS CDK constructs can be painful.
- Pulumi is perhaps a more mature offering, and something that I first got exposed to through Webiny. Definitely interesting, but the same lack of L2/L3 AWS CDK constructs is a pain point.
- Ion sounds like it'll be an extension of Pulumi with a catalog of high level serverless constructs, a subset of supported Terraform providers, and SST DX improvements. That really is exciting! But it's not out right now. Even if it was, migrating existing services to it would probably be too onerous to bother. And if you can't migrate existing services, it raises the question of whether or not it's worth it to keep new things on the existing flow as well instead of
At our startup, we currently use AWS CDK and mostly manage to work around the sharp edges. I've long felt that CDK is the right abstraction, but built on the wrong foundation. My guess was that something like CDKTF would win in the long run. But maybe it'll be Ion+Pulumi. I'm both optimistic about what IaC tooling will look a few years from now and sad at the reality of the situation today.
Counterpoint, yes, it is better. It's an extremely straightforward DSL, with easily understandable docs. Importantly (IMO), it's a declarative language, which is how infrastructure should be defined, because it a. produces exactly what you tell it to, without any surprises b. results in short* and easily understandable code.
*: Short is relative. I've worked with massive TF codebases. I meant that I don't have to spend LoC telling Terraform how to do something, I just tell it what the end result should be.
I had a system years ago that would build a network of machines in AWS, run a data processing pipeline, make an AMI, run tests, and submit the AMI to the store. It was easy to code up in Java using the straight AWS API and wouldn't have been hard to port to some other cloud like Azure. It did all sorts of things that Cloudformation couldn't do and it didn't lock me into a vendor.
Case in point, I'm in the midst of writing a massive Ansible playbook that builds highly specialized AMIs with EC2 Image Builder via Terraform. It could just as easily be used with Packer, to your point.
Some parts of it are monotonous, some parts of it are mind-bending, but all of it is more correct and idempotent than the myriad of scripts and runbacks it's replacing.