With apologies to Philip K. Dick.

This post is going to address three topics:

1. The relationship between a virtual machine (VM) and its network connection(s).
2. The changing perimeter
3. The role of APIs in controlling network configuration

The common theme is dreams, or perhaps de/re(ams) – as the last two topics touch on whether something is de- or re-. I’ll explain…

Dreams of connectivity

Patrick Kerpan and I stepped out of Cloud Expo last week for a cuppa and a chat, and the conversation inevitably came around to the relationship between cloud architectures and networks. His company (CohesiveFT) makes a virtual network overlay that used to be called VPNcubed that was renamed to Virtual Network Server cubed (VNS3). I used it myself a few years back when I was experimenting with deployment of a PaaS fabric to a hybrid (public/private) infrastructure environment. I made the following point:

The VM doesn’t really know the difference between an eth0 and a tun0 – it’s just dreaming a different dream of network connectivity.

Could that be a dream bubble or a cloud?
CC Some Rights Reserved by Akakumo

This isn’t entirely true… If the connection to a VPN overlay (tun0) is made from within the VM itself then it needs a (pretend) physical adaptor (eth0) to bind to. But the rules of the game don’t have to work that way. The management layer could present the VM with a tunnelled end point and the VM would have no idea.

The underlying point here is that network layers 1,2 & 3 have become entirely made of software (and hence fungible) in virtualised environments, and the virtual machine doesn’t (and shouldn’t) have any idea when things are being moved around. Not only do VMs dream of connectivity, but we can have Inception into those dreams. That’s a fun magic trick when things are being configured manually, but it becomes really powerful when the network is configured by software through APIs.

De or Re pt.1 – perimeters

For some time the Jericho Forum has been taking about deperimeterisation – the idea that the network perimeter as presently defined in most organisations will disappear. I never thought it was realistic that the perimeter would go away entirely[1], so for many years I’ve talked about reperimiterisation – where the perimeter contracts around core assets/data. In the enterprise the first step comes in moving the perimeter from the entire network (including desktop etc.) to around the data center. In the case of mobile we can already see mobile application management creating perimeters around specific apps and the data they handle.

In many ways the traditional perimeter was about management convenience – good guys inside, bad guys outside – build a wall between them. Of course that simplification was never true, and often helped the malicious insider, and got in the way of doing business with the legitimate outsider. In an age of manual configuration it was just a good first approximation that made the problem space manageable.

Software defined networks let us have much more precision in tailoring perimeters to the threat and the business case.

De or Re pt.2 – software, networks and APIs

Software Defined Networking (SDN) is the new hotness at the moment, especially since VMWare spent $1.2Bn on Nicera to get the networking piece for their Software Defined Data Center (SDDC) story. There seem to be some who are taking software definition to mean that the network is itself a software entity. Whilst this can be true it’s certainly not the most efficient way of moving packets around – that takes optimised hardware. Chris Hoff has recently been tweeting that we should call them Software Refined Networks, and I’m inclined to agree. Specialised hardware isn’t going away, we’re just going to get smarter about how we (re)configure it.

APIs are now stepping into the yawning hole between manual changes to network config (which usually involve a trouble ticket and somebody with a Cisco certification) and changes to network config that have always been automated (and somewhat invisible) – like Routing Information Protocol (RIP). There will certainly be places where networking is pure software (the first part of this post illustrates that), but as the tributaries merge into great rivers the software piece will be about getting the most out of hardware.

Conclusion

Networks have had virtualisation (in the from of virtual local area networks – VLANs) since before virtualisation hit the mainstream in other areas like (distributed[2]) compute and storage. The issue here is that the configuration of that virtualisation was primitive, and it hasn’t meshed well into other areas of data center automation. That’s changing now, and as VMs dream of connectivity we can use software through APIs to refine networks and reperimeterise security boundaries. Networking (and network security) just got interesting again.

Notes

[1] In the words of my friend Colin Constable we still need the perimeter (and its firewalls etc.) to ‘keep the lumps out’. As Bruce Schneier has pointed out – the old threats don’t go away.
[2] Virtual machines of course aren’t new, but VMs on mainframes weren’t particularly interesting or challenging from a network perspective.