Man, I don't miss CloudFormation. If you want to do anything interesting at all (like being able to spin up turn-key ad-hoc stacks for developers that are mostly the same as your main environments), then you have to parameterize everything, and passing data around CloudFormation templates is just awful--what you want is functions and data structures but CloudFormation gives you "nested-stacks" and you have to encode most of your data structures as strings and "parse them out" with the YAML builtin functions that they provide (e.g., `{"Fn::Split": "foo,bar,baz"}` will evaluate to `["foo", "bar", "baz"]`, but good luck if you want a list of objects). Each stack also has a limit on the number of parameters you can pass, and since you can't really pass struct-like data (e.g., `"Foo": {"bar": "baz", "qux": "..."}`) you end up flattening that struct into N parameters (e.g., `"FooBar": "Baz", "FooQux": "..."`). You can try to plumb things through SSM or SecretsManager, but each stack also limits the number of parameters you can pass there as well.

Basically, CloudFormation is like the shittiest programming language you've ever encountered. People will argue that it's supposed to be simple because it's just YAML, but that's bogus--we clearly need to be able to do complex things in this space or else CF wouldn't provide these hacky functions. We pretty clearly need some sort of expression language if not something more robust, since that's the direction all of these "it's just YAML!" tools are going (CloudFormation, Terraform, etc). CloudFormation might actually make a decent "assembly language" for an infrastructure-as-code backend (although extending CloudFormation for third party services was still far too difficult last I checked--basically you had to run your own lambdas) that some higher-level tools might generate, but it's a mess for anything that isn't a toy.

> Not a great article

Well, duh, it's a Stackery ad posing as an CF best practices article; if the superficial meat was any good, it would distract attention from the ad.

Having written more CFN than I care to remember CDK is a breath of fresh air. It has a multi-level API that deals with the relationships between resources in a much cleaner way than plain CFN. However, at the lowest level you can still write basically CFN in code. But CDK has so much more. It includes multi-language support, unit testing, compile time checking for errors, etc.

Reading CDK's introduction page, it seems that, similar to CloudFormation, it uses pre-made components, just at a higher level. Those components are then translated into a CloudFormation template[0]. Is that correct?

Might it be more accurate to state that CDK is a higher level version of CloudFormation, that abstracts away unimportant details?

[0] https://aws.amazon.com/cdk/

I couldn't agree more. Cloudformation is a nightmare in my opinion and never should have seen public release. CDK is what Cloudformation always should have been.

CDK is the first time I experienced the benefits of TypeScript. If nothing else it’s a great playground to learn that stack. Testing stacks in the CDK is pretty rad.

What would you flag as the biggest differences between the two?

Not at all. I don't think most people really grasp what CloudFormation is.

I've had too many CF stacks get stuck in states that don't allow for rolling forward or backwards to buy this. You have to purchase a premium support plan to get access to the AWS personnel who can help you out.

CF does actually kind of try to behave transactionally, which is interesting--you don't often get stuck between states like you do with Terraform, but I rarely have had much of a problem getting Terraform out of one of these states either.

This isn't to speak about the abysmal expressiveness of CloudFormation. Reuse is a joke--I'm tempted to call it a programming language in which you encode the AST manually as YAML/JSON, but that would be overly generous because any programming language AST allows you to express the concept of a function that takes complex arguments (e.g., an object, list, or list of objects).

Further still, if you want to extend CloudFormation to support third party services (e.g., if you want to create a user pool in your identity management provider for your new stack, or otherwise manipulate non-AWS APIs), you have to write and run your own lambdas--which each require their own infra-as-code--which just takes a lot of effort (not to mention how hard it is to write these correctly) and so you end up compromising with a half-manual workflow, missing out on much of the promise of infra-as-code.

I don't love Terraform, mind you. I think there's a Better Way out there somewhere (maybe it's Pulumi or CDK, I'm not sure), but CloudFormation is brutal.

> more reliable

This is... quite the assertion. Terraform has historically been _far_ more reliable than CloudFormation, and perfectly capable of getting itself into unrecoverable states. Furthermore, the behaviour has _never_ been predictable - CF only even grew the ability to preview changes relatively recently.

(Disclaimer: I worked on Terraform at HashiCorp, and on other provisioning tools since).

The stregth of TF is the community and quality of docs. I use providers to manage an infra that is a mix of AWS + Heroku + external services like Rollbar and that just comes easy with TF. The point of it being paid (although I don't use any of their paid services), is that it is their core business and they are forced to continuously improve on it. TF 5 years ago sucked, but TF in 2021 is super smooth.

The only problem is Cloudformation is strictly AWS resources, so unless you're absolutely 100% sure you'll never need anything outside of AWS ecosystem, I always recommend using TF.