vCloud Director: hand the network over to server admins
A few months ago VMware decided to kick away one of the more stubborn obstacles in their way to Data Center domination: the networking team. Their vCloud architecture implements VLANs, NAT, firewalls and a bit of IP routing within the VMware hypervisor and add-on modules ... and just to make sure the networking team has no chance of interfering, they implemented MAC-in-MAC encapsulation, making their cloudy dreamworld totally invisible to the lowly net admins.
After you vent your initial rage at the stupidity of another unnecessary (politically-induced) layer in your Data Center, try to find the silver lining: if the server admins are brave enough to implement VMware vCloud Director Network Isolation technology (VCDNI, the MAC-in-MAC encapsulation), the networking infrastructure becomes exceedingly simple. Once TRILL, FabricPath or 802.1aq become reality, building a huge Data Center network is a piece of cake.
However, someone will still have to cope with all the complexities of load balancing, firewalling, NATs, VLANs etc; just make sure your CIO (and everyone else involved) is well aware that the server team is now responsible for everything beyond point-to-point layer-2 transport.
To read more about this “brilliant” idea, head over to SearchNetworking.com where my wonderful editor Rivka Little has just published my vCloud Director: Sure, hand the network over to server admins Fast Packet article.
And just in case you’d like to learn more about the real-world Data Center architectures – there’s the Data Center 3.0 for Networking Engineers webinar (buy a recording or yearly subscription).
But I am going to take the other "view" on this, not trying to troll/start a flame war, but just kickstarting the discussion.
To start by quoting you: "And now a virtualization vendor is trying to persuade people with limited exposure to internetworking issues [...] to rebuild the hodgepodge from scratch using untested virtualized components and a GUI. Wish them luck ... and make sure your CIO knows who's taken over the responsibility for the stability and security of the new cloudy infrastructure."
Funny because I've actually heard this statement a numerous times before for the last 10 years. Let's rephrase.
"And now a networking vendor is trying to persuade people with limited exposure to SS7/PBX issues [...] to rebuild [...]"
I've heard your statement before from both telephony people and SAN people.
"Letting network admins and system admins run a PBX? Connecting the the phone to the network and using IP network as a transport? Never going to or should happen, because computer people do not understand the complexity of voice systems and never will, and therefor cannot learn how voice systems work."
FCoE and other insertnametechnologies that make it possible to run SAN over the same equipment as the network (or so to speak). The SAN/Storage guy says: "ehh, no storage is ever going to use IP as a transport. That means having to work with the networking people, and they don't understand how complex storage solutions are, or how to manage a network that SAN would rely on.
I'm not going to go into a debate about what specific technologies the server-admin should or should not get access to.
But the way I see it is that both the network team and the server-admin team will be crossing eachother fields.
Even though server-admins have "limited exposure to networking" today, after a few years that may change.
Just like a few years back network and server-admins had "limited exposure" to voice-related technologies, and a lot of SS7/voice guys said "hah! voice over IP, that will never go well, the network department doesn't know a thing about voice, wish them luck".
The point that I'm trying to come across, is that "networking" is working their way into the server admin field (starting "small" with buzzwords like UCS), and providing a switch for vmware (nexus1k). It's only normal that the server admins would meet you half-way down the road.
It's great that you've mentioned SS7/PBX, it's a perfect example: Internetworking vendors with no voice knowledge rushed into this space trying to persuade everyone to replace their PBX with VoIP. While VoIP was easy to implement in small networks, the solutions were not ready for large-scale deployment for years (and it's still extremely hard to get anyone with deep SS7 knowledge when you need it).
We've got our fair share of bumps and burns trying to implement VoIP with SIP trunking internally (luckily we usually eat our own dog food before trying to sell it to our customers) and I'm positive a lot of people had similar experiences.
It's not that person A cannot learn how technology B works - you usually under- or over-estimate the complexities of unknown technologies. It's the same with some server admins, who view networks as an obstacle, not realizing (without prior in-depth exposure) that there are numerous reasons they got as complex as they are today. Or, to turn the tables around, I would never agree to manage a server farm - I'm simply not qualified for that.
Last but definitely not least - I perfectly agree with you that the networking, server and storage people will have to "hug it out" and it's totally irrelevant whether they are in one team or several teams - what's important is that every function in the data center is designed, implemented and operated by sufficiently knowledgeable and qualified people.
I myself grossly underestimated the complexities of voice when entering the UC field, but am gradually gaining a better understanding. I have to agree with Ivan in regards to people need to better work together in the industry. Could a move like this precipitate a mindset instead of server admins "seeing the network as an obstacle" instead "getting exposure seek to better understand the logic and work with the existing network team"? Could this help foster a better collaborative environment between different teams? Too early to tell, and I think it is the human quotient that will speak the answer rather than the technology being available or not.
1. Some isolated server environments that for several years have struggled with a lack of support, interest and understanding from the network environments, will take this opportunity to get "rid" of the network people. Some of these undertakings will crash and burn... =-O
2. Some isolated network environments will either fight against everything that tastes of virtualization and cloud computing, or try to overtake the server admins part (it cannot be too difficult, and servers are just minor parts of the network anyway... ;)). Some of these undertakings will crash and burn... :'(
3. Some server and network environments will actually manage to collaborate, and these will most probably be tomorrows winners. It is important to have a decent respect for other fields of expertice, but it is even more important to be interested in other fields and to be able to learn from each other.
Both netporks and servers are IT solutions, but both of them still struggle with to little user orientation/friendliness, poorly developed user interfaces and most larger IT projects still struggle to deliver upon the promises and budgeted costs.
Complexity is something we will have to focus more and more on, in the near future.
Most larger networks and server installations have now outgrown what is possible for a single person to understand, know and control. We will see even more of the old server-versus-network challenges, but also increasingly more of network-versus-network challenges.
So the answer might be to manage the competence and knowledge, but in a structured way and in a collaborate way.No one will know it all anymore, so we need to organize our efforts and collaborate, in tomorrows workingplace.
We should stop to focus so much on establishing boundaries, like networking and servers - but focus on solutions more. And solutions will contain elements traditionally thought of as networking and server infrastructure... Not to mention applications... ;)
Some people will be specialists, but that will require even more knowledge than before, and fewer will probably have such high knowledge levels.
This is the same development as we have seen in other areas, like web portals etc.
But as Gartner mentioned in a recent report about virtualized server environements:
- These virtualized environments will probably be less secure for 2-3 years time. But when 5 years have gone, the environments will probably be more secure again...
The same will probably be the same for cloud computing, vCloud, etc.
Take care, but collaborate... :-D
In a cloud environment, where a VM is abstracted away from the physical infrastructure, you need to solve the problem of how to make sure the app networking still functions regardless of where the VM runs -- whether in any of your own data centers, or in an external cloud data center -- without requiring re-configuration of physical networking gear every single time.
All of the cloud stack vendors solve this in the same way -- by introducing a network abstraction layer. The benefit, which you describe as "unnecessary", is that you can have a virtual networking config for a set of VMs and run those anywhere, on any cloud, without change. It's a huge benefit.
So... the task for Cisco and other networking vendors, is to figure out how to make this work on their infrastructure. For example, by integrating with vCloud Director. Trying to stand in the way of VMs moving to cloud infrastructure simply isn't a tenable position -- the tide is coming in, and you'll just drown.
There are numerous ways to solve the network abstraction problem. We had VLANs, VRFs, VDCs ... for years and some of those things can be made extremely scalable.
If you decide to reinvent the wheel, bypass everything that's out there and hide what you're doing in MAC-in-MAC encapsulation, I would argue that "solving a bona fide DC problem" (which definitely exists, I've been blogging about it from different angles for quite a while) is not your first priority.
As for the VM tide ... let's see. Maybe, just maybe, some people will discover you can code your applications in some more sensible way using PAAS. Ah, forget that, it's not going to happen :-P
This from what I have seen of vCloud director ( I did the labs at VMWorld 2k10).
I do not see most Corporations having the Server folks do the advanced vCloud networking pieces. I see perhaps we assign pools for them to use. I also see someone like a VMWare-knowledgeable network guy who works hand in hand with the VM/Server guys to get this configuration in place. This is similar to what is happening now with vDS' like the Nexus 1000v and having VM infrastructure in DMZs.
Now, as a network admin, in vCloud Director, I am giving IP pools to the Server Build folks. This is something they already had from us, but were using an excel sheet or something similar. If you were not already providing pools of IP for them to use, you most likely were slowing down the VM build process.