John the plumber?

After Cisco’s UCS announcement, the media fight with HP is heating up, it is getting an election time feel. HP asked in a PR piece that was mentioned here, whether you would  “let a plumber build your house” meaning whether a mere networking company could be responsible for the whole data center. So John Chambers is now the plumber?

Greg Ferro pointed out that it is really not HP, who strikes back, but Cisco. Over the last years HP ProCurve switches have gained market share. Personally have seen many brand new VMware environments that where sold by an HP team and included HP blades and HP ProCurve switches.

In money terms, Cisco has more to lose if HP challenges them in the switch market. Leaving all questions of technology and competence aside, switches are still a high margin business for Cisco, servers are low-margin for everyone (though Sun may not have heard the news). A typical Cisco 48-port Gb switch starts around $6k, a similar HP ProCurve switch costs around $3k. In both cases we are talking of highly commoditized technology. A price premium of this order of magnitude just does not fly in the server market.

But Cisco has more to win, too, simply because the server market is a lot larger. In order to make servers profitable enough for Cisco standards they have to completely change the market structure. And UCS cleary is designed to do just that. Cisco is not really entering the server market, they are trying to supersede the server market by a new “unifed compute market”.

If you think Cisco cannot move it new markets, read what was written when Cisco started to push their voice products. “They have to sell to a different set of people”, “Voice is different” and “Lucent, Nortel and Alcatel have been doing voice for 100 years”. Have you looked at  Lucent/Alcatel and Nortel stock prices recently? The real question will not be how different the markets and technologies are, but how well HP and IBM execute – and they are a completely different calibre then the traditional phone people  (with Lucent-bred CEO Fiorina out of the picture, that is).

In Hoff’s metaphor, Cisco is Brock Lesnar, the wrestling star who moved to Mixed Martial Arts (MMA). First he lost because he was only a superb wrestler (i. e. plumber), but as he picked up the other fighting styles he won the UFC (Ultimate Fighting Championship title. Nice comparison that makes a very valid point, as Cisco has proven their ability to learn new tricks. But I think Cisco is not trying to become UFC champion (i.e. beat HP and IBM at their game), they are trying to be the next UFC. It is about starting a new, bigger league of their own.

What are the other networking vendors doing about virtualization?

This is only partly a rhetorical question,  I actually would like to understand better what they are doing. But impressions go a long way. Everybody in the virtualization space talks about Cisco when talking about networking (and there has been a lot of talk in the last year). At VMworld in September Cisco was all over the place (with Nexus 1000V and vFrame for example), but the other networking players were noticeably absent. OK , there was Checkpoint with a pretty impressive announcement of a virtual version of there firewall technology,  but I was actively looking for the others and there was not much to be found. So I am trying to keep track. This post is starting with Juniper, the next one will be on Force10 (for no other reason than the fact that both had announcements this week).

In December Juniper came out with a VMware Implementation Guide, 7 months after Cisco came out with their guide (jointly published with VMware). But then Juniper only started to ship their first switches around that time. This week Juniper appeared prominently in an IBM cloud computing announcement (sorry for throwing virtualization and cloud together here without further explanation, but I think they should be thrown together). An interesting announcement – as far as IBM was concerned. Juniper featured in the context of hybrid clouds (connecting private and public clouds). Extremely interesting from a networking perspective and much closer to Junipers routing roots since their solution seems to be nothing but old-fashioned MPLS. Proabably not different from MPLS solutions that Cisco could provide, but IBM is a strong partner, and the link-up is naothe indication that IBM and the other large  datacenter players are looking for alternatives to Cisco; they can neither be happy about nor surprised by Cisco’s recent server announcements.

The verdict: Juniper is behind Cisco on may fronts when it comes to VMware-style virtualization, but mostly because they are new to the switch business. The speed at which they are catching up is fairly impressive.

Minor confusion about the release date of Cisco’s Nexus 1000V virtual switch

Colin McNamara’s blog is usually excellent, all the more annoying that his post titled  Cisco releases Nexus 1000v  virtual switch for VMware created a lot of confusion by not distinguishing between the terms “announces” and “releases” which mean entirely different things in marketing speak …

Just for the record, Cisco’s announcement states: “The Cisco Nexus 1000V distributed virtual software switch with VN-Link capabilities supported in a VMware Infrastructure environment is expected to be generally available to customers in the first half of 2009.” Most observers agree that this means the release date will actually be June 30, 2009 at the earliest. Btw, the “V” in “1000V” is capitalized.

If you follow the discussion it is, of course, impossible to release an ESX integrated switch until VMware releases the next version of their virtual infrastructure. The current VMware version just does not have the hooks to plug in a switch that replaces the built-in vSwitch.

Except for the word “releases” in the title, Colin’s post is highly recommended reading. What I like best is his analysis of the lack of people that can do both networking and virtualization and the passing remarks about all you have to do in order to do appropriate network configurations in the virtual server world. And, most of all, the post is fun to read!

</tom>

No VMotion around virtual or physical firewalls, please

Chris Hoff’s BlackHat presentation titled “The Four Horsemen of the Virtualization Apocalypse” was described here by Ellen Messmer to Chris’ dislike. Her spin may have been slightly too negative, but in any case she reports interesting points, among them Chris’ comment that it just won’t work if you VMotion a virtual firewall (VFW). While Chris is right in general, moving a VFW will in fact work in some simple corner cases, basically when both locations are indistinguishable in networking terms (same subnet, same VLANs, no NAT on the VFW itself etc.). So you can VMotion a firewall, but just a little bit … if you are not so lucky all hell breaks lose.

What’s more worrying is that all the same problems will happen if you VMotion any VM in presence of any firewall (virtual or physical): either you VMotion between two locations that are identical in terms of routing, VLANs etc. or you are in trouble. Any relative motion between firewall and VM will create the same troubles.

The really revealing bit about Chris’ comment is that most VMware deployments are still so simple that all VMotion happens in the simple corner cases. So don’t get too close to your firewall when you do VMotion.

ps. I have, of course, my own agenda here.

Virtual machines and the virtual DMZ

An article by Edward Haletky made me think about ESX and the DMZ in general. The schematic picture is simple: services that need to be accessible from the Internet are in the DMZ (the demilitarized zone between the internal enterprise network and the Internet, in case you wonder), all others are in the internal network. In between, we place a 3-port firewall, one port for the Internet, one for the DMZ, and one for the internal network.

In reality, it’s of course, never that simple. Let’s ignore all the complexities of real life physical networks for a moment and think about virtualization in the most simplistic case imaginable. We run public web servers, mail servers, databases, and application servers insides VMs on ESX servers. Obviously public web servers and mail must be in the DMZ, databases must not. So what do we do? One option I have seen is separate ESX servers. Not pretty, because you tie down VMs to a small set of hosts in the DMZ. And for the services console, we have set up a separate network anyway, because we do not want it in the DMZ. The second option is dedicated DMZ NICs. Somewhat better than option 1, it means that certain network interface cards are connected to the DMZ; we can share VM hosts between DMZ and internal guests and do the separation on the virtual network (on vSwitches or VLANs in the case of VMware ESX). Still fairly inflexible.

The case for the virtual alternative to option 1 and 2 is pretty straightforward. Going virtual means to combine vSwitches, VLANs and virtual firewalls to establish a virtual DMZ (VDMZ). Putting a VM in a VDMZ is a clear and simple concept; it means to put the VM on a VLAN that is connected to the DMZ and to shield it with a virtual firewall inside the ESX server.

Dedicating physical NICs for the DMZ is wasteful, both in terms of the cost of the NICs and the lost flexibility. Either I have to dedicate two NICs (assuming that I need redundancy) for the DMZ on every single server, or I have to limit the servers that can host DMZ VMs – which is awfully close to option 1.

Talking to many VMware users, there are still some concerns to overcome. Virtual DMZs are sometimes perceived to be less secure. I cannot share the sentiment having seen too many misconfigured physical firewalls and too many untraceable wires connecting segments that should not be connected, but in the end, the practices from physical networks will carry over. As mentioned in the beginning, real life physical networks consist of multiple DMZs, mostly separated by VLANs. So it’s certain that the much more virtualization minded VMware crowd will go for virtual DMZs, too.

Two Quick Takes on the Business Case for Virtualization

CFOs love virtualization! “Replace ten servers with one”, how easy can a business case be? CFOs have seen too many IT business cases that do not make any sense. They appreciate one that can be summarized in five words.

But virtualization is really not primarily about hardware cost. Looking at VMware’s standard business case, two things stand out. On the benefits side, it is the huge impact of improved availability. With virtualized servers, you do not have to bring down the application to replace a fan in the server. You move the application to another server (with VMotion, availability remains at 100%). Without virtualization you have to schedule downtime and find out who the users are in order to inform them. Big impact, but most would consider it “funny money”. Unlike the hard green dollars of a server that is purchased, the savings may never make it to the bottom line.

The second big impact factor is on the cost side. The biggest drive is not that pricey VMware licensing, but setup and management. It’s not only interesting because it’s a big dollar amount, but also because it has a large fixed cost component. Getting a virtualized environment up and running and operating it costs money. And running a pool of 10 ESX servers is not significantly cheaper than running a pool of 50.

Digging deeper into VMware’s standard business case is very instructive. I really like a sensitivity analysis. The point is to find out which of the dozens of parameters that go into the case have the biggest outcome regarding what I care about (typically the return on investment, ROI). So I individually change every input parameter by 10% and see how it impacts R0I. Some parameters are more “sensitive” than others; you guessed correctly, that’s why it’s called sensitivity analysis. But that is for the next post ..