Auto-tech series: HashiCorp - Automation & the multiverse of machine madness

Continuing this series of technology platform analyses examining the universe of automation tools and services now being brought to bear across every transept  of the software application development space, this is a guest post for the Computer Weekly Developer Network written by Adeel Ahmad in his role as strategic advisor for cloud transformation HashiCorp, a provider of multi-cloud infrastructure automation software.

Ahmad writes as follows…

Hello, Dr Strange

Just imagine it. An existence where millions of near-identical worlds are inhabited by billions of beings going about their daily lives – until they’re ruthlessly terminated by a higher force.

No, it’s not The Multiverse of Madness but some would say a near-close alternative: it’s multi-cloud running immutable, container-based microservices.

Dr Strange was warned he couldn’t control everything in his multiverse: the good news is, you can bring order to yours through automation.

You just need to think about it in human terms.

Multi-cloud has crossed into the business IT mainstream and with it a belief in the power of automation to operationalise that infrastructure. Automation breaks through the different worlds of clusters, machines, datacentres, zones and service providers to let you spin up services, provision firewalls and apply patches in a consistent and predictable way.

Automation eases the administrative burden on IT teams as this multiverse grows and expands, allowing them to keep up with changes and get ahead of potential threats.

As a result, we’re seeing near ubiquity of automation – in the form of AIops, Robotic Process Automation (RPA) and other expressions of machine-driven technology, but many organisations are simply automating their existing processes in multi-cloud.

Automation, however, offers a much-needed opportunity for deeper change.

Take security.

We’re all familiar with the model of perimeter-based firewall and trusted IP addresses but multi-cloud has rendered this obsolete. Immutable devices sharing IPs, fast-changing connections, and snowballing transactions between people and machines provide air cover to attackers so that if – or when – the perimeter is compromised the blast radius is huge. 

A more effective approach is to apply access controls to applications, machines and users with a model of identity-based authentication called Zero Trust. This, however, means configuring thousands of devices and requires a sophisticated infrastructure capable of issuing and administering tokens, passwords, certificates and encryption keys to protect access and sensitive data. 

Impossible using traditional practices – but not so with automation.

Don’t believe the hype

Despite such obvious benefits, automation is viewed by plenty of IT pros with a healthy dose of suspicion. One reason is our – fully justified – aversion to industry hype on the subject (yes, automation is being oversold). Another factor is at play, however: that corporate fixation with automating existing processes. When machine deployments consequently fail to live up to expectations, it validates the scepticism.  

The question is how to break the cycle and help automation achieve its potential?

Automation is a machine-deliverable outcome but it also means re-examining what we do at a human level – and capturing and expressing that in a way the machine can act on.

What does that look like in practice?

First it entails establishing new machine workflows – ways to deploy, update and protect infrastructure from different sources in different locations several times a day. Workflows must be capable of operating consistently in each of your multiverse’s worlds. They must also be accessible via an API to connect to each world and developer tools to implement that workflow. 

Power play – policy-as-code

Second, it means implementing policy-as-code. This covers the detailed steps to follow when, for example, a change or update request has been committed. 

Traditionally, policy has been written in run books: Tickets would be filed and code reviewed by the security, compliance or technical teams. Policy as code implements practices in a machine-readable form and works like digital tick boxes to ensure best practice – for example, dictating nodes in a development cluster cannot be accessed from an external address. Policy as code is stored in the DevOps infrastructure for version control and implementation.

Workflows and policies are the guide rails on which automation runs – the fabric used to build templates for standardised and repeatable processes for IaC, regardless of multiverse nuance. 

This is operationalising the infrastructure at a human level, giving DevOps the autonomy to work without submitting to a time-consuming review and approval process. Ultimately, it paves the way for DevOps to create new templates that adhere to the rules –  taking automation even further.

Automation has become an article of faith in enterprise IT but we can do better. Automation for IaC is more than a machine play – it means addressing how we work as people.

Get that right and you’ll operationalise the madness out of your multiverse. 

Image source: HashiCorp