When we think about networking, we think about things that go bump in the wire—things that place bumps in the wire. Such things could be switches, load balancers, firewalls, routers, gateways, etc. The list is not all that long, thankfully. Things that put bumps in the wire are at odds with software-defined networking (SDN). SDN relies upon key services to exist. These services are DNS, identity management, and key management. Without these, many systems would fail outright. However, they are not considered network functions. Network functions are considered to be the bumps in the wire we need to make applications work. The goal of network functions virtualization (NFV) is to streamline this process, to reduce complexity while maintaining compatibility. NFV and SDN together lead to an interesting mix of hardware and software, and some of these just do not interoperate well. Is there a better solution?

We mention three distinct types of services that networking brings:

  • Transport: Wires, cables, etc.
  • Always-On, Always There, Anywhere Services: DNS, identity management, key management, IP management, and routing
  • Network Functions: Load balancers, firewalls, intrusion detection and prevention, web application firewalls, cloud-aware access brokers, management-aware access brokers, etc.

Now, my claim is that all of those are network functions; however, if we stick to the traditional language of networking, we are looking at three distinct areas. In general, that is already too complex. Why are we doing this? Because we are tying to take a new concept and shoehorn it into an old way of doing things. So why SDN and NFV? Let us look at this differently.
SDN is bringing to the world a new way to transport data over existing hardware while making always-on services available where they are needed. However, we still want to put bumps in the wire. Is there a better way? The answer is NFV, but a very smart implementation of NFV. Or “just enough” NFV. Some data does not require every bump in the wire. Some does. We need to put in just enough to satisfy security, compliance, and other requirements. We need to decide if a bump in the wire is necessary or if that data can be sent somewhere else to meet compliance requirements as well as meeting our business goals. Should there be splitters instead of bumps? I spoke about this in Cloud: The Great Disaggregated Everything. The concept has not changed.
However, until we combine our thinking, we will be worrying about transport layers, our existing always-on always-available services, and network functions as different elements. It is simplistic to view the wires and other hardware as nothing more than our roadway or rail system. But there you have it; that is what it really is. It is the protocols we use, the software that makes networking the complex beast that it is today.
We need to move away from bumps in the wire to something smoother, a transport that includes all the necessary functions. We also need to determine how many of those functions are in reality services: services such as DNS, which we can use via other APIs. Can we leverage what is already available? This is the dream of the containerized world. This is the dream of tools that hook together APIs; they become the flow controller. Eventually, where we send out data will have hundreds of services involved. Those services include which transports to use: higher performing ones vs. lower performing ones. They include encryption, DNS, identity, IPAM, routing, and many other aspects of modern computing.
We need intelligent brokers as well, not just intelligent networks. Perhaps these will provide the capability to manage the data path between services: Open Service Broker API, SmartBear’s ServiceV Pro API Virtualization, and others. Our services need to become as available as DNS, identity, and key management. To do that, we need to switch from thinking that the network controls our service, but the service is controlling the network.
This is a serious change in thinking, perhaps even radical. Some companies have made that leap. Others are still considering it. Where are you in your network rethink? Where are you in deciding what to do with things that go bump in the wire?