Infrastructure-as-Code series: Morrell on Microsoft’s march & maturity

The Computer Weekly Developer Network (CWDN) now starts 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.

In the Infrastructure-as-Code (IaC) model of technology creation, definition and management, there are no cables, wires, widgets and connection plugs.

It is sometimes referred to as programmable or software-defined infrastructure. This is a new type of technology substrate built using descriptive model source code files that define connection topologies.

Of course, there are cables and wires running in and out of the (typically cloud) server running the IaC layer, but for our illustrative purposes here let’s assume that they’re all virtual and we are building an abstracted machine.

Using Infrastructure as code, we can enable developers and their corresponding operations teams to automatically manage, monitor and provision resources, rather than manually configure discrete hardware devices and operating systems.

In terms of implementation, IaC is not a world apart from software application code used to build apps i.e. it is a ‘descriptive model’ for defining and provisioning the structure of an IT network.

That definition also includes specifications to detail data storage capacities and capabilities, server structures and other associated base elements such as load balancers etc.

In IaC, IT infrastructure is now established through the use of IaC files, which are typically text files written in various languages such as Terraform or CloudFormation or other.

Already quoted in our series introduction, guest writer Dick Morrell – a Linux veteran and developer advocate – says that the current ramp up to Infrastructure as Code first started being seen when organisations who had played with both Cloudstack and later OpenStack had created three tiers of applied architecture.

Morrell writes as follows to explain more…

As we look at the evolution of Infrastructure as Code (IaC) and the drive to put Idempotence (the grounded core defining principle behind IaC) at the core of a deliberate push to arm and enable safe and secure delivery of cloud assets, we can see how the market and the technology tools at hand here have developed.

We want to move to a future DevOps communities world where maturity is a new norm. Considering the fact that there is so often a misalignment between business use cases (and technology provisioning) for many organisations eager to provision at speed, the goal of pushing the concept of a target environment having a known and assured configuration (regardless of the original state that it left the test dev environment) is an appealing one.

The ability to aid DevOps teams by enabling the simple creation of fresh environments into known configurations is also good news.

The promise of having on-demand IaC environments that provide full CI:CD tiers that are dynamic to provision and simple to tear up and tear down can only be seen to provide a level of sanity and safety for an environment outside the comfort zone of many auditors.

For industry-specific applications such as health and fintech this has to be seen as a positive goal for cloud architects to ensure DevOps teams are trained and aware, bridging skills gaps now rather than post-deployment.

Just as Microsoft provided a unified set of tools and environments on bare metal, the next power play is the cloud.

I would like to argue and suggest that Microsoft, over and above Amazon Web Services, Google (and to a more mature level than HPE) provide the keys to an extensible platform. A maturing platform that provides transparent and easily replicated, simple to tear up and tear down configuration management in a hybrid or poly cloud.

Yet it is very rarely the first choice of the cloud architect whose first thought is to reinvent the wheel with Terraform and a plethora of other tools and associated metric monitoring tools. When I talk to cloud architects it’s often not even the first or second choice tool of choice. In fact it seems to be overlooked as the norm.

The growing maturity of Azure Resource Manager has emerged quietly as a stalking horse from Microsoft’s development stable. Microsoft knows it has a core global concentration of companies using Azure and on-prem MS computing.

So the obvious attraction of having Microsoft’s IaC as a core tenet of removing technical debt is very astute and a play that every CIO must place on their radar at the risk of ‘not invented here’ attitudes that often lead to cost overruns and creating platforms that fail to deliver the business use cases needed.