For people with a technical background, the easiest way to describe “<Insert thing> as Code” is the Wikipedia headline statement for Infrastructure as Code: “…the process of managing and provisioning computer data centres through machine-readable definition files, rather than physical hardware configuration or interactive configuration tools.” You can then replace the word “infrastructure” with any insertable item.

For people without a technical background, Infrastructure as Code represents the ability to build (provision) servers and services using code (a structured machine-readable file). To be able to do this, a platform needs to exist to which users can send code describing what they want to build and the platform builds it for them. Azure uses ARM Templates and AWS uses CloudFormation, which are basically files describing how to build a virtual machine or service of some kind. Of course, both platforms (Azure and AWS) provide support for Terraform and each provider works with Hashicorp (the creators of Terraform) to add support for the way in which Terraform describes how to build something.

Here's a diagram to explain this process:

Understanding-Infrastructure-as-Code-diagram-1-1

 

So, generally speaking, “<Insert Thing> as Code” is a bunch of configuration files of some kind that describe the thing you want to create so that another system can create it for you. I’ve found that a helpful and relatable way to explain this, particularly to people with non-technical backgrounds, is through the analogy of buying a cup of coffee.

Cofee As Code

If we take Infrastructure as Code as a way of writing a configuration that describes the state you want to achieve, we can take a visit to your local coffee shop and represent it as a series of steps:

  1. Walk through door
  2. Order coffee from Barista
  3. Wait for coffee
  4. Barista brings coffee to your specifications.

Here we define what we want (for example, a flat white) and someone else (the Barista) takes care of the production of the drink. Here's our Infrastructure as Code diagram again, but from the perspective of the coffee shop:

Understanding-Infrastructure-as-Code-diagram-2-1

 

To make sure we’re covering the “as code” part, let’s represent a coffee order as code. In theory, the Barista does this for you when they enter your order of a “flat white” into the till. What we would need to fulfil this part is to supply them with a pre-existing description of the coffee in a manner they understood.

We can see something like this if we look at an average Starbucks receipt:

starbucks-reciept-1

 
  1. Gr Carml Macchiato
  2. Gr Latte
  3. Tl Chai Tea Latte.

We can see three drinks ordered. We can assume what some of these terms represent: Gr = Grande, Carml = Caramel, Tl = Tall. And from this we can get a general sense of what the receipt is saying and convert this to some actual code:

Understanding Infrastructure as Code-diagram code-picture1-1

 

Here we have a yaml file describing our drinks from Starbucks. And if we assume that this is how the Barista's till expects them to be entered into the User Interface, then we have provided the till with the correct code.

The Platform

Whether it’s a Barista making our coffee with the aid of a coffee machine, or if we replace the Barista with a coffee vending machine, this represents a “platform” into which we input a pre-defined order that instructs it what to create. This is very similar to Infrastructure as Code and, in a normal scenario, we would also be able to change our drink by editing the code:

Understanding Infrastructure as Code-diagram code-picture2-1

 

We now have a Latte with caramel instead of hazelnut and the platform we sent our edited code to either modifies or recreates it. In this instance, because we wouldn't want to chemically extract the hazelnut (if that is even possible), we are going to need to recreate (re-provision) our drink. So now the platform (Barista/machine) applies certain charges to us for this process - we have basically thrown a coffee away to create another one. When you apply this to infrastructure, the creation is done, and you pay for the compute (resources) that you needed to create your infrastructure. In the coffee analogy, we can assume that the creation of a new coffee simply applies a surcharge (of one whole coffee) to your order.

A Note On The Coffee Analogy

At this point, I feel the need to point out the limits of the coffee analogy. Coffee is a consumable entity and with Infrastructure as Code (or indeed anything-as-code) you are creating and managing a resource – whereas a coffee no longer exists once it has been consumed.

If, however, we think of the drinking of our coffee as a manual change to the infrastructure then, when we re-run our Coffee as Code script, the platform will detect the change in state of the coffee from “ready” to “consumed” and return it to the original state - i.e., fill it up again.

How The Coffe Analogy Applies To Policy As Code

Policy as Code is basically the same thing – a file that describes to a platform how to create or apply a policy. For example, we might create a policy that restricts the build of resources to a specific size or generation of server to reduce cost or ensure we use the latest generation for security reasons. When we apply this policy, users building infrastructure would be forced to use a specific size or generation of server.

Understanding-Infrastructure-as-Code-diagram-3-1

 

Note in the diagram above that the policy can be applied at any time, meaning infrastructure can be created that does not apply to the new policy if this is done before the policy is created. However, once the new policy has been applied it will prevent the creation of non-compliant infrastructure; these would then notify admins that infrastructure exists that does not conform to the policies in place.

How do we apply Policy as Code to our coffee example? Think of it as being like the menu: without it I might order a coffee with an assortment of random syrups that would force the coffee shop to have all known syrup flavours at its disposal. Coffee shops prevent this situation by having a menu and only stocking the ingredients required to make those drinks. So if I walk into the coffee shop and order a cappuccino with pineapple syrup, the Barista can decline my request. A policy here is something that would affect the making of drinks by our Barista/machine and prevent the creation of anything we don't want. The policy would have been defined in code in the same way as our coffee was.

Conclusion

I hope you have found the coffee analogy useful to understanding the basic premise of Infrastructure as Code specifically and <Insert Thing> as Code generally. It’s certainly becoming a large part of how we deliver solutions for our clients and is something worth getting familiar with.

In fact, an understanding of Infrastructure as code is on of the ten things we believe all technologists should have. At BJSS, we’re always asked about which skills will help build a strong portfolio or lead to rewarding work in your tech career. So we created a free e-book about the skills needed for a successful career in tech, based on insights from BJSS technologists at all levels in the business.