Infrastructure as Code - what and why?

One of the core concepts behind our Cloud adoption strategy is that of Infrastructure as Code (IaC).

IaC is commonly associated with DevOps - in fact the two are sometimes (I believe incorrectly) used interchangeably, but I can see how this arises.

Often the greater the need for the increase in pace of change, the greater the need for collaboration, empathy and automation.  IaC can certainly help with automation but what about the other two?

In order to achieve a high level of pace of change all the cogs of the IT delivery engine need to be aligned – there is no point in having high level of application change throughput if you have to wait an age for an Ops guys to make the necessary infrastructure changes to support it.  If you put a Skoda clutch into a Ferrari then you are going to severely dampen the effectiveness of the car...

Let's take a step back and have a look at what IaC actually is first...

What is IaC?
Infrastructure as Code means writing code to manage configurations and automate provisioning of infrastructure in addition to deployments.

This is not simply writing scripts, but involves using tested and proven software development practices that are already being used in application development.  For example: version control, testing, small deployments, use of design patterns etc.

IaC differs from infrastructure automation (scripting), which just involves replicating steps multiple times and reproducing them on several servers.

In other words, IaC uses software engineering principles to produce repeatable infrastructure.


Why use the IaC approach?

• Its easier to associate, develop, version control and test the application along with the infrastructure that it resides on
• This aids collaboration between Dev and Ops teams
• By using similar techniques and approaches to the delivery of change there should be an increase in empathy between both camps
• Infrastructure delivery is reliable, repeatable and fast
• Its possible to spin up entire environments and the applications that sit on them for a version control repository.  That's cool on a number of levels - could this help your DR capabilities for example?

Software engineering has been around a long time and the principles are relevant to infrastructure as they are with applications.

• Why shouldn’t infrastructure be version controlled?
• Why shouldn’t infrastructure be built and deployed automatically?
• Why should infrastructure be tested automatically with every change that is made?

Principles and features of our IaC approach

• Immutable - a change to the application or infrastructure stack triggers a full rebuild (where possible - databases are harder) of the whole environment.  That way we know what is in version control is exactly what is going to be deployed.
• Full Stack Engineering - we should version control the application alongside
• The network
• Security roles, firewalls, authentication mechanisms etc
• Databases
• Compute
• etc
• Everything is in version control (we use Git and BitBucket)
• Human readable - all the configuration should be in easy to read configuration files
• Tested - we test everything automatically using BDD.  For example, run a test to ensure that only port 80 is open on a webserver.  We run these every time someone makes a change through Continuous Integration (we use Bamboo).
• No changes in the portal - we are using IaC on our Cloud project.  We don't allow any config changes via the Azure portal.  Everything has to be done in code.
• Hands-free deployment - deployment of infrastructure is completely automated apart from someone pressing the "Go" button