IBM reversed course on networking in 2010 when it acquired Blade Network Technologies, one of its key network suppliers. Network World Editor in Chief John Dix and Managing Editor Jim Duffy recently caught up with Vikram Mehta, founder of BNT and now vice president of IBM System Networking, for an update on IBM’s network visions going forward.
IBM divested its network operations more than decade ago, so why did it decide it had to get back into the business?
IBM divested its network business in 1999 and acquired BNT in 2010, so interesting question. As enterprises have increased their reliance on IT to run their business the amount of infrastructure has gone through the roof. And what customers have come to realize is that, given the scale and the pace at which they need to deploy infrastructure, the old model of build your own using best of breed servers, best of breed storage and best of breed networking, just became untenable.
They said look, our core business is insurance or banking or running an airline or what have you, we need credible technology suppliers to put the entire solution together. IBM has a tremendous brand in servers, a tremendous brand in storage, but increasingly customers look at these systems as a combination of hardware, software and services and IBM was missing one key component which was networking so it was incredibly important for IBM to have a strong point of view on that.
Now you might say hey, IBM Global Technology Services sells a lot of Cisco and a lot of Brocade and other stuff, why not just carry on with that? Well, as things like virtualization take hold and the need to scale out the infrastructure grows, the fabric that connects servers to servers and servers to storage is a strategic point of differentiation and for IBM to just merely resell other people’s technology and not be able to innovate in that area would have been an issue. It was incredibly important for IBM to own some strategic control point within the networking piece.
Now our strategy from a networking perspective is different than some of the other players. We’re not doing backhaul networking. We’re not doing the LAN. We’re not doing wireless networking. We are really building differentiated IP when it comes to connecting servers to other servers, servers to print, and storage to other storage, so that’s where our pieces are concentrated. And we still maintain good partnerships with the likes of Brocade, Cisco and Juniper for all those network things we don’t build.
ANALYSIS: Implications of the IBM/Blade deal to Cisco
Frankly it seems like a clear endorsement of what Cisco has been saying all along with its Unified Computing System, that the fabric is core to these new bladed architectures. You’re agreeing with that then?
What we are endorsing are two things. First, full compliance to standards and interoperability without compromise. And second, avoiding rip and replace. Now, when we look at several other vendor offerings in the market, they fall short on both of these measures, and we think this is bad for customers.
I have never heard a customer say come and put your hands around my throat and choke me with proprietary technology. So one of the things we’re professing as part of this integrated systems approach is, first and foremost, no proprietary stuff. We’re going to rely very heavily on standards. And secondly we’re going to be really respectful and mindful of customers existing IT investments and try to embrace what they have versus the Cisco approach of rip and replace.
Same thing say with HP’s matrix issues built around Virtual Connect. Once you buy into Virtual Connect, the only type of servers you can buy are HP Blade Servers. Blades are good for some things and not good for other things. We take a very different approach in how we involve some of these things and I would say are sort of our key differentiators.
Another example where IBM differs is in network virtualization. We’re not only hypervisor agnostic, we take a standards-based approach to our offerings. This includes incorporating Edge Virtual Bridging, the IEEE 802.1Qbg standard with our Virtual Machine-aware, switch-resident VMready software, which is provided at no extra charge on our high performance 10G and 40GbE top-of-rack RackSwitch products. This is very different than those vendors who are promoting a variant on the standard.
The irony of this is pretty rich coming from IBM.
The masters of proprietary technology. Absolutely. I spent a dozen years at HP and used to joke about how IBM systems were open so long as every system in the network was provided by IBM. And I don’t mean this in a cocky manner, but having invented this proprietary lock in thing decades ago, we understand the perils of it. So call it the person that has been to the dark side and now is really making a God’s honest effort to embrace open technology and solve customers’ problems without locking them into proprietary technology.
Can customers of IBM’s RackSwitch and BladeCenter switches use any blade server or rack mount server they want?
Yes. As a matter of fact we have customers around the world buying top-of-rack switches from IBM System Networking, previously BNT, and deploying them with Dell and HP and even Cisco servers.
How closely do you work with IBM’s server and storage groups?
Very, very closely. Storage and Networking are two separate businesses that are part of the Systems and Technology Group. And BNT was selling product to IBM’s competitors, NEC and HP specifically, and we still maintain a healthy OEM business with them.
Let’s turn to the topic of the day, data center network fabrics. What’s IBM’s take?
I think this is another point of differentiation for us because when companies like Cisco or Juniper are talking about fabric they’re coming at it from a pure networking-only perspective. Our perspective is a little bit different in that the fabric is the entire infrastructure. There are compute elements in that fabric, storage elements in that fabric, function-specific appliance elements in that fabric.
If you look at IBM’s Systems and Technology Group, with its various server types, with it’s storage offerings and with is connectivity offerings, we try and address the fabric very holistically and I think that is a key differentiator.
The second key differentiator is where you put the intelligence. Juniper puts all the intelligence out at the edge in the QFabric. Cisco’s strategy is the exact opposite, with all the intelligence in the core. Our approach is you put the intelligence in the entire IT infrastructure, the entire IT fabric is the function of the type of applications that you are running.
Some applications require a lot of intelligence at the edge if they are trying to stream content or pull down content, so you need a lot of intelligence at the edge. Then you’ve got centralized application such as CRM that don’t necessarily require a lot of intelligence out at the edge and so can reside back in the core. We’re not trying to push one architecture down the customer’s throat. We architect our solutions for what is best for the customer’s application.
A third key differentiator is our fabric storage is, again, not proprietary. What if you have a 3Com switch or a Brocade switch, how do you move virtual machines from Point A to Point B? Cisco can’t do that. Juniper can’t do that. With our approach if a customer has IBM System Networking top-of-racks and the core could be Cisco, 3Com, whatever, and you can move virtual machines from one rack to the other.
We’re not just saying that the network is a fabric, the entire IT infrastructure is a fabric.
FABRIC WARS: Cisco vs. Brocade vs. Juniper
All this discussion about fabric gets a little cloudy given everyone is defining it differently, but one thing Juniper is pretty vocal about is the idea that we have to minimize latency by minimizing the number of hops between two resources. Do you see the same need?
We agree with that, but what we don’t agree with is where people make the leap of faith in saying the only way you can minimize the number of hops is by buying everything from one vendor.
Latency is a big deal for applications like trading, for people in content distribution, the Netflixes of the world, etc., but it’s not a requirement for many other customers. For example, for end-of-day reconciliation on trades, latency is not important. Absolute throughput and performance is incredibly important.
How’s your relationship with Juniper since IBM acquired Blade? Are you still supplying top-of-racks switches to Juniper?
We certainly are. As a matter of fact, when it comes to low-latency solutions, their low-latency solution is sourced from IBM.
Is IBM still endorsing Juniper’s QFabric approach?
They are a strategic partner for IBM. There are some customers that have expressed an interest in building an integrated IT infrastructure server/storage/networking with a preference for QFabric and IBM certainly supports that. It’s hard for a company the size of IBM to have a purest model where this guy is a pure competitor and that guy is a pure partner. Look at System Networking’s relationship with HP or NEC. We compete on the service side yet we supply networking components for the HP BladeSystem or the NEC SigmaBlade.
Is your business through the Juniper channel growing?
You are referring here to the EX2500, our top-of-rack business, yes. We’ve exceeded our business case objectives in 2011 with not only that piece of the business, but just overall.
All the theory behind why this acquisition made sense, if we became part of IBM we would be able to benefit from IBM’s scale and reach, has certainly proved itself out. We went from a tiny company to over 10 million ports in production and earned ourselves a little spot on the world map.
Being a public company we don’t break out numbers, but I will tell you the traditional core metrics used to measure success, whether it is top line growth, profitability, market share growth, customer satisfaction, etc., we have not only met, but actually exceeded our goals for every one.
A hundred million dollar company coming into a hundred billion dollar company, there was some fear and trepidation about getting stomped by the elephant, but thanks to a lot of planning ahead of the acquisition on how to make this thing work and good execution, I think this has been a very good result for IBM, its stakeholders, customers and all the people at BNT that came into IBM.
Cisco recently crossed the billion dollar mark with UCS and says it now has 10,000 UCS customers; what would you attribute that success to if IBM and HP and everyone else are meeting the needs of the market? [Also see: “Cisco boosted profit, sales in Q2 while cutting costs”]
One of the things Cisco has done very well is articulate the benefits of an integrated system and made the sourcing of this integrated system incredibly simple. Where they’ve had the biggest success is in the mid-market. So we track and learn from that. We’re making our messages a lot simpler, our value propositions more compelling, and making it simpler for our customers to source these solutions from IBM.
Does IBM support any specific standards for flattening network architectures in the data center, like TRILL or Shortest Path Bridging?
We are very much behind TRILL.
So your strategic technology for flattening data center architectures is TRILL or TRILL-based?
Absolutely, because we believe that approach will enable customers to leverage existing infrastructure which may or may not be from IBM, and that only through the adoption of standards can you truly lower cost.
We haven’t talked much about HP in all this. How do you guys stack up against them?
They are a customer. We supply switches for the HP Blade System. But I think the 3Com integration has been a real challenge. I don’t think it is one HP networking. You have a big Chinese wall between the operations and we and some other players in the market have benefited from that. But we do run into them in certain accounts and they’re a formidable competitor. I have a tremendous amount of respect for HP. I worked there for 12 years. We take them darn seriously.
What are your thoughts on the role of virtual switches?
It comes back to the application. If an application can benefit from virtual server technology, then it might benefit from virtual network technology. If the application itself sees no benefit from virtualization, then the same goes for the network.
Is IBM’s virtual switching technology internally developed?
IBM invented virtual machines on the mainframe, and we’ve got virtual server technology on our Power Systems called power KVM. We also partner with VMware for their piece, and Citrix for Zen and Microsoft for Hyper-V.
VIRTUALIZATION WARS: VMware vs. Hyper-V vs. XenServer vs. KVM
As a matter of fact, IBM System Networking’s virtualization technology called VMready, which customers compare to Cisco’s Nexus 1000v, is much more widely deployed than Cisco’s tech. One of the unique propositions of that technology is we can work with any of those hypervisors and be a version agnostic.
Jumping back to standards, what’s IBM’s position on FCoE?
VM: Truth be told, I think you’ll find different answers at IBM depending on who you talk to. But let me give you a customer perspective and tell you what we’re doing from a product perspective. There are two parts to an FCoE solution. There is a lossless Ethernet transport and there is supporting the Fibre Channel protocols on top of that. Those Fibre Channel protocols could either be basic NPIV or it could be full director class switching. We have been supporting lossless Ethernet transport ever since we got into the top-of-rack business, which was late 2008. Starting in the first half of 2012 we will start to enable customers of our lossless Ethernet top-of-rack switches to break out Fibre Channel and connect to their favorite Brocade or Cisco Fibre Channel.
On any port?
On a certain number of pre-designated ports, so say a dozen or so ports on a 64-port box. If you support multiple protocols on each port you burden every port with cost and higher latency. Customers don’t want to pay for FCoE functionality on every port if they are not going to use it.
Now in terms of customer demand, so far I think FCoE is a cool technology in search of a problem. I haven’t had one customer say, “Let me show you my 20-petabyte FCoE implementation.” I mean, Fibre Channel technology is good, and Ethernet technology is good, so I think where people have converged things is on the network adapters.
Look at a typical rack. You’ve got 30 or 40 servers in there and a couple of switches and 30-40 connect adapters on two Fibre Channel HBAs. Consolidating those into one shared adapter that is multi-personality can save people a lot of money. A lot of that has happened.
But the reality today is you’ll be better off economically if you buy a separate Ethernet switch and a separate Fibre Channel switch, so I’m personally skeptical [of the integrated approach], which is why we’re taking a measured approach in saying look, everybody can benefit from lossless Ethernet. Once you put a lossless Ethernet fabric in place, it doesn’t matter what storage protocol you’re running on top of that, iSCSI, NAS or Fibre Channel. It will benefit all, so we did that piece.
Now, in a very measured way, we’re saying, now that you’ve brought Ethernet all the way to top-of-rack, and you need some connectivity to your legacy Brocade or SAN or Cisco MDS, or whatever, let’s provide some physical connectivity to a dozen or so ports. That’s better than saying, “Oh Mr. Customer, I’ve got this wiz bang technology and any port can be Fibre Channel, any port can be Ethernet or whatever, but oh by the way, in order to benefit from this you have to rip and replace everything you have.”
What’s you’re higher growth product line, the rack switches or the Blade Center switches?
When we started off in 2006, as the name of the company suggested, we were providing networking for blade server systems. In 2008 we expanded into top-of-rack and went from blade being 100% of our business to top-of-rack being 50% of our business, so it’s a very, very high growth area for us.
Maybe we can end here with your thoughts about OpenFlow. Where do you see that going?
I think one of the proof points around how serious IBM is about open systems is our support for OpenFlow. We have partnered with NEC to work on OpenFlow, and NEC was a founding sponsor of the OpenFlow lab at Stanford University. We’ve since expanded that partnership and actually have several commercial successes in the OpenFlow space.
MORE: IBM, NEC team on OpenFlow
Now here’s the stuff that really scares the bejesus out of the likes of Cisco and Juniper: a technology like OpenFlow taking off and breaking down the proprietary paradigm. IBM is as serious about OpenFlow as it was about Linux, and I think our track record with Linux speaks for itself. You can expect us to do the same thing when it comes to OpenFlow networking.
To what end? What are the expected benefits?
Similar to the benefits people associate with Linux. You get a community of people developing the technology, versus just relying on the rate of innovation from a particular vendor. And I think OpenFlow will dramatically reduce the cost of networking products. I mean, companies today are still charging over $1,000 per 10G port at list prices. We think it should be south of $100, and in the next couple of years, south of $50.
I think things like OpenFlow will force some of that to happen, much like Linux did in the operating system world. Look at the impact Linux had on the whole Microsoft server movement and the domination there of a few players. I think OpenFlow holds that same promise, will really challenge those with 60%, 70% market share in the networking world. If you think TRILL has some of these vendors running scared, I think OpenFlow is a bigger challenge.
