An Introduction to Terraform Providers
If you are a professional outside of the DevOps (Developer Operations) workspace that has had to interact with Terraform, you may have many questions with few answers. This is very normal, as Terraform itself represents the most popular implementation of a broader change to the very nature of how software is deployed. Whether you are Backend engineer with an API consumed by a Terraform Provider, or a manager trying to discern the nature of the tickets you are reviewing, hopefully this article should give you a high level understanding into how Terraform operates.
Terraform is Infrastructure as Code
Infrastructure as Code is the process of using code itself to manage the hardware and networking infrastructure that code is deployed through. The benefits of doing so are many and diverse. For example, this enables documenting the state of your infrastructure in easily readable and versioned files you can reference in the future. You may also choose to programmatically update your infrastructure through code pipelines like Github Actions. This code that is used to describe high-level resources like servers, load balancers, and data storage is stored in .tf files. This suffix indicates that the files uses Hashicorp Markup Language (HCL), a declarative language specific to Terraform that describes the intended state of digital resources.
[Example main.tf code from https://developer.hashicorp.com/terraform/tutorials/aws-get-started/aws-build ]
These files would usually be stored in a source control repository, such as Github, so that other engineers can reference the file to check or change the state of their environments. As you may have noticed, the example references a resource and a provider. A Terraform resource defines the desired output of a Terraform file, such as in this case a computer server in the form of an AWS ec2 instance. A Terraform provider is a plugin that is used to reference external APIs (Application Programming Interfaces) that are called when creating resources. Additionally, a special notice should be made of modules, collections of resources in Terraform that are deployed together. Modules allow Terraform code to be repeatedly reused, reducing the work needed to deploy across similar use cases.
Terraform Providers Are (Usually) Hosted Remotely
Almost all major cloud providers like AWS are hosted remotely so that users can reference and download them when needed. The most popular method to store and call these providers from is called the Terraform Registry. When a user sets up their Terraform environment by using the command “terraform init”, this is usually the location from where they are importing their provider. Another method used specifically for internal facing Terraform providers is the very similar Terraform Private Registry that can be used so that only approved users have access to the uploaded provider. In niche cases, experienced Terraform developers themselves may use a .terraformrc file which overrides user settings to use local resource definitions rather than any remotely hosted definitions.
Terraform Providers are Generated by (Non HCL) Code
Developers that create and upload Terraform provider artifacts use the same coding languages that are used for developing backend code, such as Python, C#, and Java. The most popular is Go, or Golang, a language created by Google that is popular for its ease of use and association with container orchestration software Kubernetes. There is even a popular scaffolding framework in Golang published by Hashicorp to give developers an example of how to create new providers! This is a common source of confusion because the actual users of Terraform will only use HCL when calling and referencing providers, not the code that generates these definitions.
Terraform is Automation
The fundamental principle of DevOps is the reduction of time in release cycles. For example, deploying code to a production environment two times a week rather than once could be considered an improvement even if the same amount of code is released. This is because a shorter release cycle engenders faster improvements, feedback loops, and shorter rollbacks when issues arise. Terraform is used to enable this philosophy by allowing for infrastructure to be automated with the same tools as other code repositories. When connected to a Continuous Delivery pipeline, the state of existing environments can automatically be reconciled to your .tf files that dictate the intended state of your infrastructure. In this way, the drift between the intended and actual state of your infrastructure is only limited by the speed of your deployments.
Terraform can be intimidating at first, but with time and experience becomes more manageable. If you are looking to become truly proficient with IAC and specifically Terraform, the best step I can recommend is trying it for yourself given a safe cloud testing environment where mistakes can be freely made. An amazing deal you can use to facilitate this is the free trial offered by GCP(Google Cloud Computing)! Free for 90 days and/or $300 of credit, this will allow you to deploy from your own .tf files both with absolute safety and no ties to external projects. If you have any other questions or concerns regarding the content of this introduction, feel free to contact me at hello@rogueethic.com or on Linkedin!