Amazon’s quarter 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. Some 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 (“Mo”, 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. We are a quarter of one percent into the cloud market at this point, and the horse that’s ahead one step out of the starting gate doesn’t gain much from the lead in statistical/historical terms. The real challenge is that IaaS is a pure cost-substitution play, which means that it is always going to be under the worst price pressure, always generate the lowest profit. The telcos, whose internal rate of return is low, have a natural advantage in this sort of service, and they’re coming into the market now. We are going to see more pressure on EC2. Tablets are consumer products, whose margins NEVER grow over time, and so there’s pressure there. That’s the issue for investors, and for us in the market. Consumerism is cheapism, not profit. IaaS is cheapism, not profit. Amazon, like Apple, has to look higher in the clouds, and deeper into cloud/tablet relationship, if it wants to keep flying.
Juniper 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 none 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. Neutrality issues will likely deter operators from broadly using the protocol because those issues act against grades of service on the Internet. Inside a cloud or 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.
