So Doug Gourlay, fresh from the fight at Cisco Data Centre Business Unit and now out on his own as a consultant, has had a shot at some thinking. The result is that The Networks’ Roles in Cloud Computing. in which he spouts the view that networking is technology deficient. Since I subscribe to the view that there is nothing new in computing, we are just waiting for old technology to return (Networking Truth Number 11 – RFC1925 lets put these ideas out of the park.
Coupling – its all about Loose and Tight Coupling
In computer science, coupling or dependency is the degree to which each program module relies on each one of the other modules – Wikipedia
“Coupling can be “low” (also “loose” and “weak”) or “high” (also “tight” and “strong”). Low coupling refers to a relationship in which one module interacts with another module through a stable interface and does not need to be concerned with the other module’s internal implementation. With low coupling, a change in one module will not require a change in the implementation of another module. Low coupling is often a sign of a well-structured computer system, and when combined with high cohesion, supports the general goals of high readability and maintainability.”
Networks are Loosely Coupled systems
In Computer Science terms, a data network is a loosely coupled system with a great deal of flexibility. Compare this with the current Operating Systems and their applications which are tightly coupled systems.
For example, in a data network, we are easily able to exchange elements of the system. For example, replacing a core switch does not require a complete system upgrade. Each switch could run different versions of software, or even different vendors, and still be a perfectly functional system. The exchange of data between each element of a computer network is well-defined and standardised. The system allows for supersets of data to exist and is regularly seen as vendor proprietary extensions e.g. Cisco VTP protocol.
The stable interface between Network elements is IEEE 802 standards at layer 2 of the OSI model, by the IETF standards for Layer3/4 of the OSI model.
Servers Operating Systems are Tightly Coupled
Compare this with the extremely tight coupling that occurs in Servers Operating Systems.
Definition – Tight Coupling: Refers to hardware and software components that are linked together and dependent upon each other (reference)
. At University, they teach you that tightly coupled systems are generally bad.
An example here is that Microsoft “Windows Server” are tightly coupled by Active Directory. There are no extensions possible, and only limited interoperability. Although some interoperation with Linux or Unix is possible, the “Windows Server” is not required to conform to standards that allow for dynamic replacement.
Indeed, the replacement of an existing server is difficult even with a Microsoft Server only environment. Many of the interfaces created by Microsoft do not ensure smooth paths. Active Directory, Group Policy, Name resolution, SMB over IP is all based on old concepts.
Addressing dynamic IP Addressing
Doug is right that servers that dynamically move between data centers will have IP addressing problems. But this also presumes that applications use IP addresses to communicate to servers and that presumption is false. This type of design went out four or five years ago and most people realise is that DNS is the chosen namespace management tool that solves the IP Addressing issue. In fact, the success of companies like Infoblox shows how vital this has become.
And modern load balancers address the geo-location issues quite nicely. We also have IP Anycast, and IPv6 has several techniques that support servers having multiple addressing, and dynamic application support.
The problem today is that applications are not cloud-ready. That is, data resides in a single place not many. Replication addresses the symptom, but not the cause.
More Examples of Loose Coupling in Networking
BEEP
Block Extensible Exchange Protocol is moving to the standard for managing, configuring and dynamically working on Networking equipment.
In computer networking, BEEP (Blocks Extensible Exchange Protocol) is a framework for creating network application protocols. – Wikipedia
RADIUS
Authentication, Authorisation and Accounting in the network is typically performed using RADIUS. RADIUS is an entirely open standard that allows for proprietary extensions. Again, a very loosely coupled technology that a single network to have multiple vendors for RADIUS clients and RADIUS servers.
SNMP
While SNMP is certainly not perfect, it is a universal interface that can be molded into a shape that works for everyone.
The Failure of Network Management
The only piece of the Cloud Computing puzzle that is missing for the network, is Management tools and platforms that can change the elemental nature of our current network, into a coherent system.
This management process is currently performed by humans. Naturally, these people are highly skilled and trained, and have an enormous capacity to comprehend an entire discontinuous system as either a functional unit such as the “the Internet firewall cluster” or the elemental nature of that system “the internal & external firewalls, DMZ’s, routing, PVLANs etc”. Those of us who work in networks are often unable to comprehend the idea that a network is, in fact, a single organism. The myriad of details hides its true nature.1.

Network Management Systems
Ten years of Failure
We have seen a lot of attempts over the last twenty years to develop “platforms” that can manage our networks and all have significantly failed to do so. Worse, it would seem that there is STILL no solution in sight.
Looking back at the ignominious failure of HP Openview, Tivoli / NetView and BMC Patrol to even remotely be useful to networking and remembering the truly staggering sums of money that have been thrown at the promises made by so-called network management vendors only to deliver nothing. And Cisco themselves have struggled to complete a useful CiscoWorks product that people can really use (although CiscoWorks 3.0 looks like it MIGHT, just might, finally meet the expectations that we had in 1999).
What did I learn from this ? That Network Management is really hard.
Are things changing ? They might be
There are two useful results of [slider title="IP Telephony"]Note that neither is telephony, which is largely being bypassed by mobile phones. Who cares about PABX functions except call centres, which are niche market at best[/slider]. The first is that Management Software for QoS was developed that actually worked. Probably, the tight focus on a smaller aspect of network management allowed the development of a successful product. Now these vendors are growing their product into the larger space of non-voice or non-IP Telephony networks2 and there is hope that a solution is in sight.
Cloud Networking is about the software
When Doug insinuates that Networks have to change to meet the (so-called) Cloud challenge, I would disagree. All the fundamental functionality and capability already exists. Oh sure, a few new standard will arrive but they won’t be a radical change compared to IPv6 and will fill out a few corner issues.
What IS missing, is suitable Cloud Networking management platforms.
Which I find funny, hilariously funny. Because this is what is exactly need for all the other Cloudy thinking that is currently going on. We need systems to manage VM-Ware, or MS Server, or Linux, or deployment or monitoring or whatever. No one talks about changing the underlying technology of Windows or Linux. Neither should talk about the changes to the network.
Conclusion
The Cloud isn’t new, its just the old technology coming around again. With nicer software on top, with rounded corners and pastel colours that attempts to make it feel new. I remain unconvinced that Cloud Computing will end up as the utility model that Nick Carr espouses, and that the marketing hype machine wants us to believe.
I, for one, will welcome decent quality, useful and stable Network Management software that the Cloud will drive. It’s sure to last longer than the Cloud itself.
Footnote
Oh yeah, the CLI won’t be going away. Microsoft introduced Powershell command line after twenty years of denial and forcing us to click our fingers into bloody stumps to great acclaim. If Microsoft can’t exterminate the CLI, nothing else is likely to either.
Footnotes
- And wherein lies one of the greater challenges of Network Design, to not only comprehend the details but to envision the entirety of the system. The most difficult aspect of this is the how to communicate this to a Manager, who has no direct experience of detail since Server and Applications do not have the same complexity. Or at least, the complexity is self evident. A database is a simple thing to understand. [back]
- as Doug calls them, Phone Schleppers [back]




Greg, you raise some very very good points. On some I disageee but for most I am in complete concurrence.
I do not think DNS will solve the workload mobility challenge. Unfortunately since DNS is not a pub/sub model and is cached at the edge and the edge cache may choose to, and often does, ignore the set TTL the change in IP address of a host/server will almost always result in noticeable downtime and even at best will result in all sockets breaking. Neither of which is acceptable if I want to run a business. (I changed the IP address of my blog and it took over 24 hours for all the DNS caches to age out…)
On the other hand, I completely agree with you that when you dismantle the ‘galactic reformation’ type of problems associated with network management or even QoS management and look at a discrete problem set you can really make a useful product. By focusing on the need to mark voice traffic and then place that voice traffic into a strict-priority queue you can make voice easy to roll out on a WAN or Campus. Similarly, if I was to take a narrow focus on marking traffic, setting up a lossless queue, a real-time queue, and an elastic queue, and a bad traffic policer I could probably make a very simple and scalable QoS management for the data center.
The changes I am talking about needing for the network are a) the interfaces to the network for the management to be effective and useful, b) to enable IP address portability (unless you want the IP equivalent of a cell phone that can’t roam between towers), and c) a mechanism to ensure consistent policy is applied to a given workload even if I move it from one provider to another (ot at least be opaque and give my provider the opportunity to read in last known segmentation/QoS state that a particular app/os/vm/workload is expecting)
dg