Get startedGet started for free

Infrastructure as Code

1. Infrastructure as Code

Let’s start with the fundamental concept required to understand Terraform: Infrastructure as code, or IaC. With IaC you can write code using a configuration language to define, provision, and manage your infrastructure. Gone are the days where a system administrator had to manually configure hundreds of servers, networks, and firewall rules by interacting with a user interface. With IaC, you only declare the desired end state of the infrastructure –IaC handles management and provisioning. The rapid increase of business demand has manifested a cultural shift known as DevOps. DevOps emphasizes collaboration and communication between developer and operations teams, and automates software delivery and infrastructure changes. Let’s explore some challenges and the role IaC plays in addressing them. With competition growing among industries to benefit from the cloud, DevOps teams are struggling to manage growing environments and rapidly expanding businesses. This struggle involves four major challenges. First, high business demand requires rapid scaling of IT infrastructure across industries. Due to rapid scaling of IT infrastructure, Ops teams must overcome new operational and technical bottlenecks, such as managing infrastructure consistently at scale. When infrastructure is changed, DevOps teams often struggle to collaborate and audit changes. Closing the communication gap is imperative for successful deployments. Increased quantity and scale have also led to human, manual error that can potentially have significant effects. Now, let’s discuss the benefits of IaC. First, its declarative. Instead of having to specify the exact sequence of steps to make a particular change, you can focus on the desired state of the infrastructure. For example, you might use a production label to specify three subnets across two regions. Terraform will update the live state to match the desired state by adding a label to the existing subnet, and creating two new subnets in additional regions. Through declarative abstractions, IaC tools manage the implementation details so you can focus on changes made to your desired state. This declarative approach allows anyone to read the state of the infrastructure, as opposed to asking a system admin. Another benefit of IaC is that it’s managed in the same way as application source code. Typically, if you make changes directly in the Google Cloud Console that cause an outage, you’d have to manually identify the breaking changes - an error-prone process. With IaC, you can see a full history of versions and infrastructure changes. If something breaks, you can roll back to a previous state. The entire history of your infrastructure is captured in the commit log. Version control also enables developers to collaborate on changes. For example, perhaps a developer needs a port opened on a firewall to support their application. They can simply submit a pull request to open the port instead of waiting in a queue for an administrator to manually open it. Changes can be discussed, reviewed, and audited without creating information silos, which can lead to more collaborative ownership as infrastructure evolves. IaC also features an auditable history of your infrastructure. Typically, infrastructure doesn’t contain comments. You might see changes in audit logs, but it’s often difficult to understand why those changes were made. With IaC, you can include explanations. For example, you might comment that a specific subnet allocation is required for a certain application. This auditable history gives a clear view into how infrastructure has evolved over time. When proposing new changes, you can also preview them and inspect exactly how they will affect live infrastructure before they’re applied. These previews let you detect drift and ensure that your infrastructure remains robust. Portability is another benefit of IaC. You can build reusable modules that encapsulate conventions and let you consistently build infrastructure from a shared template. Instead of having to rebuild infrastructure manually, you can have many instances of the same template deployed for different applications or regions. Google Cloud has developed reusable modules that can be found in the Cloud Foundation Toolkit. Using the library of reusable, documented, tested infrastructure code makes it easier to scale and evolve your infrastructure. Provisioning and configuring are two terms that are sometimes misinterpreted. Fundamentally, IaC is used for provisioning and managing cloud resources, and configuration management is used for VM OS-level configuration. For example, infrastructure as code creates and provisions a VM instance, and configuration management configures the internals of the VMs. Configuration management is a broad topic that covers more than we can discuss in this section. To simplify, activities like configuring a VM for application dependencies are considered configuration management. Configuration often consists of manual tasks such as starting services, installing dependencies, installing applications, and running updates. To elaborate, the term Infrastructure as code refers to frameworks that manipulate Google Cloud APIs to deploy the infrastructure required to run application code. In contrast, configuration management refers to package configurations and software maintenance. Let’s look at another common example to differentiate between provisioning and configuration. IaC automates tasks involved in launching a GKE cluster into Google Cloud, and configuration management automates tasks involved in deploying containers into the GKE cluster. An important principle to understand about infrastructure as code is that it’s declarative. Most programming languages use an imperative model, where you specify the exact action you want to take, such as create five servers. This model is challenging for infrastructure because if you run the script again, it might create five new servers even if some exist. Imperative workflows make it difficult to determine the difference between live infrastructure and your desired state, leading to repeated resource creation. With IaC, you declare the desired state of your infrastructure and let the tool determine the details. For example, you might declare that you should have five servers. The first time Terraform runs, it might create all five servers. Then let’s say someone accidentally deletes a server. The next time Terraform runs, it would recognize that four servers exist and restore only the missing server. We encourage adopting declarative infrastructure tools like Terraform. Focus on how the infrastructure should be, and let automation handle the details of updating the infrastructure to match your desired state. Declarative management focuses on the WHAT rather than the HOW.

2. Let's practice!

Create Your Free Account

or

By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.