Might it be more accurate to state that CDK is a higher level version of CloudFormation, that abstracts away unimportant details?
CloudFormation is just JSON or YAML (treated as assembly by CDK, by spitting out a CFN template after synthesis)
To summarize their best practices:
* don't put creds in templates
* reference other parameters outside of the template, e.g. in Systems Manager Parameter Store
* make your code readable
* add comments
* check your code
Except for the second, all of those are fine practices for maintaining any code.
The one best practice that's actually relevant to CF is to store parameters in SSM. Yet, they mention that drift is a problem with CloudFormation. So... why do you want to store parameters to your stack in a service that allows them to change independently of the stack?
Maybe there's an argument for doing this, but they don't explain it. It's just a "best practice."
They don't mention a major use case for CF, namely CI/CD. The article finishes up with a pitch for their template designer.
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.
Many of us now believe that CloudFormation is best described as the assembly language of AWS infrastructure: you can hand-code it, but it's challenging and verbose, and there's a lot of detail you have to get involved in.
CDK is the high-level solution to this challenge. With CDK you describe your infrastructure in terms of high-level constructs such as classes. Your stacks are described as applications instead of YAML templates. You can use many different programming languages including TypeScript and Python, and code is reusable. You can even vendor custom construct libraries to share within your org, or openly via npm.
I've become a convert since CDK came out - it's been ages since I've handwritten CloudFormation templates.
Raw HCL2/Terraform is marginally better IMO with being able to pass around more complex structs and function calls that don't have to be expressed as JSON dicts, but still remaining declarative to be able to create a dependency graph internally.
All of this is why CDK now exists to be able to express these things as TypeScript or Python and spit out the corresponding CFN or TF.
It's also worth noting that AWS added support for additional providers a while back so the CustomResource+Lambda you're describing isn't the only way to interact with non-AWS APIs.
I'm actually curious what you're using - you've shit all over a bunch of things without providing any real alternative.
CF json/yaml is essentially declarative asm for AWS resources.
CDK is how you use popular higher level languages to generate it, and there are some friendlier-than-raw-CF options in between (like SAM).
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.
But I may be ignorant and would love to hear if and how CF beats TF.
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.
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).
New-AWSTemplate -Resources @{
$OAI = @{
Type = "AWS::CloudFront::CloudFrontOriginAccessIdentity"
Properties = @{
CloudFrontOriginAccessIdentityConfig = @{
Comment = "Access to the bucket"
}
}
}
....
}
I've tried out CDK but honestly it seems very opaque and hard to understand, I want to give it another shot but it just doesn't seem to be a direct translation from CFN templates...
1. Don't