Networking is a Service, and you are the Service Provider

The status quo approach to Networking is the biggest barrier to realizing the full potential of Virtualization and the private, public, or hybrid cloud.  We must re-think how Networking *Services* are delivered, in a way that comports with automation, decoupling, pooling, and abstractions.  I would argue, the solution is a more software-centric approach — Network Virtualization.  But more importantly, we must re-think how we view Networking as a career skill set and the value we bring to an organization.

That was the mesage of two keynote talks I recently gave at the Sydney & Melbourne VMUG user conferences.  The title of the talk was Three reasons why Networking is a pain in the IaaS, and how to fix it“.  I will share the slides and a brief summary of that talk in a subsequent post.  But before I do that, please indulge me in a heart-to-heart chat from one long time Networking professional (me) to another (you):

I emphasized the word *services* above because if you really think about it, that is what Networking really is — Networking is a Service. It always has been, and will always continue to be a service.  A service that will always be needed. To some, that may seem like an obvious statement. Congratulations, you are enlightened. But to others, Networking is still viewed as a set of hardware boxes with ports and features.

What box should I buy? What features does it have? How fast is it? How do I configure that box? I better buy a box with all the features, just in case I might need it. I better buy a box with with lots of ports, just incase I might need it.  And so on. And you begin to associate your career value to the knowledge you have in evaluating, configuring, and managing these boxes and their complex feature sets.  At this point, the mere thought of a software-centric approach to Networking can be quite unsettling.  If networking moves to software (read: x86 machines, hypervisors, SDN), well, that makes me less relevant and/or I don’t have the skills for that.  And to appeal to your anxieties, the hardware box vendors serve up a healthy plate of Fear, Uncertainty, and Doubt assuring you that software-centric networking will fail, keeping you comfortably stuck in your Networking-is-a-hardware-box comfort zone.  Meanwhile, the organization continues to see your value associated to the efficient operations and deployment of it’s infrastructure *hardware*.  When the platform changes, and it will, where does that leave you?

Your service on any platform

Contrast that to a mindset where you view Networking as a *service* — a service that can be fulfilled by any underlying platform, architecture, or another service (hardware, software, external providers).  You know that the ideal platform will change over time, because it always does (Client-Server, Virtualization, Cloud, Everything as a Service).  You make it your job to recognize when those changes are starting to occur and prepare both yourself, and the organization.  You’re able to comfortably adapt to these architecture changes because you own the service of networking — *you* are a Service Provider.  Things such as Connectivity, Routing, Security, High Availability, Access, Performance, Analytics, Reporting, just to name a few; these services are perpetual and platform independent.  You’ve put yourself in a position to help the organization navigate the ever changing landscape of applications and IT architecture, keeping the business one step ahead of its competitor that’s still stuck on legacy platforms and architectures.

Your value to the organization is much different now.  It’s no longer a situation of “I need this person to configure and manage that gear over there”.  Rather, it’s now in the realm of “I need this person to keep the business competitive and relevant in an ever changing technology landscape”.

I believe Network Virtualization (e.g. VMware NSX) really enables this shift in both platform, architecture, and career value.  Networking *services* (the things we really care about) are finally abstracted and decoupled from infrastructure, and become portable across a variety of architectures, platforms, and for that matter, service providers.  It makes it easier to provide a clean separation of the (more interesting) services that provide value, from the (less interesting) infrastructure that supports it.

Over time, everything will change — both the services and the infrastructure, but probably not at the same pace.  The decoupling of services from infrastructure, provided by Network Virtualization, allows us to:

  • Change, add, and optimize services quickly — without changing infrastructure
  • Change, add, and optimize infrastructure — without changing the services

It’s that basic freedom that allows Networking to be elevated and identified as a perpetual and discrete service to which the organization can associate tangible business value.  And the person who owns that service is linked to that value.  There’s a hero waiting to be made here.  Is it going to be you, or someone else?  If you ask me, there’s no more exciting time in Networking than right now.  The opportunity at hand now will not come around again.



  1. says

    Reading your post has come to my mind a little story called “Who moved my cheese?”, which is “An Amazing Way to Deal with Change in Your Work and in Your Life”.

    Definitely, Networking *services* is our new cheese ;).


  2. Brandon Rebbe says

    We saw this change in the phone world with ip telephony, the security industry with ip phones, now in the av world with gc, telepresence and new protocols like avb. The is a great read Brad..

    • says

      Hey Brandon! Spot on. I remember those days. There’s a lot of similarities with the anxiety that ultimately turned into a stellar career opportunity — for those that embraced IP Telephony. Remember how the PBX guy became anxious and afraid that Network Engineers would just end up doing all the voice stuff?
      As we all know, what ended up happening is that IP Telephony brought a whole new level of service to what was just dial tone, and elevated it to collaboration *services*.

      The PBX guys who embraced the change to IP Telephony went on to become Collaboration Specialists, a more business relevant and valuable career, while the Network Engineers continued with their usual job of providing a robust network.

      The same very same thing is happening right now with Network Engineers, and Network Virtualization.


      • Donny says

        Brad, I may contend however, that the collaboration paradigm was expanding while NFV is consolidating. When NFV is fully realized, the network segment, security, addressing, etc. will be programmatically deployed and consumed. No Network Engineer required for continual operations (only design and instantiation).

        So, while PBX -> VOIP -> Collaboration created a number of opportunities, Network -> Virtualization -> Automation will shrink the LAN Network Engineers. WAN and Security may pickup the displaced.

      • David Klebanov says

        Excellent analogy, Brad! I was there when IP telephony was taking its first steps. It took a company who understood IP communications to change the world. Traditional TDM PBX manufacturers, who over time tried to imitate, largely failed because they lacked the appropriate expertise and understanding. I observe a similar trend now where network virtualization is becoming a battleground between the companies who understand the intricacies of what it takes to build a viable solution and the ones who dip their toes in the water hoping customers will give them a break.

        Interesting times are ahead :-)


        • says

          In my view, it took a company that had no legacy business in Voice, to change Voice, yet had the expertise in communications. Traditional PBX manufactures were just too late to the game, as they viewed VoIP as a threat to their core business. I think the same will be true with Network Virtualization. It’s going to take a company that has no legacy business in traditional networking, and one that has expertise in Virtualization.


  3. Asa Kabazzi says

    Network Engineers are at another proverbial crossroad, I have been mulling about this over the last few weeks as it is this is a new crest in a very old wave. Reading through Nicholas Carr’s book “The Big Switch” he explains how companies used to have their own steam power generations plants, along with managers, engineers and technicians. Companies were directly responsible for their own primary power generation, they bought coal and had steam powered generators to power their offices. Then some engineers in Germany and Italy envisioned a world where electricity was delivered as a service using AC and not DC. There was push back from among others Thomas Edison himself, with public demonstrations demoting AC as dangerous. The same arguments that were made by TDM engineers about VoIP and were made by DC engineers about AC and are being made by Network engineers about SDN. You can also through in Mainframe engineers as well.

    Network Engineers need to be serious about the future of their careers and carefully consider the times ahead.

  4. Km Muma says

    I notice when you said “Change, Add, and Optimize Infrastructure” you left off the “quickly” … :-)
    But – a good read/heads-up. I’m guessing, that as a hardware company, Cisco seems to be devoting a fair bit of resources to UCS – interesting.
    Thanks for this – always a good read.


Leave a Reply

Your email address will not be published. Required fields are marked *