Infrastructure was once purchased, shipped, installed and powered on. It is now available on demand and provisioned like software. In fact, it is often provisioned with all the necessary software installed. For many that means bring your data and let someone else worry about the physical devices. For others it means reinvention in a new world built on APIs. Those APIs enable a variety of interfaces for managing networks, compute and storage. Like a bicycle there is a variety of places to start based on experience. Let’s look closer at each interface.
Point, click, repeat. Graphical interfaces are a preferred method of managing infrastructure in some circles. Knowing the organization of the interface is a skill. This remains true as the infrastructure methodology evolves, but the intention of the interface is now like training wheels on a bike.
The GUI is an introductory tool that is outgrown as the user advances. It gets you started but soon becomes a nuisance. While the click of a mouse is familar, those clicks are a bottleneck and undocumented knowledge. Remembering the sequence of clicks and data entry relies on extensive documentation. At best that documentation is kept up to date with additional effort. It’s more realistic that existing documention will fall out of date and be a faulty reference later. Especially since the GUI tools evolve as upgraded. Luckily GUI tools today are usually just a veneer on APIs which expose the same functionality in other ways.
Command line interfaces have long been an alternative to GUI tools. The advantage has always been the written nature of commands were self documenting. These commands are often cryptic so usefulness as documentation is limited by fluency of the reader. Like a leisure bike the lifespan and usability of command line tools are broad but not always the best option.
Command line tools share the memory burden of GUI tools, but the commands are reusable if captured. Past commands can be referenced instead of recalled. The commands can be aggregated into reusable scripts. New product features don’t require reorganizing the command line interface so the tools can remain backward compatible as the product they interact evolves. Much like a SDK they are versioned and supported until breaking changes are introduced. The shortcoming of command line tools is the lack of extensibility and interoperability. It’s usually possible to achieve what’s desired but a specialized tool would get you there faster.
Infrastructure as code (IaC) is not a specific technology. These configuration frameworks offer extensibility and interoperability with other APIs. They are written and easily versioned as the infrastructure evolves. Like a road bike increases velocity and enables greater distances, IaC unlocks potential not possible with other tools.
Programmatic processing of structured configuration is the real advantage with IaC. The inputs and outputs of each execution integrate with other tools. Automation changes the possibilities of scale and speed while IaC keeps records organized. Configuration frameworks can be broader than a single vendor allowing end to end automation of hybrid environments. Software provisioning tools extend infra automation to handle every detail of application deployment. Tearing down and rebuilding a system becomes trivial so test coverage increases. Repeated deployment and testing reduces the risk of the production release. Issues are resolved by rolling back to the last working release.
Software developers keep source code so they can change it and recompile. This just makes more sense than only keeping the binary, fiddling bits for simple changes, and rewriting the program for complex ones. That’s how infrastructure has been managed until now. Abstracting away physical devices behind APIs enables us to treat hardware like software. Infrastructure as code defines systems in a readable form that can be processed by tools leveraging APIs.