Software is Still Eating IT: Its Next Course is Application Services

Back in 2015, I noted that Software was Eating IT. That was based on data culled from a variety of industry sources included RightScale, HBR, PWC, and others. From development to deployment to delivery, software was taking over everywhere.

But even then, the infiltration of software into the network – on the production side of the house – was still minimal. Oh, the signs were there and even many of the tools and APIs we needed. But if the breadth of the pipeline was a fancy meal, then development was the main course and deployment & delivery merely desert.

That was then, this is now. And what we’re seeing happen is that deployment & delivery is now one of three main courses in the application pipeline menu.

The data? Culled from F5 research over the past two years. Digital transformation is fingered as the driver of all this automation and change, but don't overlook the disruptive impact of public cloud in general.

Regardless of who gets the credit (or is it blame?) for the scales tipping in favor of software, it is nearly inarguable that software is still eating IT.

Development

The development segment of the application pipeline has always been driven by software. We used software to build the various libraries and executables. We used software to house versions of the code long before Git was a thing or CI/CD became a household* term.

What wasn’t always automated was the full breadth of the development segment. Automated testing and configuration management and event-driven build systems were not as common as they are today.

Thanks to cloud and DevOps, the development segment of the application pipeline has largely become a “software that builds the software” endeavor.

Deployment

Cloud and DevOps again get a head nod for driving the need for more automation in the deployment segment. This “other side of the production wall” segment is dominated by ops who automate app infrastructure deployment as well as they automate build and test processes. This was never really the problem. The issue was the “rest of the pipeline”. The piece of the pipeline that was comprised of network infrastructure providing the platforms for the application services necessary to scale, secure, and speed up apps.

It is this segment of the application pipeline that is now experiencing an explosive growth in automation by a growing group of savvy network engineers we’re calling NetOps, as a head nod to the DevOps movement that has (and continues to) influence the tools, techniques, and methodologies used to automate “the network.”

We see huge gains made in the past three years in terms of the use and importance of automation in network operations. The deployment segment of the application pipeline is on its way to becoming the “software that deploys the software” endeavor.

Delivery

The delivery segment of the application pipeline is set to the be the most disruptive of all. That’s partially because for twenty years our primary go-to in the network has been a shiny iron box. They scale, they have the capacity, and they’re faster than software, on the whole. But with the inevitability of multi-cloud organizations and the embrace of public cloud as an option for even the most critical of enterprise applications, the rules of the game have changed.

Hardware doesn’t migrate to the cloud. Hardware isn’t really the right platform to support the per-app architectures necessary to embrace immutable-infrastructure-as-code approaches to delivery. Software migrates to the cloud. Software supports per-app, immutability, and infrastructure as code.

The question isn’t really hardware or software (for the per-app, cloud architectures – the answer is obviously software) but is it containers or virtual software? With containers moving quickly to consume data centers and clouds alike, we’ve seen a doubling of demand for application services delivered in containers. Now, to be fair, that doubling was from about 4% in 2017 to 9% in 2018, but still that’s a significantly large jump whether it’s single-digit adoption or not.

There’s also been a significantly higher demand for virtual software, with hardware preferences dropping year over year. Now, if you think it will ever drop to zero then you don’t really understand why we moved from software to hardware in the first place (yeah, we’ve been down this road before) and why some of the delivery segment (the core, shared network) will likely always be largely hardware in the enterprise.

The bulk of the delivery segment, however, will be software. Already is. Has been for a while. It’s the only way to ease the friction of migration to and from the public cloud and to address the growing friction of traditional deployment schedules with demand-driven app delivery schedules. Containers and virtual software will consume at least two-thirds of the application delivery segment – both on-premises and in the public cloud.

The delivery segment is becoming a “software delivering the software that delivers and secures software” endeavor.

That’s because software is still eating IT, and it’s going to continue to do so for the foreseeable future.

*If your household comprises mainly developers (which mine does) then CI/CD is a household term. YMMV.