Infrastructure as Code (IaC) tools
Table of Contents
Managing and Deploying Resources
- Define your desired infrastructure in a configuration file.
- And then you can re-deploy it again and again.
- Recreate it in another region (duplication).
- Desired State configuration (DSC).
- Using automation to ensure your configuration doesn’t drift from the original setup.
IaC options
- ARM (Azure Resource Manager) templates (JSON)
- Bicep (A form of abstraction - Bicep files are compiled into ARM templates)
- Terraform
- Chef, Puppet
- Powershell Scripts
- Other type of code (using SDKs and common languages like Python, Java, etc.)
- Pulumi: https://www.pulumi.com/
- There’s also SST which is built on Pulumi. Should be faster and more feature complete than CDK. https://sst.dev/
Reading material
This is a good resource https://serverlessland.com with many examples in the different IaC frameworks (and different runtimes, if you ever want to work in other runtimes too)
Deploying and managing Lambdas - CDK, Terraform, or SAM?
https://www.reddit.com/r/aws/comments/1ihsfqo/deploying_and_managing_lambdas_cdk_terraform_or/
In favor of CDK
- It’s crazy simple with cdk and if there’s a problem you get support through AWS.
- CDK. This baby will bundle your nodejs lambda and tree shake everything, with tons of customizations.
- Treeshaking - Remove dependencies that aren’t required so the final bundle size is smaller
- With not more than 100 lines using CDK, you can configure a fully serverless API on AWS: Route53 + API Gateway + Lambda + Layers + DynamoDB + Permissions
- Cdk! There are constructs that will bundle your code in a docker environment very smooth and easy
- Came from TF, switched to CDK. Deployment is painstakingly slow compared to TF, but easier to grasp, super flexible and it’s just TypeScript. Autocompletion is great as well - modern LLMs also know their fair share of CDK which is also a great help.
- SAM is simpler initially, and closer to the Serverless Framework. CDK is better if your infrastructure starts getting complicated with other resources outside of the basic Serverless ones.
In favor of Terraform
- If you or your company uses Terraform to manage the state of all other cloud resources, it probably makes sense to use Terraform to manage the state of our functions and a custom process for bundling and uploading the function code to S3.
- This eliminates the need to introduce another IaC tool
- With Terraform, you can also set-up a custom Terraform module for our Lambda functions that configures the necessary integrations (environment variables, layers/extensions) with our monitoring tool (Datadog), so metrics and logs are shipped out of the box.
- Terraform is used for more than just AWS. We use it for Github, AWS, Azure, GCP, Snowflake, Databricks and a few others as well. The commonality of approach gives us some advantages. It’s the Devil We Know but it allows us to build pools of expertise addressing pockets of ignorance. If we were to choose a mix of IAC solutions we’d end up with pools of ignorance drowning out pockets of expertise.
- Terraform is good if you don’t like Cloudformation (maybe too slow? Maybe you’ve had problems trying to rollback? idk), or if maybe you’d like to be a little closer to multi cloud (even though the transition would still require a lot of work)
- CDK and SAM depends on the shortcomings of CloudFormation. For me, that is enough to not use them, Ill stick to terraform.
- always used terraform and have my complaints, but ultimately it always does what i need. Also nice that I can do multi cloud architecture deployments with it.
Other comments
I used CDK and CDKTF (CDK for Terraform), both have their advantages and disadvantages. CDK has good highlevel constructs but compiles to CloudFormation so has all CloudFormation disadvantages. CDKTF compiles to Terraform but lacks CDK highlevel constructs.