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. 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 and 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 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.]]>
Good question, and it’s not easy to answer it from the Juniper’s announcement, but I’d say that the differentiator is the chipset. Junos Express appears to be the same basic chip used in the recently announced QFabric data center switch. Thus, you could say that the PTX is a based on a low-latency MPLS switching architecture that’s more distributed than QFabric. Given what we perceive as a chipset link between the products, I’m creating a term to describe this: Express Domain. An “Express Domain” is a network domain that’s built using devices based on the Express chipset. A PTX network is an Express Domain in the WAN and QFabric is an Express Domain within a data center.
If you look at the PTX that way, then what Juniper is doing is creating an Express Domain linked by DWDM and running likely (at least initially) in parallel with other lambdas that still carry legacy TDM traffic. It becomes less about having an optical strategy than it is about creating a WAN-scale fabric with many of the deterministic features of QFabric. Over time, operators would find their TDM evolving away and would gradually migrate the residual to TDM-over-packet form, which would then make the core entirely an Express Domain. The migration would be facilitated by the fact that the latency within an Express Domain is lower (because packet handling can be deterministic, as it is with QFabric) and because the lower level of jitter would mean it’s easier to make TDM-over-packet technology work. Overall performance of the core would also improve. In short, we’d have something really good for none of the reasons that have been covered so far in the media.
This (if my interpretation is right) is a smart play for Juniper. It creates an MPLS-based virtual domain that can be mapped to anything from a global core to a data center. Recall that I noted in the QFabric announcement that Juniper had indicated that QFabrics could be interconnected via IP/MPLS. Clearly they could be connected with PTXs, and that would create a supercloud and not just a supercore.
What would make it truly revolutionary, of course, would be detailed articulation of cloud-hosting capability. I think that capability exists, but it’s not showing up at the right level of detail in the positioning so far. In any event, if you add PTX to QFabric in just the right way, you have a cloud—probably the best cloud you can build in today’s market.
If Juniper exploits the Express Domain concept, then the PTX and QFabric combine to create something that’s top-line valuable to the service providers. Yes, there are benefits to convergence on packet optical core networks, but those benefits are based on cost alone, and cost management isn’t the major focus of operators right now—monetization is. You can’t drive down transport cost per bit enough for it to be a compelling benefit in overall service pricing, or enough to make low-level services like broadband Internet profitable enough.
Furthermore, achieving significant capex savings for the operator means achieving fewer total sales for the vendor. That’s the old “cost-management-vanishes-to-a-point” story. But you can do stuff at the service layer that was never possible before, drive up the top line, and sell more gear overall rather than less. Or so I think. We’ll be asking for clarification on these points, and in our March Netwatcher we’ll report on what we find.]]>
The newest problem facing both enterprises and operators these days comes from the fact that a single user is extended across multiple appliances and increasingly uses those appliances as facets of a virtual personality. This is true with social-driven consumers, as well as increasingly with productivity-driven enterprises. Point-solution security not only doesn’t secure the range of devices, it forces those who want security to integrate disparate policies and processes to create a secure framework. One miss destroys collective security and also risks cross-contamination of the other channels to the user.
I like the Juniper approach here, not because of its capabilities or because of Juniper’s need to validate the research it sponsored. We have security on devices, and we’ll have it on all of them eventually, and the problems of mobile device security are hardly a surprise, even without new research. What I like is that Junos Pulse extends “the network” to the device itself and makes it an agent of network policy and services. It seems the only long-term solution to both security issues and creating service value-add. Plus the multiple device faces of the user are going to pop up in a lot of future service missions, and they will be problematic to those without a device-integrated approach.
It’s hard to pull this story out of the Juniper talk, in part because it’s focused so much on security needs and the point-solution remedy, but the real story is the ecosystem.]]>
It would also help in the enterprise to support hosted applications that are tightly coupled with the network, including unified communications (UC). One impact of this step would be to formalize Cisco’s entry into the IT space, something that’s been inevitable anyway as Cisco works to rise up the value chain.
In all, we believe this rumor is absolutely true and a good thing for Cisco. It will put considerable pressure on Cisco’s competitors, especially Alcatel-Lucent and Juniper, to flesh out their own strategies. Alcatel-Lucent has already announced a strategic shift to the “online ecosystem” that links developers and telcos, but Juniper has not articulated a strategy here yet, though the company has spoken at conferences on the topic of open networks.]]>
We believe the step is a kiss blown at Wall Street, something Cisco knows is likely not to be the right answer but that may be necessary to support the stock price in the near term. Even in that light, we believe the move to be unwise because it tars Cisco with the brush of a firm experiencing problems in the downturn, something competitors might play on directly but that will indirectly challenge the most basic value proposition Cisco presents to buyers—stability.]]>
This is the second of Juniper’s announcements that have created a “higher-than-the-network” layer of technology, the first being the company’s support of hosted control plane software for JUNOS. When you add this to the recent management changes at Juniper, it begins to look as though the company may be taking a turn more toward software and “transformation” versus routers and “convergence”.]]>
We believe this is a good thing. Johnson represents a vision of where Juniper must go, which is beyond being a box vendor or its products will commoditize and its stock stagnate or fall. Kriens understands where Juniper is now, and how near-term modifications can be made to lead to the ultimate direction Johnson represents. Both the goal and the route are equally critical for Juniper, and we hope that the two can be harmonized by Johnson and Kriens cooperation and effective collaboration.
We have heard that this change has been in the works for some time and was at least in part responsible for the other recent executive changes at Juniper. For Microsoft, which will be reorganizing its Platforms and Services area, the departure of Johnson seems to signal a bitter aftermath of the failed Yahoo deal and an internal conviction that the deal cannot now be done, though some inside Microsoft tell us that’s not necessarily the case.
At Juniper, the move is not completely a surprise. Kriens was one of the few executives to start a tech company and remain CEO through its IPO and operation as a major public corporation. Last year, according to rumors, there was board pressure to make some changes in Juniper and Stephen Elop was brought in (from Adobe). Elop left after a year (ironically, joining Microsoft). It would be significant in our view that Johnson, like the other executives recently joining Juniper have a software background.
We have long said that Juniper and other network equipment vendors needed to be more focused on the software layer of the network to insure they could sustain feature differentiation. The changes at Juniper suggest that there may be a shift to a more software-centric position, and perhaps a more aggressive positioning in the Carrier Ethernet space, but it is clearly too early to say for sure.]]>