Infrastructure as Software

Summary

This post is my summary (for my own sake) of the original full length post: https://www.justingarrison.com/blog/2022-06-01-infrastructure-as-software/

What is not IaS

Writing your infrastructure in a DSL or any other general purpose coding language like Ansible, Pulumi, Terraform is not Infrastructure as Software. Any managed service to deploy infrastructure without acting like a one-time shoot action (AWS CloudFormation) is also not IaS. Also not ment is Infrastructure as Data (IaD).

Downsides of IaC

The big benefit of IaC is that your developers can write code that creates infrastructure and you can use coding practices to create libraries other people can share. But lets look the downsides of Infrastructure as code:

• Writing an application with (for example) Java and also IaC in (for example) Java: if you want to upgrade your Java version, you need to upgrade both! Another maintenance tasks which can cause conflicts.
• What if you need to transition the IaC and the hole infrastructure to a new team or person which doesn't know anything like (for example) Java? They will for sure rewrite the hole IaC stuff in a language they know or even worse they will do everything manually by hand.
• Writing IaC in different languages means you can't reuse or integrate modules together. One is in Java, one in Ansible, one in Terraform's HCL.

Downsides of IaD

The goal if IaD is separating your declarative requirements from the implementation code. With Terrafrom I can roll out IaC like this:

terraform apply

or I can separate the requirements in variables (which represents the unique data) apart from the generic IaC-code:

terraform apply -vars-file data.tfvars

The challenge with IaD is, what it relies on general purpose infrastructure reconcilers. In other words you fall back to combining your data with some form of automation or templating your data into something that can be compiled. Examples for k8s are helm charts and kustomize.

Downsides of managed services

The problem with managed services is, that its only a one-way sync automation. It requires you to send data it can deploy, but when things change those services are ignorant and do not correct the differences between your desired state and the actual state in your production. Well there are a few mechanisms to detect drifts, but they always require manual interaction.

So why IaS?

The big deal of IaS is that it allows you to continually reconcile state and sync state into the stack. It manages your infrastructure continuously. The main difference between IaC or IaD to IaS is that IaS is a continually running process, your code is always in action. IaS reads your data, stores it, reads the infrastructure state, stores it, and then checks if the two matches. It's a two-way sync automation that knows how to imperatively get from one state to another.

Examples of IaS

Two famous examples of IaS are:

• Kubernetes controllers
• GitOps

Kubernetes controllers

Kubernetes controllers ares used as example in Cloud Native Infrastructure. The idea of this is to use K8s CRDs + a controller to manage infrastructure. Examples are crossplane, AWS Controllers for Kubernetes (ACK), and GitOps. It’s also been used for managing state of applications in Kubernetes with operators.

GitOps

GitOps is a idea for using a general purpose reconciler to manage more resources. Let's have a look a the GitOps principles:

1. Declarative: A system managed by GitOps must have its desired state expressed declaratively
2. Versioned and Immutable: Desired state is store in a way that enforces immutability, versioning and retains a complete version history
3. Pulled Automatically: Software agents automatically pull the desired state declarations from the source
4. Continuously Reconciled: Software agents continuously observe actual system state and attempt to apply the desired state

There are multiple options for controllers that implement GitOps. Flux and Argo are the two most popular GitOps controllers known so far.