Juniper CTO: Open Source Software Can Be ProfitableJuniper CTO: Open Source Software Can Be Profitable
Moving to open source changes the business model but Juniper is ready to succeed selling software and the services required to support it.
July 3, 2018
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.
Figure 1: In moving to Juniper at CTO, Bikash Koley also acquired a sport coat, something he never wore as a Google senior network architect.
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.
Deep dive into real-world issues and virtualization deployment challenges with industry leaders. Join Light Reading at the NFV & Carrier SDN event in Denver, September 24-26. Register now for this exclusive opportunity to learn from and network with industry experts – communications service providers get in free! 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 Making money on selling software 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, if 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. CW: Okay. Do you think the industry has yet figured out though how that pricing changes? I find when I talk to people, depending on who you talk to, you get some very different ideas about how things are going to be packaged and sold and how to handle software licensing, for example. BK:: The industry is most definitely figuring it out, for sure. I would say that some have figured it out better than others. We have been giving this quite a bit of thought for a while and we have also sold pure software for quite some time. While I would not claim that as an industry we have all figured out what is the best model that works, as Juniper, we have done quite a bit of work in really figuring out how it changes our revenue and margin profile and how we monetize software and what's the best mix that ultimately works. But you're right in terms of perpetual versus licensing model. People are still in the midst of figuring it out. It's not completely figured out. PART TWO: Juniper on the edge -- Coming soon. — Carol Wilson, Editor-at-Large, Light Reading
You May Also Like
SCTE® LiveLearning for Professionals Webinar™ Series: Going to 10G & BeyondJul 26, 2023
Cable Next-Gen Business Services Digital Symposium 2023Jul 26, 2023
Open RAN Evolution Digital Symposium Day 2Jul 26, 2023
SCTE® LiveLearning for Professionals Webinar™ Series: Priming the Pump for Next-Gen PONJul 26, 2023