When an infrastructure environment (compute, storage, network etc.) is completely controlled by code, you can also in the reverse way say that the code defines the infrastructure environment. Because once you have written an automation that launches a virtual machine for you, you can say that the virtual machine is actually defined by the code. In this model the objective is to create a code set that defines the setup of all components of your infrastructure.
So lets say, in your datacenter you have implemented VMWare Virtualization. And then you have written a code that once launched can create all the VMs and network routes on VMWare. So now you have a code that defines your entire infrastructure on VMWare. Think of a scenario, when for some reason you need to rebuild that same set of VMs and Networks on another VMWare setup in another datacenter. So all you need is another VMWare installation in another datacenter as your only pre-requisite. Once you get that, you can run your existing code on the new VMWare setup and voila! your entire infrastructure setup on VMWare is recreated through execution of your code ‘automatically’. This is what is called as managing infrastructure as code.
Another use of infrastructure as code is infrastructure versioning. Lets say you run an application on 10 servers using an infrastructure code which we will call as v1. Then you decided to reduce the number of VMs to 3. So you modified the infrastructure code to delete 7 vms and keep only 3 – we will call this version of code as v2. Then you launched v2 and it reduced number of servers. After a while you realized that it has been a bad decision as the application is not able to perform properly on 3 servers. So you want to go back to situation where you had 10 servers. In the infrastructure as code management practice, this would just mean rolling back to previous version of code and launching the same to regain the same previous setup of 10 servers. Hence the infrastructure designs and architectures become version controlled.