Saturday, March 13, 2021

What is 'Infrastructure As Code (IaC)'?

 

You peel the cellophane wrap from your factor-new computer and prepare to go through the manual checklist of setting it all up.  Libraries, frameworks, tools and applications....one by one you check them off, grabbing a coffee or taking a long lunch as the time for each step dictates.  The morning turns to afternoon, the afternoon to evening, the day wasted away but really, what choice do you have?

The alternative choice originated back in 2005, an experienced system administrator Luke Kanies recognized the value of automating the setup and maintenance of data centers.  Lacking applicable tools, he elected to create one.  That was the origin of Puppet.

But this post isn't about Puppet, nor Chef, Docker or Kubernettes but they all originate from the same concept; automate the process of setting up and maintaining systems.  The goal; a big 'easy button', a new system? Hit the easy button.  New security patches required for a dozen back-end servers?  Hit the easy button.  A new developer joining the group needing a host of IDEs, utilities and tools...hit the button.


Almost 60 years?  The first computer was available in 1946, the first concept of setup/maintenance automation in 2005, why on did it take so long for such tooling to exist?  The year, 2020 and only a fraction of computers are maintained using automation...why isn't everyone using it?

Whelp, it's all about time; time and control.  I suppose there are a number of reasons folks don't capitalize on IaC, some likely feel it is a fad, some likely feel more comfortable maintaining a system manually (maintaining explicit control), some perhaps need or require non-uniform configurations, perhaps applying updates/patches to particular machines before applying to the masses.  There is merit to all these considerations but in my opinion it's mostly about time.  Focusing exclusively on productivity, setting aside any wouldn't it be cool it" motivations, its the constant trade between "how long to automate" vs "how long to just do it".   Authoring system configurations takes effort, requires testing, requires considerations of each step failure,....never free, always a trade.  If you provision a dozen systems a month, or maintain hundreds the effort of automation likely would pay huge dividends.  A few family computers, updated bi-yearly, each individualized....likely more time than it's worth.

IaC Architecture

At it's core, IaC technologies all tend to follow the same overall architecture.  The following diagram applies to Puppet, but is comparable to other IaC technologies.

Overall, the system contains the systems to be maintained, a series of user desktop systems or laptops, or the host of VMs or infrastructure servers.  These 'maintained systems' run an agent, the agent communicates with a master service, the thing that keeps track of what stuff should be running where.  The master maintains the installation media, tarballs, security patches....the files a maintainer would use if they were to update the systems manually.  Additionally, the master service would have a list of what servers require which applications/libraries/patches.  When a new configuration is required, it's updated on the master.

The maintained systems will occassionally 'call home', communicate back to the master to see if their are updates that are required.  If so, the agent transfers the files from the master and executes the update.  In the case of Puppet, the agents (by default) call back to the master every 30 minutes.

In the absence of an actual person running the updates, observing the process, an IaC requires some means to confirm everything when smoothly.  Often, some form of a dashboard, a way to see if any systems failed in the process.

The agent/master file transfer, execution and status constitutes the 'easy button'.  The real heavy-lifting is authoring, organizing, maintaining and testing the configurations leading up to hitting he button.  Like any automation task, trial and error and testing can be a considerable effort and you'd better have your ducks in a row before you push it out to dozens of machines!  The only thing worse than having to manually update 50 servers is to have to manually undo problematic updates...will absolutely ruin your evening plans, your weekend and your rep.  Great power, great responsibility and Uncle Ben once said.

Whether you have an immediate need, or a mild curiousity, it's certainly worth peeking at IaC.  Some of the major open-source players are:

The concept of containers also fall into this category:

As the world continues to transform into a 'computing on demand' model, VMs created and destroyed as needed, elastic systems dynamically launching containers as needed our need for devops demands a means to respond.  

No comments:

Post a Comment