Infrastructure-as-Code series - HashiCorp: no, it’s not just “the code”

Building blocks and DevOps 

These, however, are just the building blocks. Perfecting the fundamentals of IaC means overcoming a set of challenges first encountered in a field now impacting IaC – DevOps. 

At its heart, IaC is an embodiment of a consistent and repeatable set of routines. How else could you deploy thousands of fully provisioned servers in a complex, on-demand, multi-cloud environment spanning containers, virtual machines, microservices and service providers?

Consistency and repeatability are achieved in three ways.

The first is to capture your infrastructure using a declarative model. A model will allow you to make changes to artifacts such as servers or clusters centrally, thereby eliminating manual or ad-hoc coding on production machines. Changes can be rolled out at scale using unattended processes.

Next comes immutability – infrastructure that is transient and disposable. Immutable infrastructure is created as needed and deleted when its purpose is served, removing the need for maintenance, upgrade or repair. 

The motor behind both of these is number three: automation. Scripts and commands are activated according to predefined processes, doing away with the need for manual intervention.

Is Conway the wrong way?

HashiCorp’s Sayar: At it’s heart… IaC is an embodiment of a consistent and repeatable set of routines.

Too often, however, modern infrastructure contains variables and uncertainties that act as roadblocks to automation. The root cause is invariably team structures and practices that mean systems are developed and maintained in non-repeatable ways. Conway’s Law sums this up: “Any organisation that designs a system (defined broadly) will produce a design whose structure is a copy of the organisation’s communication structure.”

This is where IaC becomes a process and a cultural evolution.

The first step is to automate operational practices. This is achieved by capturing run books – that formed part of the traditional ITIL ticket-based systems and manual processes – as code.

The next phase is to establish effective collaboration and communication between infrastructure engineering teams so they can share code and modules, very much like how applications are built on shared libraries and common modules. 

This can be challenging – moving from a team of, say, two engineers to 30 or even 300, all of whom have different ways of working and different priorities different levels of expertise with the infrastructure, e.g. storage vs network engineers. It therefore makes sense to formulate and roll out blueprints and templates that serve as a baseline for repeatability and consistency and to implement an ownership model with RBAC (role based access control) to the different areas of the IaC. 

The final phase is the public release of APIs so infrastructure can be consumed at a higher level by the wider organisation – developers, infrastructure and platform managers.

It’s at this point you should focus on the governance aspects and implement policy-based processes in areas such as security and compliance. These can help, for example, to manage cloud budgets, discover who uses the infrastructure and how, ensure storage and corporate networks aren’t exposed to the public internet, or make sure only modules and resources approved by the infrastructure team are used.

The cadence of real IaC 

IaC is a fast-growing and busy market. We’ve moved quickly from rolling and managing bare-metal servers, through virtualisation, to building business infrastructure using software.

Realising successful IaC requires an understanding and appreciation of its core principles – and some intentional cultural and practical changes outside the code.