Sponsored By
Bikash Koley came to Juniper with a clear understanding of the power of open source software, from his years at Google as a senior network architect who helped drive things such as OpenConfig, getting the industry to rally around key standards for next-gen networks. (See Google to Open Key Network Models for Industry Comment, Standardization, Google, AT&T, BT Unite on Network Data Models and Google: OpenConfig Grows, Goes Commercial.)
As the CTO of Juniper Networks Inc. (NYSE: JNPR), however, he is seeing the other side of open source and how it is transforming vendor business models. Koley is still a big fan and says Juniper will be able to successfully transition to a profitable provider of software and more, in support of open source deployment and standards development. But that will require some significant changes in how the company operates. (See Juniper Weathers Hypercloud Storm, Says CTO Koley.)
In a telephone interview, Koley tells us that Juniper is ahead of the game in developing, selling and profiting from open source, based on its experience with Contrail and more.
Carol Wilson: With the move to open source, are you working with your customers in a substantially different way? Are they're expecting something different from you?
Bikash Koley: Yes, absolutely. There are a couple of things that come up every time we talk to the customers. One is that virtualization ultimately is about economy, and there is always the trade-off between capex and opex. And more and more, the customers are looking at how do you optimize the TCO [total cost of ownership], not just the capex or the opex.
And the way that open comes in there, is that ultimately open, in many ways, is a proxy for flexible -- the more you are able to go and pick the best of the breed as my requirements, or my applications, or my users change over time. In many cases, open source is almost a de facto requirement for them. Because, first of all, it allows them to go and build on top of what's already there, and in some cases move at their own pace.
And [secondly], in many ways, it gives them the guarantee that the interfaces and APIs and all the layers that they're building on top, [are] usable. So "open" there in many cases, is a proxy for de facto standard and for flexibility. So that comes up all the time in the conversation.
CW: When I talk to service providers about open, they complain some traditional vendors are just paying lip service. They also say there is still a critical role for vendors in providing distributions of open source, and ongoing integration and software support, as well as being somebody to call when things go wrong. From the vendor perspective, how does that change your relationship with your customer and what you actually sell service providers? Or does it?
BK: So three things come to mind when you're talking about open. Open standard, open API and open source. For Juniper, it is not lip service. [We] have actually been committed to all three. Open standard, starting from the UDP MPLS to more recently, VXLAN, Juniper has been leading open standards development. When it comes to OpenAPI, the Jet [Juniper Extension Toolkit] has been an OpenAPI for Juniper for a long time. gNMI [gRPC Network Management Interface] and OpenConfig are things that I was involved in the past life [at Google]. Juniper has wide support of that, almost everything. Juniper has been supporting open source standard APIs in devices. You may have seen, we announced wide support of P4 as [the language between] the control plane and the data plane, so we are really committed to it. Same thing is true with software. Contrail has been open source forever. We've moved it to the Linux Foundation. It's now community-led, it's called Tungsten Fabric as you know.
The part where I sometimes see confusion in both vendors of network solutions as well as consumers, is open is not equal to free, right? Open is flexible and somebody has to do the engineering. If you have capable teams to do engineering in-house, like many of the hyperscalers do, the Googles, the Facebooks, the Amazons, the Microsofts of the world, then it starts with open source component and builds on top, but you're really spending your money on development because there's ROI for it.
CW: So what do these changes mean for you as a company? What different kinds of skills do you have to bring on board, or are the skills already there?
BK: First of all, as a company, Juniper has always built software, that's the core to it. Of course, it has sold them as part of the hardware, but developing mission-critical software has been in the company's DNA, so that's not a whole lot of change. The change that the company is going through is ultimately you need an 'ops' skill set, just 'dev' is not enough because more often than not, you need to be able to stand up a cluster or stand up an NFVi stack and then operate it to start with, and then maybe hand off to a customer. It's a new skill set, but at the same time, it's a great service model that they actually like.
The second part of this is when you're building for open source, which we do, your development model is different. If you're really true to open source, then you have to build and do software releases in a way that is true to that. [That means] you're putting these on open source GitHub and you are allowing the community to drive the development and then you are consuming it so that the development model is different. Which again is not new to the company because Contrail has been doing it for a while, but we're adopting this across the board with P4 and other things. So that model is changing.
CW: How do you replace the profits you might once have gotten by selling hardware, by this other business model?
BK: In terms of monetization, that's a great question. There is a perception rightly or wrongly that open source ultimately reduces the ability for companies to monetize. I actually think it's a mistaken conception for the reason that I said. Open source is not free. Somebody is ultimately building and operating this for you. So our view of that is when it comes to hardware, the hardware is a commodity, we just use commodity hardware. There is no reason for Juniper to build it. We actually buy it from the same set of folks that, if you were to go and consume, buying commodity hardware yourself, you would buy it from.
When it comes to software, there is still a lot to be said about building reliable, fault-tolerant software that you can base your mission-critical systems on. What you really monetize is the software that you sell. In some ways I can think of, with the most complex software that Juniper used to sell, even if it was selling hardware, ultimately you were monetizing the features that run on the box. Ultimately that's not that different in terms of a model. It's just that the way that software is packaged and sold is changing.
The third piece, which is probably the most important one, is we absolutely expect over time our mix of pure software revenue versus pure hardware revenue is going to change toward more pure software revenue, which as a company, we're absolutely excited about because it opens up a lot of different ways of monetizing the intellectual property that we're building. That is changing as well.
— Carol Wilson, Editor-at-Large, Light Reading
This is an edited version of a story that was originally published on Telco Transformation's sister site, Light Reading. To see the full story, click here.
