Posted by: Tom Nolle
Cloud computing, cloud security, Cloud Services, Juniper, QFabric, Virtualization
Juniper provided analysts, including me, with some more color on their QFabric security integration. There are two dimensions to this. First it illustrates in some detail what a “service” is in QFabric terms, and second it illustrates the exploding complexity of security in a virtualization and cloud environment. The combination of these things positions QFabric much more directly as an element in a cloud computing strategy, which is how I’ve viewed it from the first. Since I think anything truly cloud-enabling is important, we’ll look at this a bit here.
In the QFabric pitch, Juniper’s CTO made a point of saying that Juniper QFabric offered both virtual networks and “services” as its properties. Security is considered a service, and the way a service is created is by routing a flow through a service “engine”. Because the flow’s route explicitly intersects with a security process, the flow route is secure without external intervention. You can see that this sort of engine/service thing could easily be applied to other things like application acceleration, although Juniper hasn’t said anything about what might be a QFabric service beyond security. Interestingly, by making security appliances into QFabric service engines, you effectively virtualize security and increase the number of machines you can secure with a given device. It’s like the old test of a good compiler; can it compile itself? An offering to secure virtualized resources has to be a virtualized resource.
On the complexity-management side, the problem Juniper is solving here is the fact that it’s impossible to build a static-appliance security framework around a virtual or cloud data center. Even if application-to-server assignment isn’t totally dynamic, as it would be in a cloud computing application, it’s still easy to move virtual machines around with management commands. In fact, the VM tool players are falling all over themselves to make the process of moving VMs easy, which only makes security hard. All of those problems are multiplied in the cloud, where resource assignment is dynamic by definition.
Juniper’s idea is to combine in-fabric security and in-VM security (through its Altor acquisition) to build a truly secure virtual data center. By adding support for cloud “director” functionality, Juniper will presumably then extend this to the more dynamic resource assignment of the cloud. As it is, VMs carry their security credentials as metadata, so cloud partners that have Juniper products on their end will be able to interpret and apply the policies even in a public cloud.
We’re starting to see a glimmer of what security would look like in a cloud-enabled future, or at least how Juniper sees it. The question now is whether competitors will present their own holistic model of cloud/virtual security or whether they’ll simply try to counterpunch pieces of this.
A good industry debate on the issues here would be helpful for everyone, but especially to service providers that need a secure model of cloud services if they ever hope to sell them to anyone but startups and hobbyists. As I’ll get to in a minute, clouds are really critical for operators’ future monetization plans, which makes them critical for network spending and for the future of broadband services.
It’s good to see that Juniper is building a cloud story here in the security space, and in fact, its security story is pretty holistic and strong in a cloud perspective. That particular aspect of the announcement would have been stronger had the QFabric/PTX symbiosis been played up and had both that and security had explicit links to Junos Space. Yes, it’s hard to make a big launch work, but rather than try to do a big launch made up of five or 10 deeply technical pieces (as Juniper did a couple years ago), it could do a strategy launch and then instantiate it. Detailed announcements invite defeat in detail, and the cloud is no place to take that risk.