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 Light Reading that Juniper is ahead of the game in developing, selling and profiting from open source, based on its experience with Contrail and more. In the following two-part interview, we discuss open source, the future of networking and what Juniper is up to at the network's edge.
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.
If you don't have an engineering team, then you need somebody to ultimately put this together for you. They get you to a place where it's deployable, it's operable. You have somebody to go and fix it for you. For us, it has been a very interesting transformation where many of our customers started with the completely disaggregated model. And more and more, they're coming and asking us for build, operate, transfer.
This is one of the reasons that we announced our partnership with Red Hat. We now sell a product called Contrail Cloud, the whole idea being if I want to deploy an open standard with NFVi infrastructure and if I'm a service provider, just the CI/CD [continuous integration, continuous development] of it takes up all my resource. I don't want to do it. I need the ability to call somebody when something breaks. We're invested in that as a product. So obviously like you said, the way that we build and offer the product is changing, including the risk model that goes with it.
Next page: Making money on selling software