Virtualisation first hit compute in a big way in the late 1990s, fueling VMware’s growth. In a somewhat overlapping timeline, virtualised storage gave administrators the ability to chunk up disks in a similar way. But networking hung in there.

Almost every network on the planet today still has to balance collision domains, broadcast domains, subnet masking, and cabling in what can be a very labor-intensive set of design and maintenance tasks.

While advancements like vLANs helped ease that burden a bit, networking has been ripe for a new approach—and that comes in the form of application-defined networking.

>See also: Getting real visibility for monitoring virtual environments

What does that even mean? How did it get here? What happens to the livelihood of the network engineer? These questions will be explored, and more, below.

How did it get here? The OSI model

Published in its current form in 1984, the open systems interconnection model, more commonly known as the OSI Model, has dominated network thinking for more than 30 years.

A core concept of the OSI model is that each layer is largely isolated from the details of any other layer. While that has led to great independence — as, for example, an application developer doesn’t have to worry about whether or not there is copper or fibre optic cable being run at the physical layer — it has led to siloed workers that don’t necessarily appreciate the details of the work that goes into the other layers.

>See also: Augmented reality means augmented risk to networks

Traditionally, an application developer working at the top of the OSI model only cares about an IP address and a port number provided by the Network Layer, since that provides a specific place on the network where a client-server connection can be maintained.

But a whole lot of design, art and maintenance goes into setting up a set of routers and switches to make sure traffic doesn’t bottleneck between any two IP addresses. This means there’s a network engineer who spends a lot of time managing tickets that represent requests for changes to an existing network design.

Application-defined networking: the network ticket killer

When you look at a modern application and what its networking needs are, it typically boils down to a chain of VMs or containers that need to talk to each other. In a simple example, here’s a three-tier web application with a virtualised load balancer, a web server and a database server:

From a network engineer’s perspective, the key here is to enforce a set of rules so that the load balancer can only talk to the web server and only over the ports needed to facilitate communication between the two. That makes the communication more secure and less open to attacks. Communication between the web server and the database server should be similarly restricted.

While there are plenty of great network administration tools available to help set this up, what happens when more web servers need to be added to the pool of existing ones at times of high load?

>See also: 3 key strategies for managing international firewalls

Generating tickets and configuring the network requirements there can be challenging and hold up deployments. Using concepts like vLANs, which extend the same 30-year-old model we’ve always had with TCP/IP networks, is better than manually stringing new cable, but they don’t take a fresh approach to what has emerged as a very common problem.

Application-defined networking seeks to simplify the problem by creating bubbles of connectivity around the different tiers of the application, and only allowing those bubbles to be pierced in certain situations.

Now if more web servers are needed, they are simply placed in the existing bubble where rules governing what traffic can pierce that bubble and in what direction are reused. From an application perspective, then, the network administrator simply sets up the bubbles or defines the parameters under which a developer can create or reuse one.

This eliminates the need to have a network engineer involved in every application deployment or change to one, leading to faster deployments and more of them, so that a development team can get more chances to innovate.

The livelihood of the network engineer

Often criticism of an application-defined networking approach is that it threatens the livelihood of network engineers. It doesn’t. Instead, it lets the network engineer automate interactions at higher levels of the OSI model so that they no longer have to deal with the whims of an application developer.

Instead, they can provide those constituents with a set of constructs they can work within in a more automated way. That frees up the network engineer to spend more time refining what they are best at anyway: layers 1-3 of the OSI model.

>See also: Cloud agnosticism: does the survival of current cloud providers matter?

There is typically no love lost between application developers and network engineers. Application-Defined Networking eases the burden of that relationship on both parties, letting each focus on what they do best.

At the end of the day, an application developer only wants to be able to make a client connection from one machine to a server running on another machine.

No network engineer enjoys fielding tickets from application developers—they would much rather spend time optimising traffic throughout a network with more creative placement of switches and routers, setting up routing tables, and other details that are vital to the overall efficiency of a network.

Sourced by Pete Johnson, technical solutions architect for cloud in the Global Partner Organisation at Cisco Systems