Cisco Tech Blog CiscoTech Blog Close
Home Contact

What is Infrastructure as Code?

Author

Infrastructure as a Service, Infrastructure as Code, or recently Infrastructure as Data — 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 — entered the stage, the software engineering community had to determine just out how to work with Infrastructure as a Service.

This blog post discusses some of the most popular methods and provides concise and accurate definitions to both technical and non-technical stakeholders.

TL;DR 🔗︎

  • Infrastructure as a Service refers to the capability of acquiring and releasing resources on demand.
  • Infrastructure as Code or Data refers to a method of acquiring and releasing resources on demand.

Infrastructure as a Service 🔗︎

Infrastructure as a Service refers to the capability to acquire and release resources. Infrastructure as a Service refers to the capability to acquire and release resources.

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 🔗︎

Infrastructure as Code refers to the method of acquiring and releasing resources. Infrastructure as Code refers to the method of acquiring and releasing resources.

This blog post is based on a minimal model of Infrastructure as Code based on the model of Infrastructure as a Service: The term Infrastructure as Code refers to the provisioning method of acquiring and releasing a set of resources on-demand.

Infrastructure as Code or as Data or as … 🔗︎

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.

The Hello World of Infrastructure as a Service The Hello World of Infrastructure as a Service

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 🔗︎

Figure 1.1 Infrastructure as Tickets Figure 1.1 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.

Figure 1.2 Infrastructure as Tickets Figure 1.2 Infrastructure as Tickets

Infrastructure as Clicks 🔗︎

Figure 1.1 Infrastructure as Clicks Figure 1.1 Infrastructure as Clicks

Infrastructure as Clicks refers to the method of using a resource provider’s user interface to acquires and release resources.

Figure 1.1 Infrastructure as Clicks Figure 1.1 Infrastructure as Clicks

Infrastructure as Scripts 🔗︎

Figure 3.1 Infrastructure as Scripts Figure 3.1 Infrastructure as Scripts

Infrastructure as Scripts refers to the method of using a resource provider’s command-line interface to acquire and release resources.

Figure 3.1 Infrastructure as Scripts Figure 3.1 Infrastructure as Scripts

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 🔗︎

Figure 4.1 Infrastructure as Code Figure 4.1 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.

As of today, 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.

Figure 4.2 Infrastructure as Code Figure 4.2 Infrastructure as Code

Infrastructure as Data 🔗︎

Figure 5.1 Infrastructure as Data Figure 5.1 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.

Figure 5.1 Infrastructure as Code Figure 5.1 Infrastructure as Code

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.

Conclusion 🔗︎

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.