People have asked why I use CloudFormation (CFN) and not other tools such as Terraform or AWS Cloud Development Kit (CDK). There are several reasons for this.
Firstly, I’m not a developer. I come from an infrastructure background and although understand scripting and programming constructs it’s not my expertise. This means no matter what tool I had to learn it was all relatively new to me.
Secondly, when I started my Infrastructure as Code (IaC) journey Terraform had been out for less than a year. I was also working with AWS engineers who only dealt in CFN templates and the boot-camp I attended at re:invent 2015 all focused on CFN.
Finally, no matter if you use CFN or another tool it all ends up as a CFN Template deployed in the account. So my view is that if you understand CFN and how it works natively you will be able to transfer all those skills to other tooling if you chose to do so.
That aside, here are brief introductions to the tools, and my thoughts on CFN vs Terraform and CDK
The Contenders
Terraform
Terraform by HashiCorp is a semi open-source infrastructure as code software tool that enables you to safely and predictably create, change, and improve infrastructure. It is multi-tenant, so lets you define both main cloud providers, and on-prem resources, in human-readable configuration files that you can then version control, reuse across projects, and share within the organisation. Terraform can manage low-level components like compute, storage, and networking resources, as well as high-level components like DNS entries and S3 Objects.
AWS CDK
AWS Cloud Development Toolkit is an open-source software development framework for defining cloud infrastructure in code and provisioning it through AWS CloudFormation. It allows infrastructure to be written in progamming languages such as TypeScript and Python, and is aimed at simplifying the bridge between software developers and infrastructure engineers.
AWS CloudFormation
AWS CloudFormation is an Amazon service that helps to model and set up your AWS resources. Creation is through the use of a template that describes all the AWS resources that you want (like Amazon EC2 instances or Amazon RDS DB instances), which CloudFormation uses to take care of provisioning and configuring of the resources for you. It takes what can be done via the console or cli, and converts it to a YAML or JSON file that can then be version control and managed at scale.
The Battles
CloudFormation vs CDK
So the first question is why is there CloudFormation and CDK.
I think CDK is AWS’ attempt and keeping people from going to Terraform, although it does offer integration with Terraform. It moves from the YAML/JSON approach and allows infrastructure to be written in a number of programming languages. For me this is suited to full/native DevOps teams that can choose a single programming language and write both the infrastructure and application all in the same language. As a software development framework it alows the modeling and provision of cloud application resources using familiar programming languages.
If you are happy with the resources being in CloudFormation, and a separate pipeline to deploy, I’d argue just go stratight to CloudFormation and have separate infrastructure and application code. If developers come from a software background and more comfortable with programming languages then I can see CDK being a suitable tool to give the flexibility for full stack developers.
CloudFormation vs Terraform
To me Terraform was sold as a single coding solution for multi-cloud. Something where you could write code that was cloud agnostic such as “I want 1 server” and Terraform would handle the rest in which ever provider you pointed the code to.
Sounds great right!
However I have found that it’s not so easy. Rather than one piece of code that can be run against multiple clouds you still need to re-write code if you move between clouds as primatives of resources are differnt and Terraform doesnt abstract things completely. Don’t get me wrong Terraform offers several advantages over CloudFormation and often has capabilities before they are available native in AWS tooling, but if I am only going to use AWS there are benefits for not using it and in some instances you might choose to forgo the extra options to be 100% AWS native.
comments powered by Disqus