Published on 00/00/0000
Last updated on 00/00/0000
Published on 00/00/0000
Last updated on 00/00/0000
Share
INSIGHTS
6 min read
Published on 01/10/2021
Last updated on 06/18/2024
What is Infrastructure as Code?
Share
Infrastructure as a Service (Iaas), Infrastructure as Code (IaC), or Infrastructure as Data (IaD) — certainly infrastructure comes in many forms, shapes, and sizes. Yet, even though these terms sound deceptively similar and deceptively simple, they denote fundamentally different and intricate concepts.
After Infrastructure as a Service — or Cloud Computing (see more about cloud computing at our Cloud Native Security FAQ) — entered the scene, the software engineering community had to determine how to work with IaaS. This blog post discusses some of the most popular infrastructure provisioning methods and provides concise and accurate definitions to both technical and non-technical stakeholders. 
TL;DR: What is Infrastructure as Code (IaC)?
- Infrastructure as a Service refers to the capability of acquiring and releasing resources on demand.
- Infrastructure as Code or Data refers to acquiring and releasing resources on demand.
What is Infrastructure as a Service?
This blog post is based on a minimal model of Infrastructure as a Service: The term Infrastructure as a Service refers to the capability of a resource consumer to acquire and release a set of resources from a resource provider on-demand. The term Resource refers to any component that is consumed by a consumer and therefore provided by a provider, for example, virtual machines, containers, or load balancers.
Infrastructure as Code
This blog post is based on a minimal model of Infrastructure as Code based on the model of Infrastructure as a Service: Infrastructure as Code refers to the provisioning method of acquiring and releasing a set of resources on demand.
Infrastructure provisioning: 5 methods to acquire and release resources
Arguably, Infrastructure as Code is the most well-known and most frequently discussed provisioning method today. However, in this blog post, we will discuss five distinct methods to acquire and release resources. The resource consumer determines the required set of resources, the desired state. The provisioning method determines how the desired state is expressed and how or when the sequence of commands that transform the current state into the desired state are calculated or performed. For example, the resource consumer may determine that they need one Load Balancer Resource in addition to three Compute Resources to run their application. 
But how may the resource consumer get there? And what happens if the resource consumer encounters any adversarial effects triggered by the environment e.g. a compute resource becomes unavailable?
Imperative provisioning methods
Imperative provisioning methods refer to the set of provisioning methods where
- the resource consumer does not formally encode the desired state and
- the resource consumer determines the sequence of commands
Most notably, imperative methods are not repeatable and therefore neither automatable as the resource consumer must determine the sequence of commands that leads to the desired state for each given current state.
Infrastructure as Tickets
Infrastructure as Tickets refers to the method of submitting a support ticket in the enterprise’s support ticketing system. The resource consumer submits the description of the desired resources as a support ticket. The support agent acquires or releases resources on the consumer's behalf and shares the connection information and credentials with the consumer. 
Infrastructure as Clicks
Infrastructure as Clicks refers to the method of using a resource provider’s user interface to acquire and release resources. 
Infrastructure as Scripts
Infrastructure as Scripts refers to using a resource provider’s command-line interface to acquire and release resources. 
Declarative provisioning methods
Declarative provisioning methods refer to the set of provisioning methods where
- the resource consumer formally encodes the desired state and
- a component determines the sequence of commands
Most notably, declarative methods are repeatable and therefore automatable as a component determines the sequence of commands that leads to the desired state for any possible current state.
Infrastructure as Code
Infrastructure as Code refers to the method of using an additional component to acquire and release resources. The resource consumer encodes the desired state in a component-specific format and the component determines and executes the required sequence of commands. Additionally, “as Code” implies the presence of control flow statements.
Currently, available implementations of this component have the quality of a tool that executes once when triggered by the resource consumer — manually or automatically in the context of a Continuous Deployment or Continuous Delivery Pipeline. Well-known examples include Hashicorp Terraform or Pulumi’s Pulumi. 
Infrastructure as Data
Infrastructure as Data refers to the method of using an additional component to acquire and release resources. The resource consumer encodes the desired state in a component-specific format and the component determines and executes the required sequence of commands. Additionally, “as Data” implies the absence of control flow statements. As of today, available implementations of this component have the quality of a platform that executes continuously. Well-known examples include The Cloud Native Computing Foundation’s Kubernetes Platform or AWS’s Fargate. 
Infrastructure as Code vs. Infrastructure as Data
The defining characteristic of Infrastructure as Code is the presence of control flow in the encoding of the desired state while the defining characteristic of Infrastructure as Data is the absence of control flow in the encoding of the desired state. Infrastructure as Code is often associated with the manually triggered detection and mitigation of state drift by the resource provider. Similarly, Infrastructure as Code is often associated with the continuously executed detection and mitigation of state drift by a component. However, the manually triggered or continuously performed reconciliation is not a defining characteristic:
The association that Infrastructure as Code is manually triggered stems from the popularization of Infrastructure as Code by manually triggered tools like Terraform or Pulumi
The association that Infrastructure as Data is continuously performed stems from the popularization of Infrastructure as Code by continuously performing platforms like Kubernetes.
Infrastructure as Code: a new way of understanding cloud security
Whether we are reasoning about Infrastructure as Tickets, as Clicks, as Script, as Code, or as Data, we are reasoning about an Infrastructure Provisioning Method, that is, how we interact with Infrastructure as a Service.
If you have more questions about how ideas like this fit in the cloud security context, visit our cloud security FAQ.
Subscribe to
the Shift!
Get emerging insights on innovative technology straight to your inbox.
