Juniper CIO on Going All-In with Cloud

Q&A with Bob Worrall on complete transformation of the networking giant’s IT strategy

Yevgeniy Sverdlik, Former Editor-in-Chief

March 28, 2016

12 Min Read
juniper
juniper

When Bob Worrall joined Juniper Networks as CIO in July 2015, the multi-year transformation of the company’s IT strategy had been mostly complete. Juniper had gone from an on-prem-first to a cloud-first approach to infrastructure and from operating 18 data centers around the world to one in Sacramento, California, which hosts some leftover legacy applications, and two sites to support its engineering efforts.

DCK covered Juniper’s data center consolidation earlier.

We caught up with Worrall earlier this month in Las Vegas, following his presentation at the Data Center World Global conference there, to get more details about Juniper’s infrastructure rethink and to ask him about some important industry trends.

Below is a Q&A, in which the Juniper CIO reflects on the experience of the company’s switching from a “Why cloud?” attitude to a “Why not cloud?” one, his views on commodity hardware, which is eating into traditional sources of revenue for vendors like Juniper, the rise of Software Defined Networking and Network Function Virtualization, as well as the aftermath of the announcement he made last year that the company had found a “backdoor” in its data center security software.

The interview has been edited for clarity and brevity:

Data Center Knowledge: Can you describe Juniper’s use of cloud computing today?

Bob Worrall: The short version [of the answer] is we use cloud for everything. We have pivoted away from ‘why cloud?’ to ‘why not cloud?’ and I think that has transformed our overall approach. We don’t even consider anything on-prem anymore. It’s just not part of the conversation. If someone even suggested that, they would be looked at as someone from a different planet or something; it’s just not part of the DNA of the company.

We use cloud in all various ways, from engineering to corporate applications to some custom applications, everything in between. All of the flavors of it.

DCK: Can you share what your cloud services spend is?

bob-worrall-juniper-e1459137614328.jpg

Bob Worrall, CIO, Juniper Networks

BW: I can’t; that’s an internal number. But the overall spend for IT in the last five years has not materially changed. The shift, obviously, has changed: from depreciation on equipment and people to cloud services. We’ve harvested savings in one area and applied those monies to others.

DCK: So much of the spending has shifted from capital to operational cost?

BW: Most of it. We still have a lot of people as well, but the people that we have, fewer and fewer have been on the infrastructure side. We’ve invested more in roles like vendor management and compliance and security. We still have a large development team doing custom development, applications and so on, for internal needs.

DCK: Can you describe the tipping point when Juniper decided to go all-in with cloud?

BW: Back in 2011, with some early wins in cloud adoption of [Microsoft] Office 365 and so forth, I think the company just realized that cloud was real, if you will. Real in the sense that the savings were real, the operational benefits were real, the agility was real. And so there was a fundamental change in the attitude: Let’s go chase it. Let’s go big.

I think that was further supported by the realities of the customers that we began selling into back then. Large cloud providers who were running their businesses on all of these technologies and doing so very effectively. So, if it worked for them, certainly it could work for us.

DCK: Many of your biggest customers, the big cloud providers, have switched to commodity hardware. Have you done the same?

BW: On the hardware side we have various flavors of commodity hardware, up through name-brand providers, and everything in between. Really, it depends. In areas like engineering, we’re more apt to go with white-box approach to things, but for some applications that have unique software requirements, or other requirements, we might choose a more traditional supplier.

DCK: Can you elaborate on that last point, that some software requires hardware from traditional vendors?

BW: Security, or DR, or high availability, or some of those kinds of requirements for the applications. It’s not that you can’t achieve those with commodity hardware, but in some cases it might just be easier to buy a solution that includes some name-brand server providers.

DCK: Are services a big part of that calculation?

BW: Services are a big part of it. We have applications that support our customer service team, for example, with points all around the world, so it’s critical that we be able to get depots and spares and those kinds of things to many locations around the world. For some commodity suppliers, they may not have depots and points of presence in the Far East or Eastern Europe, so, in some cases we’ll go with name-brand providers.

DCK: You mentioned in your presentation that you now hire software engineers instead of traditional IT pros. Can you elaborate?

BW: That’s an aspirational goal. We’ve begun doing that in our emerging technology group, which looks after this transformation to the cloud. It’s really just a different skill set that IT is going to need going forward. [We’re] trying to hire less developers in the sense of classic Java development, but more people who understand automation, particularly – a big skillset gap for us.

And that’s true not just for the software side but even people on our networking side. Juniper products are really moving to a software play. We want people on our networking team who understand software development, who use those skills to focus on more automation, so across the environment we’re looking for those skills more and more.

DCK: Can you describe how Juniper re-architected its global network?

BW: Back in the day, it was a traditional mesh network, and I think what they realized back in the 2010-2011 time frame was that we needed a highly resilient low-latency network that can provide connectivity to these global cloud services at various points of presence.

So, sitting down with our networking team, our product team, and our network providers, they came up with a topology which has seven points of presence around the world – from Sydney and India to several points in the US, etc. Between all of those points we use a Juniper-managed MPLS network.

We rely on AT&T and Verizon for the underlay, but we provide our own network overlay on top of that, and then rely on some partners for fiber connectivity to ensure low latency. It’s a very resilient, highly dynamic, highly performant, application-based network that has given us the ability to move all these applications out to the cloud with virtually no degradation of service back to the customers.

DCK: Do you use Software Defined Networking and Network Function Virtualization technologies on that network?

BW: SDN is the new thing. What we’ve all realized is software-defined networks are really important, but, securely software-defined networks are even more important, so we use all of Juniper’s products in that space. We also rely on Contrail [Juniper’s network virtualization and automation software] and OpenStack. And that again transforms the skillsets of people in IT. Managing a box is one thing, but now you’re managing a network that’s defined in software. It requires a whole different orientation.

DCK: What kind of security changes has Juniper made as it made the transition to an all-cloud infrastructure strategy?

BW: Just more investment in security. As you move everything out to various locations, there’s an expectation of maintaining if not enhancing the security profile, so we’ve been moving away from this traditional perimeter defense to more of a defense-in-depth strategy. From data all the way to the firewall and everything in between is kind of the new orientation.

Since this journey began, there’s been a material increase in security staff that we have, both on the architecture side, as well as the response side. And we partner with a number of people to have complete end-to-end visibility in the lifecycle of data. It’s certainly elevated the role of the CISO in the conversation.

DCK: What are your thoughts on the Open Compute Project, the Facebook-led open source hardware and data center design community? I’m especially curious to hear about it from the networking perspective, now that both Facebook and Microsoft have their own networking solutions.

BW: Juniper has always believed wholeheartedly in open compute of all forms. I don’t know the company line specifically on SONiC [the open source data center networking software Microsoft recently contributed to OCP], but we’ve certainly made a full commitment to Contrail [Contrail is based on OpenContrail, the open source network virtualization software] and OpenStack, and all of those components. And we’ll certainly continue to sell into those providers as things evolve.

What I don’t see is anyone broadly adopting the Open Compute stack on the networking side yet. I think Microsoft’s announcement is interesting, but it’s going to take quite some time for large enterprises to go deep so to speak.

So, Juniper will continue its product development, keeping fully aware of all the OpenStack and open network initiatives, and we’ll participate in all those conversations.

DCK: Would Juniper consider joining OCP? (Cisco, its biggest competitor, is a gold-level member).

BW: That I don’t know.

DCK: If and when OCP networking becomes more viable for enterprises, how can Juniper ensure its market share is safe?

BW: As the world evolves, we’ll continue to evolve with it of course. I don’t know if there’s anything specific I can say in terms of trying to protect our market share. But we’re a quickly evolving company, and I think our products are keeping pace. Juniper’s products themselves are going from what used to be pure hardware to more software, so we’re taking that whole disaggregation opportunity to separate hardware from software, and once we have the software assets, I think we can address some of the unique requirements of our customers through delivering software as opposed to those traditional hardware stacks.

DCK: Several months ago you posted a blog post announcing that Juniper had found a “backdoor” in some of its data center security software. What kind of fallout did you observe as a result?

BW: I wouldn’t say “fallout.” There’s been a lot of questions from customers about upgrading the old NetScreen boxes [Juniper’s firewall product] and so on. People were concerned, but the reaction was more along the lines of, “Thank you for being so forthright in telling us. Now we have some work to do to go patch the boxes. But I’d rather know than not know.”

As soon as we knew, we took a very aggressive posture about being transparent with that issue, and we’ve seen a very positive response actually from our customers. A little openness goes a long way.

Obviously, we’re not going to talk about details of any of it, but we’ve had customers ask about our security investments internally and are we protecting Junos [Juniper’s network OS] and all the other core assets of the company. And the answer is of course. The NetSreen situation was a very old end-of-life product. The world has changed dramatically since then. I think with that reassurance customer are more than satisfied.

DCK: Big part of Juniper’s IT transformation was switching from an ERP system by Oracle to an SAP solution. Why did you guys make the switch and what was the process of switching like?

BW: I think there were some features and functions in SAP that were not readily available at the time in Oracle. Juniper’s distribution models and pricing models are just one example of areas where there were highly customized solutions in Oracle and we found more out-of-the-box solutions in SAP.

As is typical, they did a big bake-off, all the technical analysis and the decision came down somewhat close between the two, with a slight leaning toward some of the offerings in SAP. The transformation itself has gone well, although if you ask people on the project who had been working on it for three years, it’s a lot of work.

DCK: How many people worked on the project to switch from Oracle to SAP?

BW: Probably at the height, 700 people, and that includes part-time people doing testing and validation, data transformation, all of that. But when I joined nine month ago we had probably two-thirds of IT working on the project in some form or another.

And having been through a number of these ERP deployments myself, I can say now, a couple of months after the transition, it’s actually gone more smoothly than most of them have.

Data transformation is always the biggest challenge. Moving from Oracle to SAP, getting the data right is a big challenge. You get dirty data in one system; you’ve got to clean it up before you transform and load it. We spent a lot of time trying to get that right, and I think we did a good job at it, but it’s not perfect. Within days after the conversion in January, the business was about at its normal transaction levels, and today as we speak we’re certainly back to normal transaction levels, order processing cycles.

DCK: Juniper has consolidated from 18 data centers around the world to two data centers that support engineering and one in Sacramento that still houses about 50 racks of IT gear running legacy applications. What’s running in that Sacramento facility and what are your plans for it?

BW: The Sacramento data center is about 46 racks. It’s all the stuff that is at the tail end of the transformation, things that didn’t have an obvious home. Many things that are probably five, 10 years old, but it just takes a lot of time to go find the owner of the application or the tool, or whatever it might be, and engage in the conversation of, “Can’t we just end-of-life this? Do we really need to reinvent it?”

Once that conversation occurs, it ends up in one of two places. Either yes, we have to re-architect it for cloud, or we can end-of-life it, and maybe with end-of-lifing there’s an archiving strategy.

These several dozen tools that are left are just the last, most difficult ones to identify the owners for, that don’t have a clear disposition. You can imagine, some of these are probably 10 years old. Over 10 years, the person who owned it 10 years ago has left, and there’s no clear ownership. In some cases they’re applications that are used very infrequently, so people are a little reluctant to say you can do away with it, because they might need it next month or a year from now.

So, it’s just a lot of conversation. But we get through them. We knock them off one by one.

About the Author

Subscribe to the Data Center Knowledge Newsletter
Get analysis and expert insight on the latest in data center business and technology delivered to your inbox daily.

You May Also Like