Programmable Infrastructure Vs Infrastructure-as-Code (IaC)

With the advent of cloud services such as Amazon EC2 and Google Cloud Platform with simple exposed APIs and SDKs (if available) and infrastructure management tools such as Puppet, Chef, Docker containers etc.., gone are the days when a tech company needed to hire dedicated system administrators to manage the infrastructure layer of their software platform (Financial controllers love to hear this kind of stuff). Now, all a tech company needs is a developer with an understanding of APIs and SDKS to write code to provision, deploy and manage infrastructure services. This is what Infrastructure-as-Code boils down to.

Of course you could argue that the developer nirvana described above is nothing short of configuration management, but 2 main differences with Infrastructure-as-Code are:

• It is fully automated
• A developer can build the infrastructure blueprint directly into the core of an application or into the build / deploy component of an application simply by writing code that describes the infrastructure. (Now isn’t that awesome!)

A typical highly simplified application workflow that takes advantage of Infrastructure-as-Code could be along the lines of this:

Infrastructure-as-Code offers a number of advantages to a development team looking to take their ninja DevOp skills to the next level.

A few of which are:

• You end up with documentation that describes your infrastructure from which you can generate other representations of your infrastructure such as pretty diagrams. (Don’t we all love pretty diagrams!)
• You only need to look in one consistent place to make changes to your infrastructure which makes maintenance a breeze
• You can chop and change your infrastructure at the speed at which it takes your developers to write code against an alternative API whether internal or external