We’ve all heard the phrase “software is eating the world” but the trend of infrastructure-as-code seems to be pushing even those boundaries. The trend, which sprang from the growth of DevOps, is to treat infrastructure management as yet another problem that can be simplified, managed, and optimized through the power of code.

In short, infrastructure as code replaces old processes which manually managed servers in the cloud (think of the point-and-click interfaces used in the Amazon AWS console) with tools that manage those same servers with code and machine-readable configuration files. Rather than having an administrator click through menus until you’ve launched the correct number of servers or allocated the right number of gigabytes of storage space, you feed those as inputs into your code, and it does the work for you.

Simplification

So what’s the upside to taking the human out of the equation? The goal of infrastructure-as-code is to allow you to treat infrastructure as another entity we can build software around, the same way we write code to manage photos on Facebook or pallets in a warehouse. 

With smaller companies, the job of managing (and inventorying, auditing, and monitoring) infrastructure is simple enough to do on a codeless web interface. But once you’re managing multiple, larger deployments? Then the benefits of coding up your infrastructure are really on display.

Consider what deployments were like before the cloud. Adding a server was an even more manual process: you had to buy a server, take it to the data center, and wire it in yourself. The cloud revolution transformed that into a process of selecting a server from a dropdown menu on a web page, and clicking through some configuration. But infrastructure-as-code makes it one step simpler, since you no longer need slow, manual processes to launch new servers.

Tooling

The other great benefit of infrastructure-as-code is that developers have spent decades building tools for managing code. The more other problems can be treated as code, the more leverage you can get out of those existing tools.

Consider the problem of auditability. Many enterprises want to know when and why a server was launched in their cloud. With a manual process, that’s a tough question to answer. Who was logged in to the interface when it launched? Did they remember to leave a note in some other spreadsheet or document? 

On the other hand, code changes are almost always managed with version control software like git, which requires leaving a comment attached to the specific change. Want a list of every time a new server was launched, along with the user who launched it and their notes? The git log has that info for you.

And there are many other coding tools as well, that can make your infrastructure more reliable, scalable, and bug-free. Testing code is quite a bit easier than testing a web portal. Experimentation and agile development work faster if you can copy over the code for your infrastructure and make tweaks without needing human intervention.

Liberation

One final reason enterprises get interested in infrastructure-as-code is because it lets you treat infrastructure as fungible. By treating infra as “just another entity” we can decouple it from individual infrastructure providers. For example, there’s no need to write code to launch Microsoft Azure, AWS or Google Cloud servers, we just launch “servers” and write additional logic to handle which provider.

Getting away from vendor lock-in has important implications for business continuity and infrastructure planning. When there are outages in one cloud, it’s nice to be able to change a couple lines in your configuration, and start moving assets to another. If you’re negotiating another multi-year contract with a provider, it’s nice to know you could redeploy on a different provider without weeks of scrambling.

It also allows for more experimentation and innovation. If you’re training a machine learning model, you can deploy that infrastructure in a provider with good GPU support. If you’re doing heavy data storage, you can go with the provider with the cheapest cost per GB. When you’re no longer thinking in terms of one provider and their portal, the possibilities of mixed cloud architectures really start to open up.

Getting Started

Infrastructure-as-code has been a developing concept for a while. There are mature tools for building, managing, and monitoring your cloud assets (and your cloud costs!). The most well-known are Kubernetes, an all in one-tool, as well as Chef, Puppet, and Ansible, which are more flexible tools for managing deployments.

These tools typically let you use a declarative syntax to describe what you want your infrastructure to look like. They grab data from your cloud providers to see what your infrastructure looks like now, and make requests through each provider’s interface to get from A to B. 

All of them have robust tools for tracking changes, monitoring to make sure things don’t get out of control, and far more powerful management options than any of the web forms cloud providers offer, so you can get exactly the infrastructure you need. Looking to learn more? We’re the experts on infrastructure-as-code, and we’re ready to start a conversation.