Why Infrastructure as Code (IaC) is Important

INFRASTRUCTURE AS CODE (IaC)

I believe as TPMs we often are the guiding compass for our teams. We should always be looking at industry-wide trends and nudge our teams in the right direction. Having said that it is quite necessary to keep an eye out on what’s happening across the industry. Over the last decade, we have seen several pivots that have changed the way we build and operate our teams. We have seen – 

• The movement from the waterfall SDLC towards a quick and iterative methodology like Agile. 
• A shift from using servers to using Virtual Machines (VMs).
• Move from having a dedicated SDET team to having SDEs owning the code. 
• Moving from a fragmented SDE and Operator team, to deploy the code to a DevOps model and/or SRE model.
• A shift from monolithic architecture patterns towards a microservice-based architecture. 
• An ongoing shift from using VMs to deploy our microservices on, to using Serverless / Functions as a Service (FaaS(Function as a Service)
• A shift from using in-house data centers to moving to the cloud.

In this post we are going to focus on teams moving to the cloud and how that process is maturing with the use of IaC. As this happens, there comes a time when we need to fundamentally rethink the notion of Infrastructure as a Service (IaaS). Traditionally IaaS just meant Compute, Storage and Networking where you would have a VPC, subnets, couple of Load balancers, applications running on compute instances and a database. In most cases, the base design of your infrastructure would not change a lot, over a period of time even though your team would be deploying new code for new application features. 

However with the move towards serverless and Kubernetes, the line between application code and infrastructure code has become blurry. This is because serverless is offered by Infrastructure providers and is for all intent and purposes Infrastructure. 

What is Infrastructure as Code (IaC)?

Infrastructure as Code is the concept of managing your infrastructure in the same way you manage application code.

Infrastructure as code simply means to convert your infrastructure deployments into code, where it is managed by some kind of version control system and stored in a repository that you can manage it similar to your application code.

This means that core practices like versioning, continuous integration / deployment, monitoring and testing now need to be utilized in managing your infrastructures as well. 

Some things that you now need to do with your infrastructure now are :-

• Versioning  & Scalability: Your infrastructure code now needs versioning, where the goal is to store all the infrastructure code similarly to application source code. As more developers use the cloud within one organization versioning and having a repository becomes imperative.  
• Automation: By automating infrastructure provisioning, infrastructure as Code, enables organizations to develop and deploy cloud applications at a reduced cost and risk with greater speed and higher reliability.
• Multi-region Deployments: With IaC you should be able to automatically configure your deployments across multiple regions and even look at your monitoring metrics to evaluate if the deployments should proceed or should be rolled back.
• Multi-Cloud Deployments: Several large enterprises are maturing to start using multiple cloud vendors to avoid lock in and also benefit from the fact that certain cloud providers might be better for certain types of work loads. IaC enables managing and maintaining this in a standardized fashion.
• Abstraction: IaC also provides a layer of abstraction where you can build replica environments with relative ease.
• Reduced Risks: IaC offers a relatively cheaper disaster recovery option by making it possible to provision several production environments in different regions simultaneously without having to pay for any standby failover environments.

Why Is It Critical To Embrace Infrastructure as Code?

Over the last decade, there has been a significant push to build and deploy faster to test out hypothesis and deliver value faster to our customers. The ability to reduce your time to market and the fact that you can easily maintain your application/infrastructure code is a primary reason to use IaC.

IaC also speeds up infrastructure deployment and, at the same time, also allows for rapid iteration. It enhances the infrastructure deployment process by building repeatability and consistency. It spins up the whole process by enabling the use of the Code used to create production environments to immediately create high fidelity environments for development, testing, and simulation in minutes. 

Through IaC, developers can operate more quickly as the infrastructure code houses the security and other enterprise standards. Also, tests can be staged simultaneously in several different staging environments. By introducing different continuous integration and deployment techniques, IaC further increases the processing speed and also reduces the slow human involvement procedures.

Declarative vs Imperative Styles of IaC

There are two styles of implementing IaC  a) Declarative b) Imperative Style

The core of a declarative style language is that you say what, whereas in an imperative style language you say how. In the case of IaC, for declarative you specify a list of resources you would like, whereas for imperative you specify a list of commands to run to create the resources that you want.

Both have the same output. On the surface imperative option is simpler, it’s definitely fewer lines. However, there is very little point writing commands that you can only ever run once. With the declarative approach, you can reuse and re-purpose the same infrastructure code.  

Declarative infrastructure tools like Terraform, CloudFormation, and Pulumi offer a much lower overhead to create and maintain powerful infrastructure definitions that can grow to a massive scale with minimal overheads. The complexities of hierarchy, timing and resource updates are handled by the underlying implementation so you can focus on defining what you want rather than how to do it.

The most common tools of Infrastructure as Code (IaC)

1.  Terraform: Developed by hashicorp, Terraform is an infrastructure provisioning tool that uses its domain-specific language (DSL). This language is called the Hashicorp configuration language (HCL), which is JSON-compatible. Configuration files used in describing infrastructure resources to be deployed created using HCL.

2. AWS CloudFormation: This is a configuration orchestration tool similar to Terraform. How this differs from Terraform is that AWS cloud formation can only be used with AWS. Another difference is that the CloudFormation templates can be created with YAML in addition to JSON.

3. Azure Resource Manager: This is an IaC tool similar to the AWS offering above. It enables the deployment and management service for Azure. Resource templates can be created with JSON.

4. Google Cloud Deployment Manager: Similar to the Azure resource manager, it offers GCP infrastructure stack Automation features. YAML and Python can be used to create templates and preview deployments in a console user interface.

5. Pulumi: Pulumi is a cloud agnostic enterprise product that enables you to manage, configure and provision your infrastructure. Pulumi also lets you doo this using real programming languages like JavaScript, TypeScript, Python, Go, .NET, C#, F#, and VB and also integrates with your IDE.

Terraform vs Chef / Puppet / Ansible

Chef, Puppet, Ansible are all configuration management tools and unlike Terraform or any of the above-mentioned tools which are provisioning tools. It’s important to understand the difference between the two. There are teams who also use a combination of tools like Ansible for configuration management and then use terraform to deploy the code. 

Conclusion

By fading the line between an application and infrastructure, IaC aids in sustainably deploying infrastructure changes. For companies using the cloud at scale it is now imperative to take a second look on how they manage, providion and deploy to the cloud.