Imagine if all of your infrastructure configurations from AWS, Azure or Google could be replicated . This is infrastructure as code. faster and more accurately than you could click The of using infrastructure as code are: insane benefits , knowing you can redeploy to a given state safely. If god forbid your infrastructure vanishes Being able to sleep at night , check in changes, code review and build your infrastructure as a team Follow coding best practices I am going to be taking a look at both Terraform & CloudFormation. I used Terraform extensively at but for the sake of learning I decided to get my hands dirty with CloudFormation. Localz The two contenders is the communities answer to infrastructure as code. It is open source with over 12k stars, is cloud agnostic supporting . It is often less verbose than CloudFormation & has a great module system. Terraform hundreds of providers is developed and maintained by AWS, it is very tightly integrated and only supports AWS. The tight integration lends itself to having a great UI, being able to view all your stacks for a given account is great. It enables cross stack referencing with ease, which is also a massive win for modularity and breaking down that monolith. CloudFormation Command Line Interface & WorkĀ flow Terraformās most used command feature and . Since Terraform is cloud agnostic you need to explicitly say where you will store your state file, this is a part of the command. Running a Terraform is used to create an execution plan, against your state file and existing infrastructure. [init](https://www.terraform.io/docs/commands/init.html) [plan](https://www.terraform.io/docs/commands/plan.html) init plan A simple Terraform execution plan CloudFormation has a similar process where you create & execute change sets. You will use a combination of , and . is akin to Terraformās whilst is Terraformās & rolls both commands into one. [create-change-set](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/create-change-set.html) [execute-change-set](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/execute-change-set.html) [deploy](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/deploy/index.html) create-change-set plan execute-change-set apply deploy The main difference is you will be looking at and resolving issues through CloudFormationās UI, which is easy to use, even for me š. CloudFormationās ChangeĀ set Both Terraform's & CloudFormationās is a great place to have a manual check, in your continuous integration pipeline. plan create-change-set Using to wait on a manual inspection of the changeĀ set Gitlab . I believe followed by a used to be the de facto but now exists to replace them both. But in some cases especially deploying to production, you would want to follow good practice and inspect the execution plan before you executing it. I found CloudFormations APIās to be a little confused create-change-set execute-change-set deploy I thought in this case you would want to use a followed by a but that is annoying as explicitly needs to know whether you are creating or updating stack. So this would cause heartache in your continuous integration pipelines. But after further inspection, I believe you run a with a flag, and then re run without the flag. Iām still unsure of the recommended approach. create-change-set execute-change-set create-change-set deploy --no-execute-change-set deploy Misaligned State I ran a simple experiment where both tools created a simple EC2 instance. I deleted both instances and tried to run both deployment steps again. Hidden within Terraformās is a which is used to reconcile your state file, with the real world infrastructure. This means Terraform was able to detect the deletion & boot up a new instance. CloudFormation has no such reconciliation and depends on the existing stack. Thus it was adamant nothing had changed. The only fix for CloudFormation was to rename the EC2 resource. plan [refresh](https://www.terraform.io/docs/commands/refresh.html) I wouldnāt rely on this as a silver bullet for reconciliation and wouldnāt ever recommend manually playing with any stacks, that are managed by any tool. It will only lead to heartbreak š. Functions & Interpolation Intrinsic functions is one of of CloudFormation. Terraform does have a than , but I prefer the syntax that CloudFormation uses, the lack of quotations, dollar signs & curly braces can make for some more readable code. my favourite parts lot more functions CloudFormation I also found the occasional shortcomings of Terraformās interpolation in . certain circumstances A simple referencing comparison Conditional Deployments Conditional deployments are an important part of any deployment, you want to be deploying from the same stack whether its production or development. But sometimes production just requires extra resources, or vice versa. Only CloudFormation supports conditionals explicitly, you can tag each resource with a conditional flag. Where as Terraform requires you to make use of their (awesome) and . count parameter ternary conditional , so CloudFormation would require more repeated code. The count parameter is unique to Terraform Conditionals Example CrossStack Referencing One of CloudFormations most powerful features is being able to so easily cross stack reference. This makes it extremely easy to break up the infrastructure monolith! Cross stack referencing is aĀ breeze In the above example, the Networking Stack exports its , as . Which in my EC2 Stack I simply reference that Subnet using the . CloudFormation is also smart enough to know that the EC2 stack relies on the Networking Stack and DbSubnet1 ${branch}-DbSubnet1 Fn::ImportValue:Ā !Sub ${branch}-DbSubnet1 will refuse to delete it until its dependencies are gone. Modules Exclusive to Terraform way to break down your Terraform deployments. A Terraform module is essentially a collection of Terraform files & resources that define a set piece of infrastructure. It allows for inputs & outputs. To use the module, you simply pass in your inputs as variables and under the hood Terraform will pull in the module and execute the Terraform code as usual. modules are a very powerful Reuse of a terraform module Above is an example, where I define many instances in any region by simply using a reusable module. Without this module, I would need to define each instance and the associated Terraform code required to set up an instance in a new region. The reason why this is not the same as a CloudFormation stack cross reference, is that the Terraform state file would still contain all of the state. Where as with CloudFormation, the state files would be split between each stack making it more manageable. to accomplish the same task. The issue with nested stacks are that if a child stack fails the entire stack will. This makes for deployment pains & nightmares. Approaching CloudFormation using a and cross stack referencing is the way to go. CloudFormation uses nested stacks layered cake approach CloudFormation with a nestedĀ stack CloudFormation nested stack webĀ UI User Data & CloudFormation Init CloudFormation also features , which is AWSās way of taking your and turning it into state based configuration. It is extremely powerful and shouldnāt be overlooked. It allows you to run stack updates against instances and reconcile the state. Where as previously using user data you would have to terminate and create a new instance. CloudFormation init user data script A slice of CloudFormation Init Error Handling Maybe I was never very good at Terraform, but I have been preferring the way CloudFormations handles errors. The CloudFormation UI is really good and gives a good overview of your stack. I found that with Terraform errors, while they pointed you in the right direction it was still hard to gain an overall idea of what had happened. The CloudFormation Events UI traces your stack deployment, so you can easily see what errorādĀ out. Support You would think CloudFormation would support every AWS feature in existence, but . Because open source is the best, Terraform seems to have more AWS features. unfortunately you are wrong Take for example, , this feature has been and is still in the CloudFormation backlog. Where as Terraform had a contributor , and Terraform supports RDS IAM auth well before CloudFormation. RDS with IAM auth released for over a year gazoakley make a simple PR Another more important example, there is no CloudFormation support. Where as terraform has its own resources for . Key Secrets Manager secrets manager since April Open source software is myĀ favorite We canāt forget that Terraform is cloud agnostic, a big win. But I wouldnāt take it too literally as from what I have seen cloud providers are pretty good at sinking their tiny hooks into you through features, or specific codes like ARNs. But because Terraform is cloud agnostic, it can really be applied to anything that has state and an API. For example can be . Thus you can apply your skills youāve learnt else where in your stack! Kong API Gateway managed with Terraform Summary I enjoy both Terraform & CloudFormation as they are both a great step in the right direction. My Pros &Ā Cons has a great UI for both debugging and general overview of everything thats happening. Cross referencing is powerful & makes separating stacks easy, whilst I personally really enjoy the syntax. The lack of support is my real gripe, as itās not open source the thought of having to use custom resources or shell scripts to get certain features makes me cringe. š¢ CloudFormation is great because of itās vibrant community of open sources, itās simple module paradigm & itās cloud agnostic. Terraform can be hard to debug through the cli and often you end up with a large monolith repo that includes all of your infrastructure. You can break it down into modules, but it doesnāt quite have the same separation of concerns you can get with CloudFormation. Terraform If you enjoyed it be sure to give it a clap and check out Thanks for reading! both Terraform & CloudFormation !
