A business and technical intro to Terraform.io (Infrastructure as Code)
Business Overview
When navigating the future of Enterprise IT within the Cloud, key decisions made regarding the practice and adoption of specific technologies and eco-systems will result in either strategic advantages both in the long and short terms, or force a business to re-architect their IT infrastructure in order to remain competitive.
The lifecycle of growth and adoption of the Cloud usually follows a similar pattern for many businesses and IT architects or developers working on them. For example, it is universally understood that when establishing the design of applications, at the most basic level is a networking layer, for security and access to your systems, the compute layer for the processing and decisioning, the storage layer for managing your assets and the data layer.
Despite the switch to the public cloud, the provisioning process of these cloud resources like virtual machines and databases, is devastatingly similar, regardless of the speed of access and the elastic nature of the Cloud. An architect will log into a UI console or an interactive where they will select different combinations of the resources needed, click around and hit finish over and over again after each component is acquired. Traditional automation acts as an “add on”, that is, these scripts are applied AFTER the compute instances, databases or other resources that were provisioned manually. But the database or instance provisioning itself, or any other resource needed, was a manual process.
For automation in the Cloud to yield the strategic benefits that enable a business to have full-scale continuity, infrastructure replication, automated disaster recovery process, a multi-cloud adoption strategy, and human error reduced drastically, it must be Ubiquitous automation.
Ubiquitous automation in the Cloud is the end to end automation of resource provisioning and products in the Cloud. This kind of ubiquity can only be accomplished through Infrastructure as Code where the entire blueprint of your Cloud IT is not only created but versioned, changed and updated easily and on the fly as needed.
Infrastructure as Code (IaC) is the practice of managing and provisioning computer data centers through machine-readable definition files, rather than physical hardware configuration or interactive configuration tools.[1]
Terraform is an IaC tool for building, changing, and versioning infrastructure safely and efficiently. [2]
How Terraform is the blueprint for a truly well-architectured Cloud infrastructure
When it comes to building perfectly symmetrical and beautifully connected architectures, with built-in change readiness, rollbacks, scalability, and infrastructure versioning, nothing sets the standard like the declarative configuration that Terraform brings.
With Terraform, an architect, or a team of architects need only write the resources they need following the specific syntax and resource types needed for their Cloud provider, run the initial plan assessment and execute the build as soon as they confirm that they are fine with the changes being applied.
Regardless of the complexity of the end-to-end architecture, resources and their dependencies can not only be created and updated on the fly but when necessary, be destroyed or terminated just as fast, making it ideal not just for production facing environments, but also development and lower environments where resources are provisioned on a temporary basis.
Technical Intro
Suppose you are building a 2-tier application architecture with the following layers:
Network components: At the highest level, we have the VPC (Virtual Private Network) with our CIDR blocks specified that allows you to provision resources within it, an Internet Gateway for providing internet connectivity for our instances. The Network Access Control List (NACLs) acts as a firewall for associated subnets, controlling both inbound and outbound traffic at the subnet level. Next, we have the public and private subnets that reside within the Availability Zone we’ve picked, us-east-1a. Public subnets allow resources within the VPC to have internet connectivity. The Private subnets are not connected to the Internet Gateways and therefore all resources residing within them will not have internet connectivity.
Web Server: The web layer lives within the public subnet and is simplified to include a single EC2 (Elastic Compute Cloud) instance (autoscaling and ELBs not included) and a set security group configuration.
Database instance: The data layer lives behind the private subnet and contains its own additional security group configurations.
Without automating resource provisioning with Terraform, all these layers would have to be configured manually through the console or user interface provided by AWS. Modifications or terminating resources that are no longer needed would involve the same tedious process.
All the resources needed for your architecture, i.e. networking, databases, application servers, storage, etc. can easily be abstracted as configs. Essentially, an architect can skip the endless clicking around a web UI console and instead managed their entire infrastructure from their favorite text editor. ( 🖥 VS code works perfectly with terraform).
This is what a complete picture would look like for an architecture built on AWS:
The terraform template would initialize using the AWS provider references. This is at the start of your config file and would look like this:
The access_key and secret_key can be abstracted to separate files instead of being hardcoded onto the main terraform file. These abstractions can be referenced using the variable keys syntax provided by Terraform.
To build your VPC, simply reference the aws_vpc resource key as shown below:
Next, when building the aws_internet_gateway to reference the VPC_ID, simply use the resource name for the VPC you built and terraform will automatically the computed value out of your VPC and apply the VPC ID to the Internet gateway you’re creating.
Here’s the complete blueprint of the simple 2-tier application on AWS.
This approach to infrastructure architecture has the following advantages:
1. Easy collaboration and versioning
2. Infrastructure evolution
3. Complete orchestration
4. Multi-cloud adoption
5. Seamless automation
6. Simple syntax in HCL
7. Simple infrastructure creation and termination
Getting started
To get started with Terraform, you can use the resource below:
1. Intro to Terraform from Hashicorp
2. Installation guide
3. Terraform public cloud provider references
How I’m using it
At rugged I/O, I’ve built an ecosystem of applications that combine the benefits of public Cloud with Terraforming to run cost-effective and manageable SaaS applications. Some of these applications are: 1.RuggedProjects — A project management subscription-based web application
2. RuggedTasks — A task management application for light-weight ideation and task workflow.
Conclusion
Leveraging Terraform, businesses, architects, and developers can bank on a universally understood and proven automation tool that is only available for systems and infrastructure built on the Cloud but offers greater opportunities to streamline and standardize the IT operations that on-premise solutions struggle to provide.
This is the first article in a series that I’m hoping to write on Terraforming in the public Cloud with practical examples for developers and strategic benefits for businesses.
Thank you for reading my article. 🖐
