Infrastructure 2.0: Whatever We’re Calling it Now, It’s Here

Many years ago, when the cloud was just rising and DevOps was just an idea, a small but opinionated group got together to discuss the future of infrastructure. The Infrastructure 2.0 working group included Internet legends and Internet would-be-legends alike: Greg Ness, Christofer Hoff, James Urquhart, Vint Cerf, Bob Grossman, Dan Lynch. We met many times in the heart of Silicon Valley trying to predict what needed to happen in order to bring infrastructure along on the tumultuous journey toward automation and orchestration.

Despite our earnest attempts (and numerous blogs and Twitter conversations), ultimately the timing just wasn’t right. The world was not yet ready for the transformation necessary to catapult infrastructure from supporting role to leading actor.

Now, nearly ten years later, it’s happening. We don’t call it Infrastructure 2.0 anymore. Now it has more modern, hip terms like DevNetOps, NetOps 2.0, and Super-NetOps, but the technology underpinning the movement remains the same: automation via API-enabled infrastructure that addresses the diseconomy of operational scale.

And that description is the perfect example of why we use acronyms and trendy phrases to describe things in technology.

The cloud has taught us about the economies of scale, and now containers are threatening to redefine it once again. It’s the collection of devices known as the network — or the data path — that support the scale of applications and services.

In that data path lies a number of network and application services that provide for the scale, security, and speed of the applications they deliver. Each one needs to be provisioned, configured, and managed. Every. Single. One.

In 2014, Computer Economics determined the median network device to engineer ratio was 37 to 1. A year later that number was 59 devices per engineer, a jump of 60 percent. More apps. More devices. More engineers?

Ah, that’s the rub. That’s where the diseconomy of scale rears its ugly head. There is a point at which the number of people you throw at the problem of scale becomes disadvantageous. You actually start slowing down as communications grow too unwieldy. You start trading security for speed and stability for scale — and diminishing returns kick in.

That’s where Infrastructure 2.0 — DevNetOps, NetOps 2.0, Super-NetOps — comes in. Because its purpose is to embrace DevOps principles and apply its methodologies to the network.

This notion comprises three core concepts: programmable (API-enabled) infrastructure, infrastructure as code, and the inclusion of integration.

Programmable (API-Enabled) Infrastructure

API is the new command line interface (CLI). It is with APIs that automation and orchestration can be accomplished today, and it is how disparate pieces of the deployment puzzle are daisy-chained together to replicate a deployment process. A REST API enables ubiquitous access from just about any scripting or programming language you can think of. Access via APIs promotes integration and deployment of the network and application services needed to support applications. From sharing metrics with app owners to provisioning new services, you can’t effectively automate without APIs.

Infrastructure as Code

Infrastructure 2.0 encourages the use of declarative methods of configuration – such as templates – instead of imperative, API-driven methods. If we’re ever going to get to the level of automation we see in science fiction movies and promoted in ads today, we first have to make the move to the declarative model that tells the network what to do rather than how to do it.

Part of this requires a shift in perspective toward treating network devices (whether hardware or software) as being as disposable like an app infrastructure. The deployment artifacts — the collection of configuration files and templates — become the critical component of a network architecture, not cabling.

Integration is Included

Automation is the codification of a manual task. Orchestration is the automation of a process. Processes require more than one task, which means integration is a must in the request for comments style of specifications. Integration is a scary word, thanks to decades of horrific tales from the nether regions of app development. It isn’t simple, of course, but thanks to the pervasiveness of HTTP and REST APIs, integration isn’t as scary as it once was. Still, if you’re going to self-service enable the provisioning of a load balancing service for developers, you’re still going to need a way to kick it off. More often than not, that will be from a ticketing system, which immediately means there’s integration going on.

Greeting Infrastructure 2.0

The core concepts behind Infrastructure 2.0 and what we were hoping to achieve in the old days still holds true. We need programmable infrastructure that supports a declarative method of management and can be integrated to automate the deployment process.

We can call it something else – because a rose by any other name would smell as sweet – as long as we actually put it in practice. The days of automation as a competitive advantage are long gone thanks to the cloud and pressure from containers.

Automation is no longer about getting ahead, it’s about keeping up.