Infrastructure As Code IaC a deep dive.

Introduction

With the constant growing need for businesses to deploy cloud infrastructure and other systems scaling up how fast systems can be deployed is critically important however IaC is not actually all that special and the technology behind it really has been behind many platforms including the likes of windows deployment imaging service WDS, where configuration of a clean image combined with respective settings applied to a newly deployed image is used to create a new machine, this was typically done on new computers being added to a company, school or if you were adventurous your own home network. For historical context WDS was based on a configuration file that defined various aspects about a computer system, such as the accounts to be setup, network file share and other elements. IaC was simply an iterative evolution over the WDS platform and moved into two separate paths, while those independent sets of implementations diverged they can be used to create hybridized architectures as well.

IaC at it's core is a means to automatically configure instructure. That is the servers, sometimes network equipment and other components IaC mechanisms can be even used to manage devices as simple as security doors and smart door logins, as IaC is used to issue updates to those devices over the network such as potential firmware updates and new feature which can be managed by a central software platform making it easier to manage identify information, an example of this would be Ubiquiti Access in a way this is actually an IaC system you just do not see most of what it does as UBNT networks goal is to simplify the process of managing a enterprise, medium or small business network. IaC was designed to solve two specific problems deployment scalability and deployment configurability. As virtualization took over the need to control more "switches" became apparent to programming the configuration of infrastructure at these scales become untennable via GUI or even CLI, and there were already at the time before IaC came about system admins using IaC like methods and that is how many of them were born it was because of thousands of VMs or even 10's of thousands of containers needing to be configured all at once without making errors using people do this task was time consuming with IaC as you can build -> refine -> deploy.

Infrastructure as config

Often much simpler to manage infrastructure as config often leverages human readable descriptions of hierarchical entities, in the form of typically trees, the way this is done is via various human readable serialization formats, which form the core basis of most infrastructure as config, examples of those types of configurations are the following.

• YAML (YAML Aint Mark Up Language) - Human readable and easy to understand YAML is incredibly effective at defining configuration files it's why it is commonly used in many Linux applications and other tools, but may not be suitable for complicated hierarchies

  
  

• JSON (JavaScript Object Notation) - Heavily used in API calls using RESTAPI's JSON objects are great for transferring hierarchical and structured data from one point to another it also makes a really good way to structure IaC.

• XML (Extensible Markup Langauge) - A much older technology but this method of serialization has been used extensively on the internet for a long long time, One of it's most notable uses was that of RSS feeds, they often stored data from those request as XML data and sent it to RSS readers.

  
  

• BSON (Binary Version of JSON) - You will probably not find this in most cases of IaC configs as it's binary encoded, but it might be beneficial if need to store IaC configs as a compressed form to save space, using BSON as a type of database file that will take up less space.

Infrastructure as code

Is often the most versatile in it's application, truly programmable infrastructure as code systems are often known to use various programming languages each with pros and cons, and many IaC platforms will give you the language of your choice in many cases allowing a company to quickly integrate their existing coding teams with the ability to deploy IaC easily and efficiently, some programming languages for IaC leverage the full capacity of the langauges they implement or they use a smaller subset of the programming language.

Taking Pulumi as an example this powerful IaC tool has a wide range of programmability and various elements of flexibility. I'll explain various components of language and how they might fit into the broader context of IaC, I am a bit biased towards this language as it has a lot of really nice to have features making it very good for a wide range of applications, I am disappointed Pulumi does not offer C++ or Rust, it suspect this is due to C++ potential memory safety failures and difficulty sticking with managed languages like C#, java, Go, Typescript, Python and YAML ensures that the Pulumi platform does not have the concern of memory leakage or exploitation, I do believe Rust would be a good contribution as well.

• C# - A language similar in many ways to Java but has features that really make IaC greatly simplified C# has a concept called properties, where in many other programming languages you have to create "getters and setters' for objects C# has a dedicated set of instructions built in to give you that functionality without needing physical methods defined in it to handle this task. Making code simplier in general to write, it also has a lot of object oriented nice to have including nullables, which allow objects ot take on a "null value" instead of being initiated at creation. C# also has other abstractions including delegates and events. Where events a commonly found in Java delegates are not, and rather abstract but powerful tools, the verisility of C#'s OOP functionality makes it lend itself to robust design patterns to allow abstraction and flexibility for IaC.

  
  

• Python - While it does lack static type checking, Python has recently introduced a concept known as type-annotation, this is sort of like static typing, but it is more intended for the programmer than it is designed for the actual langauge specification. Python also does not have advanced structural and layout based definitions. Where C# has various class, properties and other modifiers python is much simplier meaning creating complex OOP structures will require more work, but python is easy to prototype, in an organization quick test deployments might use Python and then move to deeper abstraction from the likes of Java or C#, python also has a lot of sequence type manipulation shorthands which makes performing tasks on IaC platforms significantly easier, it typically takes much less code to complete a sequence action compared to C# or Java.

• JavaScript / Typescript - You can develop under typescript which transpiles to JavaScript only problem is JavaScript has a very long list of quirks and problems, while it is a very expressive language JavaScripts type hoisting and other quirk problems can make it unwieldy and difficult to manage while it is very dynamic it lacks a lot of the guard rails other languages may have, especially statically typed languages. Typescript was designed the address a lot of the problems with JavaScript by providing typechecking and other features, but fundamentally it is still JavaScript under the hood in the end.

Langauge choice for IaC comes typically down to what your development teams are familiar with, however some IaC basedd implementations maybe much more scalable than others, both Java and C# have many facilites for fully parallel processing python 'technically does' however it is achieved in a different manner, and ideally when doing a deployment scalability in how fast and effectively a piece of infrastructure is deployed might be more desirable overall, both JavaScript and Python offer rapid prototyping at the sacrifice of risking potential future spagehtti code in future, however python is much simplier and easier to understand, it is less what is used in the term of 'expressive'. An example which would lead to simplier IaC code is using princples of systems engineering, and abstraction. A perfect example would be to use Javas dedicated interfaces and respective abstractions available, to build a hierachy of data, that is Servers can become an interface, that interface would have requirements as Interfaces themsevles are contractral object oriented components, a server is likely to haved the following attributes. Servers have physical hardware. In an IaC situation this would be a virtualized set of attributes applied to the structure of the system in question. Anything that is infrastructure can be built into an IaC solution.

• CPU

  • X86 architecure, ARM, and others.

• RAM

  • How much RAM

  • Overcommit

  • Quota restrictions

• Storage

  • Remote Storage Provider

  • Database Connections

  • Analyitics platforms

• Network

  • VLAN configurations,

  • Link-bonds

  • vSwitch connections

  • Number of virtual interfaces

infrastructure hybrids

There is actually a third option and that is organizational hybridzation. Allowing you to get the best of both worlds when it comes to Infrastructure as Code, by combining the code aspect with the config aspect, allowing for advanced actions and configurations by writing out the various types of configurations such as YAML and there are many libraries that can parse YAML very easily. Do note though hybrid architecture based IaCode and IaConfig can increase complexity of managing a infrastructure deployment but could given additonal options allowing template files with replacable sections indicated by say Kebernetes example. In this example you would create a script or program which would search the YAML file, and re-program the sections on the fly where you would not actually need to manually enter them, allowing for an internal tool to be written for it. Each bounded section with [brackets attribute] around them can be dynamically re-written by simple CRUD operators (Create, Read, Update and Delete).

YAML
name: [config name]
runtime: [runtime-type]
description: [description]

[variables]:
  [appLabels]:
    [app]: nginx

Evolution

Large language models have been integrated into many IaC tools, LLMs are well poised to take control of the automation process in deploying IaC, allowing for potentially less mistakes and a simplier interface to access the configuration and code of a platform. However caution must be prefaced here, using LLMs to interrogate the status of IaC or infrastructure in general will obfuscated what is happenning behind the scene and many managers, and CEOs assume just because it works "today" means it will work always, LLMs introduce both new opportunities and new hazards in the process of IaC deployment, including if an LLM does something catastrophic, borrowing from cybersecurity, jail breaking an LLM interally which is facing a IaC backend has absolutely catastrophic consequences, that include not limited to. Destruction of data, Modififcation of security Policies, Deletion of core running assets, Uncontrolled self-deployment (overwhelm a companies IT infrastructure by flooding VMs into the IaaS systems, crippling the entire back end, compromise or even the changing of cryptographic keys leading to an advesary replaciing your entire key manager set with their own, now your hardware has been pwn'd.