Like many of you out there, I am a Network Engineer. We have spent much of our professional lives learning about networking technologies. We’ve invested countless hours studying for certification exams, designing customer networks, learning about product capabilities, network scalability, network management and operations. Oh, network operations…dare we count the number of sleepless nights spent in maintenance windows, supporting P1 cases, escalations and performing complex troubleshooting.

I’m proud to be a network engineer, and I can safely say that dedication to the networking craft has paid off. So, how am I supposed to feel when I hear people say that networks are “holding us back?” That application deployment and speed of provisioning are compromised by “archaic and complex network processes?” What are they getting at? This is the world that we have come to know and love.

If I stop for a minute and try to understand these complaints, I quickly discover I have experienced all of them, in one form or another, throughout my career. You know what I am talking about my fellow net-heads:

  • That 500-entry access list that you dare not touch for fear it will cause some unexpected and catastrophic problem.
  • Trying to figure out what the heck this undocumented, 1000-line running configuration means.
  • The never-fulfilled promise from my networking vendor(s) that different product families, sold by said vendor(s), will one day have common configuration and management interfaces (APIs).
  • The management GUI that only exposes half of what my hardware can do because of that same lack of good APIs.
  • The sluggish performance I experience because device management GUIs have to connect via SSH/Telnet and use CLI parsing or screen scraping to compensate for the lack, again, of common management APIs.

As proud as I am of what I know about networks, I have to admit that sometimes it feels like I am working at dial-up speeds in the era of broadband. It is true that network operations are stuck in the past. But there is good news — very good news. It won’t be that way for long. The world of networking is changing.

Recently, the industry has been making strides around two very disruptive concepts: Network Virtualization and Network Overlays.  Network Virtualization provides a complete set of tools to help customers move towards the network automation Nirvana. Network virtualization does for networks what server virtualization did for servers: it decouples the underlying physical layer from the applications that require specific network services. The physical layer need only consists of a resilient, highly-available IP transport, while the virtual layer is a collection of network capabilities, ranging from basic L2 connectivity to advanced routing and security.  Intelligence, in this new architecture, moves into programmable software.

So if the world of networking is changing, what does this mean for our skills? Our roles? Our place in IT? What are we expected to know? I can’t say for certain, but I know one thing, we’re going to have to change.

The reality is there’s nothing here to fear. Knowing applications means we will have to learn about things that are relevant to application owners, such as scripting, APIs and maybe even some basic programming and coding.  But chances are you are already doing some or all of these things. Workload virtualization and virtual switching have forced us to dabble in the realm of software programming and scripting. Nowadays, who doesn’t know some basic PowerShell? Who hasn’t been exposed to some type of XML interface or hasn’t heard about centralized management and orchestration? It might have taken a few Google searches and some experimentation, but in the end, we got it.

Even if you haven’t done these things yet, trust me when I say that the learning curve won’t be steep. Crowning this “application hill” will be far less difficult than climbing the “network mountain” you have already conquered. Switching fabric technologies, routing protocols, load balancing and firewalls are very complex things to understand, and you already know them!

In the datacenter, network virtualization has fast-forwarded networking and synchronized it with its cousin, server virtualization. A colleague of mine, Brad Hedlund, calls this alignment “compute and network symmetry.” The two can now work together, affect each other and evolve more rapidly in unison.

So rather than fear the change that’s upon us, imagine a world in which:

  1. Network policies and security follow the workload, regardless of where the workload is placed. No longer do we have to maintain a 500-line ACLs in multiple points of our networks to account for all traffic flow permutations. Define your policy set once, attach it to the workload, and you’re done.
  2. Configuration and Management interfaces are WYSIWYG, by design! No more back doors, hidden features, and out-of-band configuration. This is because these management tools will leverage well-documented, robust and secure APIs, capable of expressing the network configuration and its state optimally, as opposed to a flaky asynchronous CLI integration.
  3. New features and capabilities are incorporated at software speeds, not hardware speeds.
  4. You can create recovery points for your full network identity and state, with instantaneous convergence and propagation, thanks to a centralized management construct (controller).

Do you think you have what it takes to make the transition to become a Network Virtualization Engineer, like me? Let me know what you think.

Marcos Hernandez, Network Virtualization Engineer

CCIE # 8283