Martin Casado, who helped launch the Software Defined Networking concept in the labs at Stanford, was recently elevated to the top business slot in VMware’s Networking and Security Business Unit, giving him the rare opportunity to see the technology through from the incubator to the data center. Network World Editor in Chief John Dix sat down with Casado for an update on the company and his thoughts on how the technology is maturing.
NW: Let's start with your new role. Why the management shift?
MC: I hired Steve (Mullaney) as CEO of Nicira two years after we started and he was with me for three years, then we came here. We were never a traditional business/technical mix. I did a lot of the business and design and technical and go-to-market work. He was more internal, I was more external, but there was no clear delineation between business and technical. He was here for two years and grew it to a $100 million run rate business, and I think he just wanted to reshape his career so he decided to take off. Since I’d already been deeply involved in the business for seven years now, I was a natural person to take over.
So now I’m more inbound than I’ve been before. Last year I did 320,000 miles in the air, and I’m delighted to say I haven’t traveled in the past month.
NW: So a $100m run rate, over how much time?
MC: The product has been in market just over nine months. I’ll give you a quick retrospective. Nicira was started in 2007 and it took us about three years to get a network virtualization product to market. The product came out in 2010, an incredibly immature product for an incredibly immature market. Over the next two years, we matured the product and we matured the market.
We were able to launch the company with five of the largest companies in the world: AT&T, NTT, Fidelity, eBay and Rackspace. By the time 2012 rolled around we had proven we could take on these large accounts, we’d proven we could get big deals. But we didn’t have VMware ESX support, so we we’re locked into a small portion of the market.
Later in 2012 we got acquired by VMware and it took us about a year and a quarter to create a VMware compatible version of that product. We announced the full network virtualization version of NSX nine months ago and since then we have a $100 million business. So the ramp has been extremely quick.
Honestly, if you ask me why I’m so excited about his role, it’s because I’ve seen every stage of this saga from the “That’s-a-stupid-idea” phase to where we are now, and now the critical challenge for changing the world and getting this technology into people’s hands is about scaling sales. It’s a business challenge now. The technology is proven, the architecture is largely proven, the use cases are understood and now it’s a question of, “How do you enable a sales force to sell this stuff to get to a billion-dollar business?”
[Soon after our talk, Casado fleshed out his executive ranks by hiring Guido Appenzeller, former co-founder and CTO of BigSwitch Networks, as his Chief Technology Strategy Officer, and Dominick Delfino, who was vice president of worldwide data center and virtualization systems engineering at Cisco, to head his worldwide Systems Engineering team.]
NW: Let’s talk about use cases a bit. It seems they have morphed with time.
MC: Yeah, they have. The original use case is still probably the dominant case, which is reducing provisioning times. I walk up to a customer and ask, “Does network provisioning get between you and getting something done, whether that’s innovation, onboarding a new employee or deploying an application or some business process?” If the answer is yes, there’s a discussion to have. If the answer is no, I leave and I go to the next customer. For the people for whom the answer is yes, I say, “Okay, I will take that provisioning time to zero.”
But the problem is that’s a nuanced operational savings type discussion, so the value isn’t immediately obvious and it’s more of a complex sales cycle. It’s a new kind of architecture that will impact processes so you need very sophisticated sales guys.
I would say that’s still about 50% of our sales. But the use case that’s really taken off is security. It’s just a much easier thing to enable someone to sell. The security pitch is as follows: As we consolidate more workloads in the data center, more and more traffic stays within the data center. We call this east-west traffic. So in an average data center about 80% of the traffic never leaves. It turns out, Mr. Customer, that 80% of your security spend is on the north-south border, so you’re spending 80% percent of your dollars on 20% of your traffic.
So if an attacker is able to get beyond that, let’s call it a Maginot Wall, they have unfettered access to all of your code and all of your data and you’ve got no security controls, or very few. What we can do is provide security controls within the data center to address that 80% of traffic. And, by the way, if you tried to do this with physical appliances, there’s so much traffic and so much bandwidth it would cost you hundreds of millions of dollars, and for us it’s fractions of pennies on the dollar.
I think if you do the numbers you would need something like five appliances per top-of-rack switch, and you have hundreds of top-of-rack switches. It’s just ridiculous. But if you distribute that functionality along the edge in the software it just becomes part of the operating model at the servers and you get all of the protection you want.
A more general purpose sales force can focus on this message. They walk in, they say, “Hey, if you try to solve this problem with appliances it would be $100 million. I’ll do it for you for $1 million.”
NW: Isn’t that what companies like Vyatta’s (now owned by Brocade) were promising with virtualized appliances?
MC: Yeah. But I don’t think the virtual appliance model actually works. We’re running within the ESX kernel in a separate trust domain. We’re already detecting every packet in software and can give you distributed functionality within that kernel. So it’s operating at line speed, the traffic isn’t going through another appliance, and you don’t have to manage independent appliances separately.
If you put in virtual appliances they may work, but you still have a bunch of independent appliances to manage. And I don’t think this is a problem you can solve by just adding some management layer on top. We offer a distributed service that you can think of as one big appliance, and it’s running in the kernel throughout.
NW: Are you talking about a full suite of security tools or just firewalls?
MC: Actually, distributing a service is very difficult, so we started with firewalling, and we’re going to be extending that through partner ecosystems and through our own products. The network firewall business is a $10 billion business. We can add a lot of value and do it in a way that doesn’t piss off the partner ecosystem, because they build appliances for North/South traffic and that’s not something we’ll ever do because those code bases have been around for 20 years. It’s not like we’re eroding an existing market. We’re going after a new one.
But getting back to use cases. The first reason people buy is operational speed. The second reason is security. The third reason is actually on cost, which for me is a sign of a maturing market. The reason it’s a sign of a maturing market is because in the early days customers have no idea how to evaluate the risk of a new technology. You’ve heard that startups never sell on price. It’s true because you go in with dials hanging out and sparks coming out of the box, and customers are like, “You could save me all the money you want, but I have no idea if this thing is going to work longterm. This is my business and my career at risk.”
So once you start seeing customers buy on price you know you’re entering a mature market. There’s trust in the solution. There’s trust in the product and also in the architectural approach. So we do see customers buying on cost, whether that’s CapEx, so they don’t have to upgrade switches as much, or it’s on OpEx, like they don’t need as many heads.
So those are the three primary value drivers.
NW: I want to go back to the difference between virtual appliances and being in the kernel. Can you elaborate on that.
MC: One very simple difference thing is, if you’re running something in the kernel it’s just faster. You don’t have the overhead of having a virtual appliance. Now depending on what you’re doing, that may or may not matter. Something like a firewall, that really matters because you touch every packet and you have to do this at 10 or more gigs. That’s purely a performance issue.
But there’s another issue, which is more nuanced and not well understood. If I take a physical appliance and turn it into a virtual appliance I haven’t distributed it. If I deploy 10 of these it’s just like deploying 10 physical appliances. There’s no difference. My background is distributive programming. That’s what I did before all this stuff. To distribute you have to rewrite the code so it’s distributed, so you can have one view and it looks like one thing, which means you have to share all sorts of state, you have to rewrite the control plane, and you have to rewrite the way the application works.
A lot of companies do this sleight of hand where they’ll take a physical appliance and move it to a virtual appliance and deploy them and then put a management layer on top and say, “Oh, look, it’s distributed.” But the reality is there’s no global view. There’s only a management side.
There are many problems for which appliances are just fine. For example, on the North/South border you might use virtual and physical appliances, but if you want to scale a service with a global view to handle all of the traffic within the data center, which is terabytes, you need to distribute it.
What we do is create this notion of a distributed firewall. This is a purely logical notion. It’s a fully stateful firewall that has one port per VM. So if you have 10,000 VMs you have 10,000 ports in a distributed firewall. And then you take this distributed firewall and chop it into little, little pieces and you run those pieces in the hypervisor kernel, so there’s a logical view of this 10,000 port firewall but the reality is only a little piece is running in the kernel.
So every packet still goes at wire speed, but we can also synchronize state if we need to because we’re running it as a distributed application. For example, if a VM moves, the state moves with it, or you can share that state and so forth. It’s actually written as a distributed application within the kernel. So every kernel has a little piece of this.
NW: Didn’t VMware have a distributed firewalling capability?
MC: They had the stateless firewall capability before.
NW: Did you leverage some of that?
MC: Absolutely. When we came in there was an enormous team here with this set of assets. We came in with another set. That’s why it took us a year and a half to integrate these things.
NW: I presume you add other security services in time?
MC: I think you can do load balancing, you could probably do WAN optimization, I think you can do it for IPS, but there are some tradeoffs we’re going to have to make. Web application firewalling, I’m not sure. It would be interesting to see.
But we can also start getting into things like vulnerability assessment. Vulnerability assessment is normally a box that sits on the network and scans things and it’s like, “Oh, my database says this is vulnerable based on the responses given me from the network.” Instead, we can actually run a little bit of code that looks directly into the applications, at the files in the memory so they can’t be tricked by, and then mitigate the problem so it can’t reach the network. Which is exciting because, wow, now we have an entirely new approach to address security concerns.
NW: How much of this security work will you do internally versus with partners?
MC: Ours is very much an ecosystem approach. We’re really good at building distributed services, but I’m not an expert in IDS, I’m not an expert in virus detection. So we want to provide a platform that will provide context that others can’t get, and even provide native distribution capabilities, but otherwise it’s very much an ecosystem play.
NW: But the firewall was home built?
MC: The firewall was home built. But again, it’s fully distributed. We’re going to have to lead with a few core products that demonstrate this capability in order to drive the ecosystem because nobody wants to invest money speculatively if they’re in a growing business.
Palo Alto Networks is a good example. They provide a next-generation firewall and are a huge partner. They run a virtual appliance with integration in the kernel and we handle the operational side of distribution and provide additional context by allowing them to peer into the hypervisor. So there’s quid pro quo here. For us, our platform gets more attractive and we get to sell a layer that adds value, and for them, they get an insertion vehicle and the insertion vehicle to a large market.
NW: They’re not threatened by your own firewall?