Kevin Johnson
Juniper Networks had a challenging 2012 as new product cycles were slow to take hold and global economic conditions took a toll on sales. The company also undertook a restructuring that saw 500 positions cut and the departure of four executive vice presidents. As the Sunnyvale, Calif.-based company looks to re-energize its business, particularly with an eye towards enterprises and data centers, CEO Kevin Johnson shared his lessons learned in leading Juniper since 2008, as well as what's ahead for the company in a discussion with IDG Enterprise Chief Content Officer John Gallant and Network World Managing Editor Jim Duffy. In this installment of the IDG Enterprise CEO Interview Series, Johnson also shared his thoughts on the hot topic of software-defined networks (SDN), Juniper's role in enabling cloud and competing against the industry's 800-pound gorilla, Cisco.
Customers are moving toward highly virtualized data centers, cloud services, hybrid cloud. In this context, why is Juniper a better strategic partner than, say, HP, Cisco, Brocade or another networking company?
The two key market trends are cloud computing and mobile Internet. Cloud computing can't be enabled unless you have a high-performance, reliable network that's connecting the users of services and applications to that data center and the compute and the storage layers within the data center. The heritage of Juniper is focused on innovation with a specific focus on high-performance networking, so tackling the most complicated problems of scale and performance and reliability in the network. If you're moving workloads from one data center to another or connecting thousands of storage and computing devices within a data center, our focus has been enabling solutions that solve the problems of scale and reliability.
Some of the key differentiators for Juniper are that we invest in R&D and we develop our own silicon that we use in many of our systems -- not all of them, but in many; silicon that has been purpose-built for different domains of the network and different areas of the network problem. No. 2, we focus on the software operating system that runs in the network. We've been very focused on Junos as a common software platform that runs across the product portfolio, which is something that helps customers better manage, configure and operate those systems. That ultimately leads to lower cost of ownership since it's a single operating system, yet still having the benefits of high performance through the silicon.
RELATED: 5 things Juniper must do to reignite growth
MORE: FABRIC WARS: Cisco vs. Brocade vs. Juniper
Juniper has done very well in the service provider business. As we move more toward this cloud world, how specifically would you capitalize on that strength in service provider to benefit enterprise customers?
The investment we make in R&D strategically across routing, switching, security, we look to take those products to market to both service providers and to enterprise customers. Now, why would an enterprise customer be able to leverage engineering work that handles networking problems with the scale of the Internet? Well, when you look at many large enterprises today, they actually start to look like a service provider. You look at the scope of their networks, you look at the complexity of their networks, you look at the requirements they have for performance and reliability, whether it's in financial services, large federal government, defense agencies, you look at healthcare institutions. Look at many of the large industry verticals in the enterprise and the requirements they have in terms of performance, reliability and scale start to mirror what we've seen from service providers over our 16-year history.
Kevin, you joined in 2008. Obviously, one of the key things for Juniper during this time period has been penetrating the enterprise. How would you characterize your success in the enterprise to date? And what kinds of things are you going to do in order to continue to improve your position in enterprise?
Certainly in that journey I think there are areas that we feel like we've made some good progress. There are a lot of lessons learned and there are a number of things that we feel that we can do a better job on. Today our revenue is roughly 38% to 40% from enterprise and 60% to 62% from service providers. We've grown both in service provider and enterprise over that four-year period, but the growth in enterprise has been faster than the growth of service provider, as we have gained market share in the enterprise. I think that in 2012, year-to-date through Q3 our switching and fabric business has grown 20%, much of that a function of data centers that we're enabling, campus and branches we're enabling in the enterprise. We've taken our routing portfolio and we've expanded it to provide routers that are more aligned with the needs of enterprise customers. The security business is one that was anchored in the enterprise and we've expanded that to cover both enterprise and service provider.
So let's look at two of those aspects that you brought up: lessons learned in the four years in the enterprise market, and then things that you see as key strategic elements going forward...
I think a few of the lessons learned, one of the things that we've observed is that enterprise customers think about their networks more and more in specific domains. And that's important because the architecture of those networks in domains is different and it allows enterprise customers to think about bringing in another vendor or a dual vendor strategy into their networks.
So when you say domains, do you mean different layers of the network?
Different areas of the network. And there are three basic areas that it breaks down to: the wide area network, data centers, and campus and branch. So as we engage with enterprise customers, oftentimes as they learn about us and think about where they could apply us, the first problem they go through and solve is which domain they think it's most appropriate to introduce Juniper, begin to utilize Juniper technology. Historically, we've had a footprint in the area of security, and security plays a role in all three of those domains. We've invested in R&D to build out our switching and our fabric portfolios. We've seen good growth in that. We've continued to take share. We're still a small share player though, when you look at the switching addressable market. It's a $20 billion addressable market and we've grown to be about a $600 million plus business in switching and fabric -- our QFabric product and our EX product line.
We've had some lessons learned there as well. I think we, over the last year, have had a number of features that customers have asked us for, things in the area of high availability, how they connect a single server to multiple fabric nodes, and so we've worked to enable many of those features. There are still some more software features that customers ask for. But one of the important lessons learned in QFabric was where we thought customers would want a single implementation of fabric in a data center, in fact they prefer to have multiple fabrics at a data center, and that was because they didn't want to have a single failure domain or fault domain. They wanted to be able to have the opportunity to take a data center, break it into some smaller fabric chunks, and enable the architecture that way. So last quarter we introduced a new version of our QFabric interconnect that basically is a scaled down version that enables them to implement multiple smaller fabrics within a single data center. So that was a lesson learned.
Then certainly in the data center era today there is a lot of discussion around the concepts of software-defined networks. In many ways QFabric was architected with several similar principles to a software-defined network. The QFabric controller is a body of software that now controls the nodes and the interconnect, and yet in order to enable the QFabric implementation and the value it creates, there was no open industry standard protocol for that communication. So we utilized some protocols that we have. So I think the discussion right now in a software-defined network is how we're going to continue to evolve both our single-tier fabric and our two-tier switching portfolio around the concepts of SDN as we did with QFabric, but do it in a way where we can now start to influence the industry standards for open industry protocols, including things like OpenFlow and other industry protocols that can be enabled in these data centers. So I think that was another lesson that we learned.
You've said in a couple of quarterly conference calls that QFabric and Juniper's New Network initiatives embody the principles of SDNs. Yet Juniper has not been one of the more aggressive or vocal proponents of SDNs, nor has it come out with an overarching strategy like your competitors have done on SDNs. Why is that?
Well I think we've been a very strong proponent of SDN and we've been very clear that we embraced the fact that the industry standard protocols will evolve. We're a member of the OpenFlow community. We've partnered with many vendors that have OpenFlow-based controllers. We've enabled the SDN protocols, including OpenFlow, in our MX routers. We've publicly announced we're enabling them in our EX switches and in QFabric. So I think we've been very clear that in the domain of the data center that the business problems, technology problems that SDN is trying to solve, that there's a set of those that we think are very viable problems to think about how software can communicate with the network systems to solve those problems. And we've been very clear that we're going to participate in the industry to shape the standards and ensure our systems can interoperate with open industry standards, including OpenFlow. What I think people are waiting to hear is -- do we have a view on what type of SDN controller we might bring to market, and how would that controller participate in open industry standards and how would that controller create value beyond what current OpenFlow controller providers provide? We've committed to build those SDN protocols into our systems, including OpenFlow, and we've been making progress in this.
[Ed. note: Juniper says it won't make a broad SDN strategy announcement until early 2013. On Dec. 12 it announced the acquisition of SDN controller startup Contrail Systems]
Do you think your competitors have been more "hypey" in the strategies they've vocalized?
I think we're certainly at a point where something like SDN, there is a lot of visibility on that topic and with a lot of visibility and enthusiasm comes the risk that hype gets ahead of the reality. That doesn't mean that there are not some interesting things that software-defined networks can provide, but it does mean that as a leader in the networking industry we feel like we have a responsibility to, number one, be at the table and help shape the industry standards around this concept of SDN, which we're doing. No.2, ensure that our systems interoperate with these open industry standards. And No.3, as we share our point of view on where we're going to play a role and where we think this thing is going to go, we want to make sure that that has substance and that we've thought it through and that it's real, and that we don't fall into the trap of wanting to just be a part of the hype for purposes of being part of the hype. But I think there certainly is a lot of interest in the topic of software-defined networks and certainly we're being very thoughtful about the implications of those concepts and the right way, from our perspective, to enable them to help customers.
A couple of months ago we interviewed Bob Muglia [Executive Vice President of Juniper's Software Solutions Division] at your headquarters and he mentioned that Juniper is looking to coalesce the industry around a third standard open source controller as an alternative to those from Cisco and VMware. Can you update us on that plan?
I think specifically what he talked about was OpenFlow-based controllers and there's already OpenFlow controller technology in the open source community. And we've partnered and worked closely with Nicira and Big Switch and many others. And our commitment is to open industry standards as it relates to SDN, and OpenFlow is certainly one of those open industry standards. The view is that with some of the OpenFlow controller technology that's in the open source community, that there's a high likelihood that that's going to get some traction by some number of customers and others in the industry that are going to keep contributing to that. And we think that's a healthy thing. We think in something like software-defined networking, it's healthy to have innovation coming from a variety of different sources. And so we do think that will manifest itself in an open source controller that supports OpenFlow. So our systems will interoperate with OpenFlow and other SDN standard protocols. And I think the things that we might be doing in the area of software controllers maybe will go beyond capabilities of the OpenFlow API, but will still be based on open industry standard protocols.