Google, Juniper, and the Cloud

We’ve got a number of interesting points to end our week, and monetization issues are at the heart of them.  Let’s get moving!

Google is taking some steps that show how hard it is to be a portal player.  First, it’s letting users block sites in search results, and second it’s classifying gmail to facilitate users’ discarding of stuff they think is unimportant at best or junk at worst.  Anything that hurts ad revenues anywhere could be argued to be counter to Google’s interest, but the problem is that undisciplined exploitation of any resource tends to discourage users.  Search is hurt by having junk results, with junk being defined as either something that games SEO for unwarranted placement (which Google has been working to eliminate) or as simply something the user doesn’t like.

In the best of all possible words, advertising would go only to people who might be receptive, but since it’s impossible to know who exactly might be, the tried-and-true approach has been saturation bombing.  That the bomb-ees are getting tired of the attention is clear, and you can see a similar trend in the TV commercials area.  In my surveys, users cite disgust with commercials nearly as often as the cite disgust with programming as reasons to cut the cord.

The underlying problem here is that we have too many people looking at ad sponsorship to drive their business models and not much actual ad revenue to do the sponsoring with.  As media conduits try to raise revenues by reducing ad prices to attract new players (often by cutting the per-commercial time) they have to spawn more ads, and their revenue growth goals create the same pressure.  So we have people who want their lives ad-sponsored but don’t want to see the ads that are paying for the stuff.  Clearly this isn’t going to work for long.

On the equipment side, Juniper provided analysts, including me, with some more color on their QFabric security integration.  There are two dimensions to this; first that it illustrates in some detail what a “service” is in QFabric terms, and second that 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 make a point to say that QFabric offered both virtual networks and “services” as its properties.  Security was such 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 stuff like application acceleration, though Juniper hasn’t said anything about what might be a service of QFabric 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 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 who 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 who 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 their 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 very 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 ten deeply technical pieces (as they did a couple years ago) they 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.

Mobility is an increasing driver for change, and some Google predictions show how profound the changes might be.  Google asserts that as many as half of all retail transactions and two-thirds of retail purchase dollars will be initiated on mobile devices.  A big chunk of this is the presumed shift from credit cards to near-field communications and phones as credit devices, a Google push, and frankly I doubt the number no matter how they arrive at it.  Still, it does appear likely that mobile devices, ubiquitous broadband, and new consumer behavior patterns will create new market opportunities.  That brings us back to the question of broadband policy and monetization.  In the best of all possible worlds, the big ISPs would be offering their own higher-layer services and would thus be encouraged to look at the access connection as a delivery asset they can exploit.  As it is, they see it as a delivery asset their competitors alone can exploit.  Mobile services is where the change in that myopic view will have to arise, because that’s the focus of investment and change right now.

The cloud is the operator conception of its future IT infrastructure, the basis for content delivery and feature hosting.  I’m so interested in the cloud because I believe that effective operator exploitation of cloud potential is the only way to avoid commoditized broadband and anemic broadband investment.


Leave a Reply