Last week we looked at Infrastructure as Code (IaC), an emerging set of IT automation tools and practices that enable infrastructure management through a software layer.
Today we will examine the impact of IaC on the business, using a “software-defined” lens to understand how this technology is a driver of change and transformation in the software supply chain. We will look at how Infrastructure as Code changes IT service management strategies, providing a foundation to launch DevOps initiatives and increase the scope of Agile practices.
Re-Defining IT
As a software-defined technology, we should immediately expect that Infrastructure as Code will be highly impactful on the business and how it is organized. It is important to recognize IaC as a software-defined technology, because looking at it through this lens gives us an understanding of what to expect as we start to adopt this technology in the enterprise. Analysis using three key attributes of software-definition will shed some light on the impacts:
1. Abstraction
Infrastructure as Code requires that all operations on infrastructure are declared in definition files and executed using an automation tool. This automation layer provides an abstraction from operations like deploying, configuring and managing components. This means that these operations shift left in the software supply chain – they are performed earlier and all together, rather than sequentially at the final stages of activity.
With this abstraction, the skill specialization for managing infrastructure shifts from traditional vendor and application specific sysadmin skills, to the ability to write code and think through the abstraction. The roles and responsibilities for managing infrastructure can move to anyone with a proficiency for writing code.
2. Control
Since infrastructure can be fully documented in code, we can “read” the environment – see everything that was deployed and how it was configured by simply reading the definition files.
The focus of service management and control systems therefore shifts to managing the automation tooling and definition files. For example, use of a version control system to manage the definition files brings about the idea of “versioned infrastructure”, where the change record is reflected in the version history.
Similarly, change management can be accomplished through code reviews performed individually when the changes are checked in, rather than putting batched changes before a change review board.
3. Mutability
The environment is exhaustively described in definition files, which are not dependent on infrastructure attributes. Ideally, the infrastructure itself is “immutable” – no changes are made directly to the infrastructure once it is deployed. Infrastructure components are locked down and not directly accessible to humans – changes are deployed only with the automation tooling.
This has two impacts: first, it introduces commoditization to deployment process. The same definition file can be used to bring up one server, or a hundred. Additional assets can be deployed as needed, just-in-time, and torn down when they are no longer required. Elastic assets means infrastructure is always ‘right-sized’.
Secondly, the underlying infrastructure becomes modular. We can use our definition file to bring up our components on-premise, or in the cloud; on AWS, or on Azure. While there are some dependencies involved in the automation tooling, overall the infrastructure layer has few enough hardware or vendor dependencies that operators have a lot more freedom to choose where to host their infrastructure.
Adoption Through Transformation
For a business that relies on a software supply chain to deliver value to customers, Infrastructure as Code represents a significant opportunity to increase efficiency, lower costs and reduce risk.
Further, IaC has emerged as a vital driver in transforming and modernizing the software supply chain. Digital-first businesses like Amazon, Netflix and Facebook live and breathe software-defined infrastructure. This is because they have been able to build their business, their culture and their value stream in a greenfield without the encumbrance of legacy systems and practices.
As with all software-defined technologies, incumbent enterprises that have a well-established value stream will have difficulty with wide-scale adoption of IaC. Some of the challenges they face include:
- Culture: All software-defined technologies present the significant challenge of redefining roles, shifting responsibilities, and altering work structures. Part of the transformation to adopt these technologies therefore involves a cultural change across the technical side of the organization. DevOps, as a culture, has emerged from this, and embraces these new roles and responsibilities. This will need to be nurtured and allowed to grow through a process of sharing and collaborating.
- Practices: IT professionals are typically accustomed to working within project based work structures like PMP and Prince2. Infrastructure as Code, however, begs for the use of software development practices like Agile to manage work. Implementing software-defined infrastructure will have the effect of proliferating management techniques like Scrum and Kanban. This is a great opportunity, but equally a challenge to get everyone on-board and trained up on the new methodologies and the tools they use.
- Value: A fundamental characteristic of software-defined technologies is that they recast management strategies. With IaC, the IT supply chain is altered beyond recognition, requiring new thinking about service management strategies. The changes in where, when and how infrastructure will be managed and deployed mean organizations need to undergo a paradigm shift in thinking about how value delivery is organized.
In order to fully adopt software-defined infrastructure, incumbent enterprises will need to be ready to undergo a transformation. There needs to be a commitment and willing to invest in new tools, new skills and new relationships. Leaders will need to be open-minded and willing to run tests and experiments to determine how best to reengineer their value stream to capitalize on the opportunities ahead. The crisis of ITSM, if this can be called one, must be embraced as a catalyst for change.
