Infrastructure-as-Code series - HashiCorp: no, it’s not just “the code”
The Computer Weekly Developer Network (CWDN) continues its Infrastructure-as-Code (IaC) series of technical analysis discussions to uncover what this layer of the global IT fabric really means, how it integrates with the current push to orchestrate increasingly cloud-native systems more efficiently and what it means for software application development professionals now looking to take advantage of its core technology proposition.
This piece is written by Guy Sayar in his capacity as field CTO for EMEA at HashiCorp – the company is known for its modular DevOps infrastructure provisioning and management products.
Sayar writes as follows…
Uptake of Infrastructure as Code (IaC) is soaring with the simultaneous growth of technologies like Kubernetes and demands for ever-faster software delivery.
Traditional systems that saw developers submit a request for, say, server resources, cannot keep pace with demand in a world of razor-thin deadlines.
IaC succeeds because it’s predicated on the concept of self-service enablement: as a developer you can press a button or call an API and get the compute, storage, or clusters you want.
Much of the talk about IaC has therefore centred on the tools and the potential for new interfaces to define the topology and resources of IaC at a semantic level without hands-on coding.
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.