As a reminder, this is pure opinion and speculation on my part just as it is theirs. Mine however, I’ll say is a bit more neutral since I don’t work for a manufacturer :).
Overlays shouldn’t have to be tied to hardware. I truly believe in network virtualization and that to realize the benefits, the physical network needs to be fully de-coupled from the virtual network. This means VLANs are not used for virtual workloads. To me, it doesn’t matter how many VLANs are deployed; the argument about overlays for hyperscale designs only (networks with 4000+ VLANs) is non-sense. That is like saying if you only have 4-5 servers, you don’t need to virtualize. What about firewalls? What load balancers? What about lab/test/QA/DEV environments? What about DR? Can a company with only a handful of servers not take advantage of VMware SRM in case of DR? Wouldn’t you want a similar solution for networking? Or maybe rather, you want to be the person that says the network is too complex to fully re-create at a DR site with all of the PBR and additional configs currently deployed at the primary DC? Your choice.
Before dismissing network virtualization, make sure the benefits are understood along with all the technical pros/cons. It seems with the lack of integrated skillsets and cross-functional teams that cover compute and network, the focus has become on the technology and implementation details vs. what it can offer an organization.
You don’t need to terminate overlays in hardware to show value
Server Virtualization and Network Virtualization are different. I wrote a few posts about it here and here. I also made the claim, there should be some integration and visibility between physical and virtual just like there is today in the world of compute. A virtual server wouldn’t be placed on a physical server if there wasn’t any RAM left and a virtual server shouldn’t be placed on a physical server that connects to a physical switch that has no more available bandwidth going back to the Core. Imagine VMware coming out with a piece of software that Cisco loads on their switch to bridge the gap. Sounds possible, right? Well, maybe not for Cisco, but maybe for Brocade, Arista, or a company who doesn’t have a virtual switch offering. I wrote about a few options to bridge that gap here. One of them was, hypervisor vendors come out with network agents (I’m not referring to running OVS on a physical switch) to glean information from the physical switches in order to show the physical path a packet is taking through the network in a given overlay. Doing something like this will still allow the virtual network to be fully de-coupled from the physical network, but having that type of integration/visibility will still be valuable for an admin of the environment, but it doesn’t have to be a requirement. That is value in hardware. If the overlays are clear text, figure out a way to get information from packet headers without having to terminate the overlay in hardware :). And it doesn’t have to be a software agent from the hypervisor vendor --- it can obviously also be physical SDN network controller to virtual SDN network controller integration via open or closed APIs.
Data Center Technology (of course, this includes network) Consumption
Admins who administer virtual servers don’t have to be the ones operating and managing the virtual network. Fully agree with Brad there. Many IT organizations still have those hurdles to get over, and it will take time, but until then many network admins will remain blind to what is really going on in the vswitch. Even some Cisco shops don’t deploy the Nexus 1000V because of the burden it puts on the various teams to work together. Within traditional roles, it is conceivable to think a virtual server admin will be one consuming virtual network resources. Network guys architect, design, provision, and troubleshoot, but server guys consume. This is already proposed by the biggest networking vendors out there. But in reality, and even as Brad points out in his first sentence of the blog, “Data Centers exist for the sole purpose to deploy applications.” As the industry gets hung up on the role of the Network Engineer, there are many roles or skills that will shift in the data center, not just the network, and it starts with gluing the technologies together to work in an automated fashion to make consumption easier and reduce the time to deploy leading to greater business benefit in any respective vertical. This is a good read on the subject with focus on the rise of the DevOps skillset (Bushong has some other pretty good articles lately on the Plexxi blog that I also recommend). What I’m saying though is that as more technologies become integrated and automated, the consumer of the actual technology is going to change dramatically ---it’s not just the network guy or gal. Why do you think AWS has had so much success? Anyone can go to AWS to provision new apps without knowledge of deploying networks or servers as long as they have high level knowledge of what their application requires. Shadow IT doesn’t just bypass network teams, they bypass IT. Operations teams and experts will exist, but IT folks shouldn’t necessarily be the consumers of what they support – that distinction needs to be continuously made. I wonder how mad electrical engineers got when the light bulb was invented.
The virtual server admin shouldn’t be the one who actually consumes network resources, but the application administrator or the end user, i.e. the real consumers are the ones consuming data center technology. It’s a matter of outlining the workflow on paper – what needs to happen to deploy application X? This helps visualize all of the steps needed and will ultimately help all parties involved if you go through an exercise like this. It’ll be the rise of the Cloud Architect and DevOps type folks that aid in this process and make it possible. If you are only focused on the network today, there is no reason why you can’t be the person trying to understand the big picture, or the future Cloud or DevOps person. Again, this comes back to being focused on the application or end to end system versus trying to state overlays or any given NEW technology are simply a band aid or “don’t make sense.”
Are overlays the logical next step?
If you want to re-invent networking, maybe overlays are the evolutionary approach after all. If not, let’s begin with carving up flow spaces in the data center, eliminate all VLANs, subnets, and routing protocols… because that is all possible. Maybe if that is the future, we can delay innovation on the network for 20 more years. That may be the future, but [IMO], software overlays are the logical next step. If you deploy a network virtualization solution with a solid control plane that is centralized, it doesn’t have to start and stop with overlays (read: architecture gives a great amount flexibility and isn’t limited to overlays), but if you require certain hardware configurations and ASICs for your virtual network solutions, have you truly deployed network virtualization?
One of the best things I’ve read about network innovation was in this post from Bill Koss:
“Imagine we all worked in a datacenter until the end of 2002. In December 2002 we decided to take a year off, bum around the BVIs and then we opened a coffee shop. Something cool like Blue Bottle in SF or Voltage in Cambridge. After ten years the coffee bug was worked out of our system and we decided to go back and work in the data center we left in 2002. When we got there and looked around we would be in shock. Every element of the modern data center would be different and nearly unrecognizable from 2002, ten years ago. Every element of the modern datacenter had dramatically changed from the servers to applications to storage to devops tools including power, cooling and the physical size of facilities. Everything would be unrecognizable except the network. The network would be the same.”
For me, I wish I tried a career change from 2007-2010. I could have kept my CCIE and foundational network knowledge, gave another career a shot, and came back to the network industry without having to learn anything but protocol extensions and maybe MLAG protocols. Then in 2010, all the fun would have been starting when companies like BigSwitch and Nicira were getting funded and others like Plexxi and Embrane were getting going as well. Good thing I enjoy what I do, because right now, I would not want to be in any other industry and truth be told, I really am okay with not giving another career a shot…yet :).