AWS Cost  Optimization | DevOps Transformation

  • About Us
  • Services
    • AWS – Cloud – Optimization
    • AWS Well-Architected Framework
    • Cloud Migration Strategy
    • Cloud Native Developers
    • DevOps-Transformation
    • Digital Marketing
    • Disaster Recovery – Public Cloud
    • Managed Cloud Services
    • Web Application Firewall
    • Web Development
  • Industries
    • Automotive, Transportation, and Logistics
    • Consumer Goods
    • Education
    • Financial Services
    • Food & Beverages
    • Information Technology
    • Manufacturing
    • Media & Entertainment
    • Oil & Gas
  • Blogs
  • Contact
REQUEST A QUOTE

Difference between Terraform vs Cloudformation

Wednesday, 18 November 2020 / Published in Cloud Migration Strategy, Cloud Native Developers

Difference between Terraform vs Cloudformation

This is the most common question that frequently pops up once in a while – why use a third-party tool if AWS services have done essentially the same thing.

There was argument been made in past with fewer compelling reasons on the said topic, but now the work of cloud formation has improved tremendously over the last couple of years. However, if to choose again today, I think I would still stick with Terraform. Here are some of the reasons for this.

Language

Terraform uses HCL (HashiCorp Configuration Language), developed to strike a balance between being human readable as well as machine-friendly.

CloudFormation, on the other hand, uses either JSON or YAML.

In general, YAML is significantly easier to read and author than JSON, but it still forces you to have multiple nested scopes and everything goes horribly wrong if you mix up indentation somewhere. In contrast, HCL normally only has one or two scopes and enforces some basic Go-inspired formatting hygiene that makes it easier on the eyes.

Terraform has a rich set of string interpolations and built-in functions, including conditionals and (to be natively supported soon) loops, which allow modeling quite complex logic in DSL without having to resort to a fully-fledged programming language (although this can be done transparently with external data sources). The intrinsic functions of CloudFormation are noticeably limited in comparison.

Another thing in favor of Terraform is that it makes it easy to reuse code using modules and gives you a lot of leeway in structuring your projects the way it makes the most sense to you. CloudFormation supports nested stacks, but in general, you have to keep all your infrastructure code in a gigantic file (or several) in one project repository, whereas with Terraform you can slice and dice however you want. For regular humans, working with several 100-line files is usually much easier than with a single 5,000+ line file. Modules can be stored on GitHub or public Terraform Module Registry and be easily versioned and shared across multiple projects.

State

Terraform keeps its state in a file. This file can be stored on disk, committed to source control (not recommended), or kept in S3 or some configuration management system. Whatever you choose, you must make sure that you don’t lose or corrupt your state file, or don’t accidentally use a state from the production environment while deploying to test. It’s more difficult to shoot yourself in the foot after the introduction of workspaces (previously called ‘environments’), but in the early days, we did get a few battle scars dealing with the Terraform state.

In contrast, CloudFormation runs on AWS infrastructure and manages the state for you, so you don’t really care how it does that. Unlike Terraform, CloudFormation also tries to roll back the changes if they could not be applied (well, unless it gets stuck in UPDATE_ROLLBACK_FAILED state…). In addition, CloudFormation backend can receive signals from your resources, which enables an extremely useful option of configuring rolling updates for an Auto Scaling group. CloudFormation also doesn’t mind if a machine that triggered a deployment suddenly went down (as can happen with fungible CI/CD servers), whereas Terraform would need to recover from a partial update.

So, on the face of it, this looks like a case where CloudFormation wins. If we dig a little bit deeper though we’ll see that Terraform’s state file is a very powerful concept and one of its main selling points. It allows us to import, adopt, or move around resources, which means we can refactor our infrastructure at will without having to tear down and recreate resources.

Another thing that is possible in Terraform is managing configuration drift. Every time we run ‘terraform plan’ it fetches the latest actual state of the infrastructure and compares it to the desired state, defined in the configuration files, and the known state, which mirrors the actual state when we last ran ‘terraform apply’ and is stored in the state file. If our infrastructure no longer matches the desired state (usually due to some out-of-band changes).

Terraform would compute the diff and suggest to bring it back in line with what’s described in our configuration by reverting the manual changes. As long as we maintain idempotent deployments, running periodic Terraform plans is a convenient way to detect and revert the configuration drift, and is, in fact, something that is done on schedule in our infrastructure provisioning pipelines.

Meanwhile, CloudFormation would stay blissfully unaware of any changes made outside its state. Try this quick experiment.

First, deploy a new CloudFormation stack to create a new VPC and a security group with no ingress rules:

AWSTemplateFormatVersion: ‘2010-09-09’   Resources:   VPC:     Type: “AWS::EC2::VPC”     Properties:       CidrBlock: 10.0.0.0/16     SecurityGroup:     Type: “AWS::EC2::SecurityGroup”     Properties:       GroupName: TestSG       GroupDescription: Test security group       VpcId: !Ref VPC

Configuration

Parameters make it possible to re-use the same template in various environments. For example, you may want to use cheaper EC2 instances in your test environment, and something more powerful in production.

Cloud formation supports up to 60 parameters that must be provided at runtime. There are several ways to do this. The simplest way is to simply pass parameters one by one and default them to something sensible. Alternatively, you can supply parameters in bulk from a file (you need to make sure that you are passing the correct file), import values from the output of another stack, or read them from Parameter Store. You can also decide to use a Mapping section and to look up parameters by some key (for instance, by environment).

Quality of life stuff (aka miscellanea)
Terraform validates the configuration files before trying to run the updates. It checks not only that all files use the correct syntax (CloudFormation has similar validation), but also that all parameters are accessible and the configuration as a whole is valid.

In Terraform, you can (and should) run a ‘plan’ step before applying any changes. This step tells you precisely what is going to change and why (with nice colors to boot!).

CloudFormation supports Change Sets, which are considerably less human-friendly and hard to make sense of.

Terraform can automatically format code, helping to maintain a consistent code style and making pull requests easier to read. JSON (or now YAML) fatigue which plagues CloudFormation developers is hard to imagine with Terraform.

Neither Terraform nor CloudFormation cover 100% of available AWS resources, but generally Terraform is known to support newly available resources months earlier than they are made available in CloudFormation. All new AWS functionality must have REST API and SDK support for the main languages when it is released. CloudFormation support, on the other hand, is optional. The open-source software shines in this case, as Terraform developers quickly jump in to add the functionality that they want to use.

Conclusion

So, does this all mean that Terraform is always superior to CloudFormation? Not really. There are some use cases where using CloudFormation makes more sense.

What you can read next

Stage to Integrate Scalable Jenkins on Top of a Kubernetes Cluster
cloud disaster recovery
All You Need to Know About Disaster Recovery
cloudservices
Advantages and Disadvantages of Cloud Computing Services

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Search for posts

Loading

Recent Posts

  • What is Future of DevOps in 2022

    0 comments
  • DevOps tools and software :-Increase DevOps agility, shorten releases, improve reliability and stay ahead of the competition with DevOps tools

    0 comments
  • 4 Major Benefits of Using Kubernetes

    0 comments

Recent Comments

  • New York Consultants on Jenkins on Kubernetes Engine – Cloud Stack Group
  • Parbriz auto OPEL ASCONA C Hatchback J82 1981 on Strategies and Process of Migrating Applications to the Cloud
  • Geam Porsche Cayenne 9PA 2010 on Strategies and Process of Migrating Applications to the Cloud

Add Wings to the Modern Enterprise with the help of a Global Cloud Platform

The platform of Cloud Stack Group provides numerous options that are beneficial to the organisation. It is necessary that we follow all the process as we share the result that is scalable, accurate and convenient to use.

GET A QUOTE

Cloud Stack Group is the pioneered and well-established company that is working on the newest and the latest forms of AWS services. Being in a competitive market for more than 3+ years we have served with our services to more than 40 industries and 50+ fortune global companies

MENU

  • About Us
  • Services
  • Industries
  • Blogs
  • Contact

OUR BLOGS

VIEW ALL
  • What is Future of DevOps in 2022

  • DevOps tools and software :-Increase DevOps agility, shorten releases, improve reliability and stay ahead of the competition with DevOps tools

  • 4 Major Benefits of Using Kubernetes

COMPANY INFO

+91 9687177221

info@cloudstackgroup.com

WE'RE SOCIAL

SUBSCRIBE NOW

Loading

© 2019-2022 CLOUDSTACKGROUP. ALL RIGHTS RESERVED

A SADADIYA INDUSTRIES LLP COMPANY

TOP