FireHost is out shopping for software-defined networking (SDN), and it's finding the early options lacking.

The cloud hosting provider does have some special requirements. FireHost prides itself on providing a secure multitenant cloud — not just "secure" like everybody else says, but really, really secure. That was the goal when the company started in 2009, and the obsession has attracted clients including infamous hacker host Kevin Mitnick — and yes, people try to hack his site. All the time.

But as I learned from VP of Technology Todd Gleason (pictured at left, above) and Jason Rieger, principal networking and security architect (pictured at right), some open questions also loom around fundamental issues such as scale. They're also leery of the potential for vendor lock-in.

In one conversation at FireHost's Dallas headquarters and another over the phone, Gleason and Rieger shared what it's like being on the shopping end of the SDN hype machine. They like a lot of what they've seen from VMware's NSX and Cisco's Application-Centric Infrastructure. But for them, picking an SDN architecture might still come down to a leap of faith.

When it comes to security, you don't seem happy with the SDN options so far. Why is that?

Rieger: It's all about the feature set. From a FireHost perspective, it needs to be a comprehensive focus. We're a security infrastructure-as-a-service provider; we have to go all the way up to Layer 7.

Gleason: We have to live as close to the kernel as we can, as close to the ingress and egress traffic. There aren't a lot of baked-in solutions that do that. We end up having to piecemeal things together.

Rieger: I'm not saying there aren't products out there. The feature set doesn't solve all of the pain points that we happen to be faced with. And I still think there are gaps, major gaps associated with scale. Cisco may have been talking about massive scale — 64,000 tenants supported by a single APIC controller — and on the VMware side, scaling the tenant domain horizontally with VXLANs up to 16 million customer segments, but in reality, I don't think that's necessarily feasible.

Gleason: If you just took NSX and ACI, I still feel that they're solving a problem very well for maybe the enterprise or single tenant, a very static environment, but when you get into our world, the scalability isn't there.

Where is the scalability falling short?

Rieger: What I'm seeing is that not a lot of solutions offer federated control-plane mechanisms, at least not with initial releases of their software. Some have it roadmapped, but they couldn't tell me when. It sounded like they were still figuring that out and gauging interest.

Also, with VMware, there's a 1-1 correspondence with a vCenter. That just doesn't scale very well for us.

Gleason: There's ACI, yes, but now you're dealing with Cisco's networking equipment, and you're beholden to them and the pace they're bringing out the equipment — which could be good, could be bad. Utopia would be: commodity hardware, and give us the scale in a multitenant direction.

Rieger: There's also performance. If you're not in the kernel, there's a chance you're not going to perform as well. In-the-kernel has a risk/reward proposition of its own; we've had some conversations about that internally.

Which products count as being "in the kernel?"

Rieger: You have two classes depending on what aspect of SDN or network virtualization you're talking about. You're getting into solutions that provide kernel-integrated functionality or non-kernel-related functionality. Cisco ACI and VMware NSX would be examples of kernel-oriented functionality. Other solutions like Embrane, like Midokura, Nuage, and Juniper — all of those could be classified as not being in the hypervisor kernel itself as far as their switching, firewall, and Layer 4-7 capabilities.

When it comes to bringing Layer 4-7 into SDN, what's important to you?

Rieger: It's just a question of the density: How many are you going to need at what resource levels in your environment? That's not such a hard problem to solve, to find a place where you're going to host all those service VMs. For me, it's more about how it's going to be managed — and are you going to have true, robust API capabilities to interact with those services?

You've got one vendor saying they've got a full REST API to interact with Layer 4-7 services, but what I'm seeing is, a lot of those APIs don't let you control everything. There's a major gap. It's really easy on a data sheet to provide the bullet point that says "full REST API," but when you actually go through a full PoC [proof-of-concept] with those vendors and you actually audit all the methods available to you for modification or management of the service, you'll find some are pretty good and some are lacking in what they're capable of letting you control.

As a consumer, it can be frustrating, because I get 50 or 70 percent into a product, and I get this roadblock. It causes me to wait longer to give feedback to the vendor about what we'd like to see or what's missing.

So, what's your impression of Cisco's ACI?

Gleason [noting that it's Rieger who's really done the deep dive on ACI]: It seems better at first glance than NSX just from a technical risk standpoint, because we can leverage their switch without kernel modules. But the risk is vendor lock-in.

Rieger: Regarding ACI, it actually is in the kernel if you choose to utilize it with their application virtual switch. It's essentially an evolution of the Nexus 1000v, but when I peeled back the layers of the onion in my deep-dive demo, what I found was — personally, I like Cisco ACI's approach to containerize services into these endpoint groups that they're speaking of. And these policy contracts, that's great.

But getting into detail, I started to notice some gaps from a feature perspective. The Application Virtual Switch [AVS] doesn't support Layer 3 switching in that module, so it's going to punt all of its traffic to the Cisco ACI leaf switch. And as a result, another thing I found out is that the ACI only has support for stateless policy enforcement. It's roadmapped to be stateful, but they couldn't provide me an ETA on that. It could be a year out, could be less. Auditors don't like to hear the term "stateless" so much; they want stateful firewalling within a tenant and in the isolation between tenants. Cisco provides isolation, but if they're based in the same network group, they're going to have carte blanche network access to each other; they can't be firewalled. That's a security demerit.

They've got some great things, though. They've taken Embrane into their world now, and Citrix, F5.  ACI federation is roadmapped; with VMware, it's more of an idea. All of these address security and scalability in our world here.

Just going back to a high level — being centric around the application, using endpoint groups and policy contracts to dictate policy flow is a good idea in theory. It's just that you're going to have to peel back those layers. The last thing any of us want to do as consumers is take a step back after we've torn out our hardware and put in Cisco ACI gear and controllers. You don't want to feel like: "I've spent all of this money and all of this time, and do I feel like I'm in any way ahead of where I started?"

That's what I stress over. This is new. Being a little bit overzealous could prove to be a bad decision.

Cisco pits itself against VMware's NSX, and we in the press tend to do it, too, even with so many other contenders on the market. Is that the right focus?

Rieger: We're pitting the two against each other as well. Cisco ACI addresses a couple of pain points I have with NSX. VMware has more features than Cisco is going to deliver this month or next month. In a way, I'm conflicted.

One thing: VMware NSX is extremely easy to install and spin up, from a PoC perspective. I wouldn't be able to deal with a Cisco PoC for a few months, because I've got to deal with hardware. Cisco has this visibility that you're gaining, but quite honestly, they couldn't show the value of that in a demo — and their own demo was just a simulation; they didn't even have hardware in their own lab yet. [That situation has presumably changed by now, as Cisco's APIC is due to ship this summer.]

At the end of the day, ACI and NSX are the two that I'm vetting. NSX probably has a slight edge for me, but you never know. Cisco ACI might end up winning in the longer term.