Posted by: Tom Nolle
Amazon, Amazon EC2, cloud provider, cloud revenue, EC2, Juniper, Juniper Networks, OpenFlow, QFabric, quarterly reports
Amazon’s third quarter earnings disappointed almost everyone, and the fact that there were so many different views about just what was disappointing makes it all the more challenging to analyze. Many said the profit picture was the problem; Amazon’s margins have been thin historically, and the Street wanted proof that they’d fatten up. They didn’t get it. Others in the Street said that their revenue was light; they could have forgiven smaller margins if revenues were up. Probably the combination was the real problem: Weak revenue guidance for the holidays combined with a clear indication that build-out in EC2 and the cost of the Kindle Fire would be a problem for the bottom line.
Underneath this is the fact that Amazon has been a challenge for the Street. They’re the drop-dead winner of the online retail game. They’re the largest single provider of cloud computing today. They now have what is arguably the second-best tablet and the Android leader. But they’ve never really generated the profit that would normally be demanded of any company, and in terms of stock performance they’ve outrun even Apple this year. The Street clearly thinks they have momentum (which is key in the way traders make decisions) and yet…
The big question here may be the cloud. Amazon’s cloud lead, as I’ve noted before, is somewhat illusory.
Juniper Networks announced that their OpenFlow implementation will be available in source-code form to Junos SDK developers. Juniper, like some other big router/switch vendors, has supported OpenFlow at least at the demonstration level, though neither Juniper nor its peers have been in a rush to productize it. That’s in part due to the fact that it’s open-source, I think. What Juniper has done here is to make their source code available to developers who could use it to extend basic router/switch functionality and create OpenFlow services/networks alongside (more properly, within) existing router/switch networks.
Juniper’s approach is interesting because it leverages something they’ve always been able to do. Their router/switch code has always made the forwarding table addressable to applications, and in fact they’ve had partners extend basic router functionality using that capability (in the video space, for example). What they’ve done is to use that capability to implement the OpenSwitch part of the picture in their Route Engine, and then link that implementation (via the OpenFlow protocol) to a controller application that runs in Junos Space.
To me, the big question is where Juniper will go with this. I believe that OpenFlow is valuable primarily as a “cloud” or “interior” technology, meaning one that is used to manage traffic inside a service black box. Net neutrality issues will likely deter network operators from broadly using the protocol because those issues act against grades of service on the Internet. Inside a cloud or content delivery network (CDN), though, you can do what you like. Given that Juniper has products like QFabric and the PTX that would benefit from being integrated into a higher-level vision of cloud data centers and service black boxes, I’d like to see them push their OpenFlow approach explicitly in these areas. Since this release is focused on partner relationships, they may be letting partners do that, which might not be optimal for Juniper’s own interests.