Home > Blogs > The Network Virtualization Blog


The Future For Network Engineers

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

 

 

 

13 thoughts on “The Future For Network Engineers

  1. Joe Onisick

    I love the hand waving magic wand trick with “Network virtualization does for networks what server virtualization did for servers.” Network and server virtualization are not analogous. Network virtualization is analogous to VMs running on VMware player where the VM has no hardware visibility and the hardware is not VM aware.
    This is not a small difference and white washing the gap here will lead customers down the same path of pain that “Desktop virtualization is just like server virtualization” did. Server virtualization relies on an OS that is tightly coupled with the underlying hardware and uses that coupling to carve out resources for known virtual hardware subsets. It does this down to the CPU clock cycle, i.e. deep integration. Network virtualization on the other hand provides no such hardware integration.

    Regardless of any possible features, capabilities, business benefits, etc. of Network Virtualization leading customers down the path blindly by telling them it’s “server virtualization for the network is doing them a disservice. Network virtualization is virtualized applications replicating network services and an overlay wrapper to allow a physical network to blindly pass those packets. Call it what it is.

    Joe

    1. Marcos Hernandez

      Hi Joe,

      Like yourself, I believe the analogy with server virtualization will only take us so far. This is a new industry which will eventually stand on its own definitions. That said, it is useful to go back to technologies and paradigms that accomplished some of the same goals around automation. My line about Network Virtualization doing for Networks what Server Virtualization did for servers was not stated in a vacuum, like you quoted it. In the next couple of sentences I talk about the importance of a reliable transport as the supporting mechanism for a successful network abstraction.

      At the end of the day, we are trying to solve a very real business problem and we truly believe this is the most adequate approach to do it.

      Thanks for your comments!

      Marcos

  2. Brad Hedlund

    Marcos,
    Excellent post. I think you’ve stated it well, that Server Virtualization and Network Virtualization are analogous in ways that matter to the business, i.e. both providing *agility* through automation, mobility, decoupling, and architecture independence.

    On the other hand, some folks seem to want to obsess over terminology — “Regardless of any possible business benefits” — with a slew of flawed arguments about implementation details. Definitely not a substantive discussion. Though I’m not surprised to see this rhetoric coming from a traditional network hardware vendor desperately clinging to the old 1990′s pre-virtualization era, where infrastructure services are tightly coupled to their hardware. Remember DEC VAX?

    Cheers,
    Brad

    1. Joe Onisick

      Brad,

      Thanks for the detailed bashing, best to use my name though, keeps things up and up. My argument with the terminology is actually an important one. The messaging going to VMware customers is very much that Network Virtualization = Server Virtualization. While this is a cute marketing game it will only lead them to deployment pain in the future.

      If you’d like to discuss the technical and business merits of the solution and drop the nomenclature conversation for a while, my door is always open. Writing everything off as “rhetoric”, or describing me as coming from “traditional network hardware vendor” is just petty and, as you know, false. I’ve been in “traditional network vendor” for a shorter time then you’ve been out of one.

      If you do choose to go the technical conversation route, I’d encourage you to avoid claiming anything you can’t answer to is “FUD” or rhetoric.

      Joe

  3. Juan Lage

    Nice post Marcos. I disagree on many of your ideas, as you know, but I liked the post nonetheless. I also disagree with Brad’s comment to discredit an argument by saying it’s hanged up on terminology.

    In my opinion, semantics matter. Because words, terms … they communicate ideas, and if those ideas are miss communicated, even if they are good ideas, they’ll perform poorly.

    I agree with Joe’s comments, certainly. I do not dislike overlays, I just don’t see them as the wholly grail of networking. But of course when all you have is a hammer, everything looks like a nail :-)

    Finally, you say “this is a new industry which will eventually stand on its own definitions”. But dude … this is not a new industry. It’s the same industry. Many of the problems of networking are intrinsic to how Ethernet and IPv4 operate. You can move up certain network services with an abstraction layer and perhaps gain efficiency and/or (a perception of) simplification, and that may be a win in many cases, where it will succeed. But it will *always* come at a cost somewhere else … as long as ethernet remain ethernet, and IPv4 remain IPv4.

    cheers buddy ;-)

    juan

    1. Marcos Hernandez

      Thanks for reading my post and commenting Juan. I value your opinion and friendship, even in we don’t see eye-to-eye on this particular topic.

      Un abrazo,

      Marcos

  4. Steven Iveson

    Hi Marco. Brad and I have kind of been ’round the block’ regarding comparing server and network virtualisation, in the comments section of his original What is Network Virtualization? article. Thanks to that I understand and appreciate the viewpoints that you share around that comparison and the possible affects of developments on employment in networking. However I still find myself feeling somewhat uneasy, even in short format article such as this, with a) how easy it’s made to sound; the lack of detail and clarity (on both subjects) and b) that comparison, despite the context.

    I appreciate the point that you are comparing server and network with regard to the business benefits but I still don’t feel you’re clear on that point. I appreciate this is a vendor related blog and that will be an influence but the technical realities are still glossed over and that does concern me. Is this article aimed at a manager or an engineer? We live by details, even when the subject is business.

    On the subject of careers, I generally agree with your point (I’ve done my own post on the subject and mostly reached your conclusion) but as with others, I don’t find the lack of evidence or detail actually that reassuring. I’m not saying my own post was any better, but I tried.

    Around your points on GUIs, APIs, inertia, fear of change and the business benefits themselves, I’m in complete agreement.

    Regarding Brad’s symmetry, I think Cisco really went and ran with that with all their talk of ‘affinity’.

    1. Marcos Hernandez

      Hi Steven,

      This blog is a platform for high level discussions, vision and trends. There is another blog area for more technical topics and I am planning to post content there too, in due time.

      Please do not confuse the vagueness in my comments regarding actual product implementation with something else. We are working very hard here and announcements will follow in due time, with details of our portfolio of solutions.

      By the way, Cisco did not coin the term “affinity”. Another SDN startup did. In any case, they both seem to be proposing that customers purchase a switch from them, as in “more hardware”.

      I am glad to hear that yo agree with the main point of my post and what the future holds for us, network folks. It is going to be fun and exciting, that’s for sure!

      Thanks,

      Marcos

      1. Joe Onisick

        Marcos,

        Interesting point on the “more hardware” here. Is NVP a hardware free solution? Can a customer deploy it without new hardware? Better question would your architects recommend deploying it at scale on the existing network equipment if that equipment was not non-blocking or close with 10G+ throughout?

        Don’t worry, I’ll answer that for you: “Um, uh, well, it would depend.”

        Joe

      2. Michael Bushong (@mbushong)

        I work at Plexxi – that other SDN company that coined the affinity term. Hard not to jump in here when you kind of call us out.

        The VMWare saber rattling on HW and SW is bizarre to me. Staples in the VMWare marketing assault like vendor lock-in are certainly not unique to hardware, so I find the discussion either lazy or intentionally misleading. After all, it wasn’t that long ago that VMWare used its incumbent position to jack around licensing and pricing before having to retreat due to customer backlash. Funny that it was actually VMWare’s competitor Microsoft who was first to ditch the shoddy licensing model. VMWare is hardly altruistic.

        At the end of the day, there is a HW component to networking. And the fact that Cisco and Plexxi offer this does not make them any less qualified to solve problems around delivering end-user experience. In fact, VMWare actually points out the need for a functional underlay over and over. The fact that VMW doesn’t make or sell that HW simply means VMWare doesn’t have all the components necessary for the solution. Disparaging other companies because they do seems off at best, dishonest at worst.

        And it turns out that both Cisco and Plexxi have a heavy software component to their solutions as well. For whatever reason, VMWare never talks about that.

        The marketing campaign being waged over the past few months by VMWare is intentionally confusing to customers and more than a little disingenuous. I don’t know when the Nicira technical magic turned into a FUD showdown. But it’s a poor representation of what used to be a reasonably genuine technical dialogue led by brilliant technical minds.

        The real philosophical differences in how to solve the networking issues ought to be the topic of discussion. Do you throw bandwidth or intelligence or a mix of both at the problem? VMWare has said the answer is bandwidth (and gotten some traction there with Arista obviously). Cisco and Plexxi have argued that you traffic patterns are not random or uniform except if you look at them in aggregate. I’d say both of our central theses are that concluding there is nothing intelligent to be done amounts to giving up on solving hard problems.

        There are clear differences in approach. Why not debate those instead of using labels like “traditional” and “hardware” vendors? Ad hominem attacks are lame. Especially when they are masquerading as technical debate by technical guys who ought to know better.

        Mike

        1. Marcos Hernandez

          Mike,

          I welcome everyone’s comments and I am all for expanding on the technical debate. I want to bring it back to what this means for Network Engineer though, the original topic of my post. Would appreciate everybody’s insight around those lines.

          Thanks,

          Marcos

          1. Michael Bushong (@mbushong)

            Happy to stay on topic – but you gotta do the same.

            As for network engineers, networking (and datacenter in particular) is moving beyond speeds, feeds, and features. When you get past a pure feature arms race, emphasis shifts to integration. It’s about price and convenience, and this is why devops is important (along with easing the provisioning burden).

            Where I think this gets interesting is the blurring of lines between different silos. While the focus is on technology, I suspect organizations are not actually ready from a process and skill set perspective. Will be interesting to see how this impacts buying decisions, which will inform R&D direction for companies concerned with quarterly sales (ie, all of them).

  5. Armarn

    I hope this wont happen as i only know networking.. Does anyone have latest dump for vmware exam?

Comments are closed.