Juniper's product line covers routing to switching to security. And when you look at this whole cloud computing schema, you see the data predictions in data centers and you see the users on the other end being connected through the network, whether it's a local area network or a wide area network.
We see our entire product line – routing, switching, security -- all applying to this cloud computing. And furthermore, Juniper specializes in high-performance networking with the objective of cloud computing. Having said that, Juniper's approach is always through providing better technology and trying to attack the fundamentals of the problem. So rather than push for additional gadgets or additional software that actually end up making the whole thing more complicated, Juniper's major message to the data center in cloud computing is trying to help the customer simplify the data center network. What do you mean by simplifying the data center?
In cloud computing, people want to use sharing to reduce the cost. And obviously, as you gather together more resources, you can achieve a much higher level of cost reduction and also achieve much deeper elasticity in offering services. [These] resources – whether they are servers or storage appliances – are interconnected through the data center network, so in order to maximize the sharing, you want to scale. In order to scale while keeping the
In this case, not just our switching boxes or fabrics but also our Junos operating system, the Junos space management platform and all the way to the Junos Pulse (the security client) -- all of these contribute to the overall simplification and enhanced customer experience. There's been a lot of talk from other vendors about management in a virtualized environment and about software switches to deal with the fact that the network is now inside the server. I am wondering whether Juniper has an answer for management within the virtualized environment.
Virtualization does not necessarily simplify the overall network. Virtualization helps the flexibility and enhances the utilization of the servers. When it comes to virtual switching, it's really the side effect of having multiple virtual servers inside the physical server. The virtual switch itself not only doesn't contribute to simplification, it actually adds more complexity for the customer. Now the customer has two switching worlds to manage. One is the virtual part, and one is the physical part. So the area the industry really needs to work on is to avoid adding yet another layer in front of the traditional physical access layer and yet another layer now residing in the server's hypervisors. The whole thing should be integrated together; and furthermore, appropriate management tools should be provided to customers so they can manage both the physical and virtual world in the same way rather than separately. The industry is still not mature in this particular area.
One difference between Juniper's approach and, let's say, Cisco's approach is that we try to support the standards so that Juniper is not going to duplicate or follow what Cisco did by introducing their proprietary virtual switch into, say, VMware's virtual environment. Instead, through supporting industry standards like VEPA or VEP, and further by providing support to the customer utilizing the well published VPI that VMware or any hypervisor vendor advocates ... [we will] go through that [route] vs. introducing yet another proprietary module. You talked about the need to inject automation into more parts of the network. How do you do that?
There are two major areas we are actively working on. We believe the data center network needs to be simplified. Rather than multiple tiers of conventional Ethernet switching with appropriate hardware and software, the vast majority of the data centers currently in the world could easily be handled with a very simple two-tier architecture. That's one area.
Project Stratus is the ultimate simplification, trying to collapse all of the layers of Ethernet switching effectively down to one. So the data center fabric essentially becomes a gigantic logical single switch. You must have the playing field flat in the hierarchy, then you can really maximize the kind of automation to do the job.
The other major direction that Juniper is working on is the application of automation. The foundational platform we launched in Juniper Space was designed to serve as the platform with appropriate database and appropriate Web application servers built in; and yes, it has a publicly supported BPI so both Juniper's module and third-party modules can be plugged in to apply various policies and automation that customers desire. A few modules we started releasing are to help the customers monitor the data center network to help them quickly set up MPLS-type networking protocols. What's the timeline for Project Stratus?
As we reported in our annual financial analyst conference in February, it's a work in progress. We have all the hardware for the first release and configuration, and in terms of releasing [further] configuration, we are talking about 2011. HP-3Com has announced a converged data center strategy, and Cisco has its Unified Fabric. Is there concern that the competition will be too deep by 2011?
Well, first of all, if Juniper were the only one talking about it, then you would question whether that's even the right vision. So in a way, when you see various competitors start talking about the same thing, that's one way to endorse that the industry is going in the right direction.
Now, knowing HP ProCurve's product line and knowing 3Com's product line, Juniper has been working on this Stratus vision for more than two years, so you really have to conclude what HP 3Com was announcing was nothing but utilizing the latest and greatest they had and trying to provide an adequate data center network -- and I am pretty skeptical. Once you remove all the top-level marketing façade, it can't come anywhere close to the simple tier vision we have for Stratus.