Infrastructure-as-Code series - Kyndryl: Beyond the ‘box’, into workable cloud
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 John Davis in his role as distinguished engineer at Kyndryl – a technology services company, known for its mission-critical cloud modernisation advisory and implementation services spanning applications, data, AI extending from the digital workplace out to the Internet of Things and the wider compute edge.
Davis writes as follows…
The need for Infrastructure-as-Code (IaC) was born as cloud evolved… and it was understood that the bottleneck for application hosting implementation was no longer centred around the timely ordering of hardware (procurement lifecycle, waiting for delivery and racking the equipment).
Beyond the box
Time to value reduced, but then the bottleneck shifted to how quickly ‘environments’ beyond the physical box can be established.
So now, we’re asking new questions centred around how our environments can be maintained efficiently… and, equally, how can their implementation and maintenance be automated?
In service provider scenarios, how can 1000’s of tenants be established rapidly and segregated?
This is where software-defined everything, infrastructure-as-code, becomes essential. Many challenges are resolved if it is implemented well.
Hello developers, please meet infrastructure
Kyndryl’s Davis: Well-defined IaC design is key.
With DevSecOps, developers have needed to become more familiar with infrastructure and operations more application aligned, infrastructure as code serves as a common language through which both can communicate, collaborate and co-create.
For significant success, it’s important to consider the wider systems context of the build process. Fundamentally, having a codified IP address register for example, so that the automation can take what it needs and register what it used. More broadly what systems do the new systems needs to be registered within?
We need to look at Systems Monitoring, Configuration Management DataBase, Service Management, Asset Management.
Most organisations will have several systems that need updating because of new environments. Anyone can provision a server in the cloud quickly, moving that to become production-ready, secure, segregated with the correct network flows is where a well-defined IaC design is key. One that also makes automated updates into the wider support ecosystem maximises the opportunity presented by IaC.
Moving to an IaC model also updates the environment change approach. All changes should be applied leveraging IaC else drift will occur and eventually production issues will result.
In addition, once you have moved to IaC, you should be able to remove secondary controls previously in place to validate the completeness of manual work. An environment that was built using IaC via a DevOps pipeline will have both precisenesses of execution and audit capabilities that make some of these controls redundant.