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.
Pradhan writes as follows…
When it comes to Infrastructure-as-Code (IaC), the skills may have changed, but it’s still not child’s play.
With 15 years of history behind it, IaC is a well-established concept and part of the ongoing march towards composability. These new approaches have been fueled by the need for more agile, more reliable and more repeatable provisioning and managing of infrastructure… and ultimately the applications that run on it, while removing the demand for complex technical skills for end-users.
Of course, as with almost everything in IT, it’s never that simple. What IaC gives with one hand, it can easily take away with the other if organisations aren’t aware. This means the whole approach to skills needs to change.
Hand-carved versus Lego
To the untrained eye, IaC and other composable approaches are a lot more straightforward than a manual, bespoke approach to infrastructure and application management. The comparison I’ve heard is between hand-carving a model car from wood and building one from Lego.
The hand-carved model will be undoubtedly beautiful but will take a lot of training and expertise to get just right. Conversely, a Lego kit makes it a lot simpler to put together a working model, and people can even make a try without the instructions. Similarly, it can be easily disassembled and combined with other pieces to create something completely new.
So where do the complications come in?
Still not child’s play
First, like IaC, Lego doesn’t remove the need for highly technical skills; they just happen at a different level of the process. Most of us won’t be painstakingly moulding and painting our own custom bricks, or designing and printing our own instructions. Similarly, IaC means development teams need to put in a lot of work learning to write efficient code and ensuring the right configuration management is in place to ensure IaC can operate as planned.
To an extent, this issue is baked into taking a new approach, but there are others to be aware of. First off, IaC won’t automatically solve every problem. There are times when infrastructure demands are so complex that an IaC approach may not exist. Similarly, there is the question of interoperability – especially in an era where mergers, acquisitions and partnerships are still commonplace. Your approach may work perfectly, but will it work as well when it also has to interact with (to return to our metaphor) Meccano and Tamiya model kits?
Another issue, in common with composability in general, is that in the rush to make the process of provisioning and management more efficient and repeatable, organisations can forget to ask themselves the most important question of all – not just “can” we do this, but “should” we? If the process becomes simpler yet results in infrastructure or applications that don’t operate as intended; puts data at risk by being less secure or moving that data to unexpected locations; or cannot guarantee the reliance and resilience the organisation needs, then any benefits are largely illusory.
Building the right skillset
Addressing these issues shouldn’t be complex. First, organisations shouldn’t think they no longer need their woodcarvers. The need for complex IT skills might not be as common, but it still exists – both to ensure IaC works as planned, and to deal with those occasions that demand a more complex approach, such as one-of-a-kind challenges or integrating new technologies.
Second, organisations need to ensure they have the skills to look at their environment from a more strategic level. This means not only asking how to provision and manage new assets, but why those assets are needed, what they will do, and how they will interact with existing infrastructure. A crucial part of many IT departments’ skillsets will be the ability to understand and predict the rolling impact of any changes, rather than the technical skills needed to implement those changes in the first place.
Finally, it will become more important than ever to be able to test and audit processes. The more the organisation understands exactly what assets it has at its disposal, where they are used, and how they interact with one another, the better it will understand the strategic impact of changing, re-using or adding to those assets. Without this, the risk of uncontrolled IaC leading to virtual sprawl or data risks will inevitably escalate.
It’s a truism in IT that something that eliminates complexity on the surface doesn’t eliminate it altogether – it just shifts that complexity elsewhere.
Understanding this and knowing where to develop the technical and strategic skills necessary to make IaC shine, is essential to making the most out of the move to composability.