In the pre-DevOps era, there wasn’t much question of developers owning infrastructure, if only because for the most part, they didn’t want to own it. They wanted infrastructure to work for them (or at least not get in the way), but they didn’t want to be stuck with the time-consuming and generally thankless task of maintaining and managing it. Add to that senior management’s understandable desire to keep infrastructure in the hands of trained IT personnel, and the IT staff’s equally understandable desire to maintain an orderly network, and the result was a relationship between developers and infrastructure that was cool and somewhat distant.

But with DevOps, we are entering (or have already entered) the era of infrastructure as code, and with it, the developer-infrastructure relationship has changed. If infrastructure is code, then almost by definition, infrastructure becomes to some degree a function of development, or at least so hard to separate from development that the distinction becomes almost irrelevant.

In the era of traditional IT, the IT staff built out, maintained, and largely controlled infrastructure, provisioning it for end-users (and developers), up to a point. That point was determined by the boundaries of IT’s responsibilities as defined within an organization. These boundaries were much more easily defined when it came to serving the needs of some user roles within the organization (administration, for example) than for others (including development). Since IT personnel were often trained by vendors in the configuration and deployment of specific applications and services, the boundaries of IT responsibility were frequently further defined by certification for specific products.

The result was that IT was likely to supply developers with systems that were not really adequate for development. The developers in turn would respond by reconfiguring their systems and installing the tools that they needed. Depending on the organization’s policies and the relationship between IT and developers, this could result in anything from peaceful coexistence (“whatever developers do on their own systems is OK, but they need to talk to IT if it’s going to impact the network”) to rogue behavior on the part of developers (unilaterally disabling firewalls, anti-virus software, and other required services, installing unauthorized or prohibited software and services). In other words, because traditional IT is not good at accommodating developers, much of what they do involves “off the books” uses of the the system.

In DevOps, development and infrastructure have to be integrated, and they have to function as a whole system that is fully dedicated to serving the continuous delivery pipeline. DevOps infrastructure is dynamic in the same way that development is dynamic, and for the same purposes; continual release and continual delivery mean a continual high level of infrastructure involvement in the process. In contrast, traditional IT’s activity cycle consists of relatively static periods of maintenance punctuated by periodic build-outs, upgrades, and installation of new software or hardware. The speed of traditional IT deployment is too slow for DevOps, in effect forcing developers to take some form of ownership.

For developers, dynamic IT in a virtualized environment may consist largely of the rapid and temporary allocation, configuration, and deployment of specific resources for use in short-term development-related tasks. This is by its nature more likely to be a scripted process, as are most day-to-day DevOps infrastructure tasks. In such an environment, certification in the configuration and maintenance of specific hardware and network systems is likely to be much less important than the ability to write essentially platform-independent scripts — a development skill, rather than one associated with IT.

This will not make traditional IT skills obsolete, of course. Complete virtualization is an ideal rather than a fact, and it may not even be a desirable ideal in many cases. Hardware is still a reality, and even in a virtual environment, it is necessary to maintain the integrity of the underlying support infrastructure. In DevOps, however, the boundaries between infrastructure and development change radically, and in many areas may disappear entirely.

But does that radical shift in boundaries necessarily place infrastructure in the hands of developers?

Consider the following progression: Unique, low-level, hand-coded solutions –> Higher-level coding/scripting systems with built-in advanced functions –> GUI-based systems with relatively limited scripting/coding requirements –> GUI-only systems with little or no lower-level scripting. This kind of pattern (or something very similar) shows up time and time again in the history of software development — common tasks that require coding skills eventually give rise to visual tools that require little or no coding skill at all.

What was true in the DOS world a generation or so ago is true in the DevOps world now, and the process is already well underway. The use of hand-coded scripts to control the Continuous Delivery process will become increasingly uncommon, until eventually, the entire DevOps infrastructure will be under the control of GUI-based tools, with little or no actual scripting.

What does this do to the relationship between developers and infrastructure? Does it place infrastructure back into the hands of the traditional IT staff? No egg really looks the same after it’s been put back together, and in the case of DevOps and traditional IT, it isn’t even a matter of putting the egg back together. Even with a full suite of GUI-only tools, DevOps IT will be dynamic, responsive, and flexible, dominated by the need for rapid-fire changes based on shifting development needs. Infrastructure management will continue to be closely tied to development, because it will be strongly driven by developers’ requirements.

There’s another side to the use of high-level, GUI-based tools to control a system. While they may not require scripting for day-to-day operations, they are likely to include a variety of functions which would be impractical (or even unimaginable) if they had to be written out in a low-level scripting language. If (as is typically the case), such functions can be optionally used from a script, then rather than eliminating scripting entirely, they will make it possible to do things with a script which would have previously been impossible. This brings developers directly back into the control of infrastructure in a way that expands both the capabilities of infrastructure and their role in developing those capabilities.

Perhaps the question is not so much one of developers becoming the owners of infrastructure as it is a question of the boundaries between the roles of “developer” and “infrastructure owner” dissolving, so that they become responsibilities contained within the same DevOps-defined role, rather than separate roles.

Feature Image Source: https://www.youtube.com/watch?v=wwbNDM08rX4