Juniper Networks is using a playbook similar to that of its rival Cisco as it works toward becoming more of a software-centric company.
In this interview with FierceTelecom, Juniper CTO Bikash Koley said he expects the company to have even more software components across its switching, routing and security solutions.
"Our approach has been we have completely disaggregated our software so that you can run the same software on a merchant silicon, including white box," he said. "It makes sense. In fact, we do that for some of our customers. You can take the same software and run that on Juniper silicon, where the Juniper silicon is the most capable and cost effective way of doing the network functions that you need to do. The beauty of this model is that you actually don't pick and choose a different operational model than you're doing.
"Where we have gone one step further in this disaggregation path is where we have said we are going to build an operating system that allows you to leverage merchant silicon based on your use case."
In the most recent second quarter, Juniper's software business did grow by 27%, but it makes up just 10% of the company's revenues. Juniper's revenues were down in the second quarter, having dropped by roughly $100 million from $1.31 billion in same quarter a year ago to $1.20 billion.
Juniper's fortunes did receive a boost recently when Ericsson picked Juniper as one of its partner for its end-to-end optical transport solution for 4G and 5G.
In this Q&A, which was edited for length and clarity, Koley talks about NFV, Tungsten Fabric, cloud native, and Juniper's use of software.
FierceTelecom: What does the industry need to do to move virtualization forward?
Bikash Koley: We're actually seeing lots of progress towards virtualization. The company's focus on Contrail as a platform should be indicative of how seriously we take virtualization. We have a very large deployed base of Contrail. I would say a significant majority of Tier 1 service providers that have deployed virtualization, they have deployed that on us.
There is reason for that. We actually have made a few things easy for them, which used to be one of the challenging parts of virtualization. We sell them a telco cloud solution that not only offers them the NFVi stack but it also offers, in partnership with Red Hat specifically but other providers as well, the compute and the storage set all combined together with a single pane of glass management and single pane of glass visibility for performance. All of that makes the operation of a telco cloud viable with operations team that many of them have.
RELATED: Juniper CTO talks about how open source software is fundamental to his company's strategy
Many tried following the hyperscaler model four or five years back and realized in doing so that they have a very different set of people and processes than the hyperscalers do and this complete disaggregation model of telcos does not work. However, they do want openness in telco cloud. They do want an open telco cloud where they can go and buy VNFs from many companies and the VNFs have a good chance of working. We see this next wave of telco cloud actually really picking up, and part of the driver is obviously 5G. People are preparing for moving to the 5G network in a cost effective way, and virtualization allows them to do it.
FierceTelecom: When I've asked other people that virtualization question they've mentioned the complexities of deploying NFV and the need for more standard VNFs. Do you agree with those assessments?
Koley: NFV has been more difficult than it needed to be. Part of the reason being, in some cases it went too far down the disaggregation path where it was disaggregated so much that putting it back together took a lot of work. Many have learned from that, and the leading ones have taken a path where it is not disaggregated to that level but it's still based on open technology.
The VNF transition still remains a problem, but the leading vendors are providing VNFs that work. We have worked with many leading vendors of VNFs, including our direct competition, where they work seamlessly on our NFV stack.
It all depends on what choices people have made on the NFV stack. You'll probably hear a slightly different view if you talk to those who have been deploying our stack. Not to minimize the problem statement itself, it is complex, and we're trying to simplify that. That has been our approach.
FierceTelecom: Have there been any unexpected use cases since Juniper put OpenContrail into open source as the Linux Foundation's Tungsten Fabric?
Koley: Contrail used to be open source even before it was called OpenContrail. It was not a community like open source, but the interesting part is it's a product that has a lot of customers who have a lot of direct interest into the direction of the product. That was part of the reason that we took it to Linux Foundation, because it was not a community that we had to form from scratch. There was already a pretty vibrant community of users of Tungsten Fabric, who were in fact using that in their production use case.
In fact, if you look into the Tungsten Fabric board members, you'll notice that it's a combination of companies like ourselves that develop as well as companies that consume. In some ways it hasn't been anything new, but on the other hand, being part of Linux Foundation networking ecosystem is a good thing because there are other projects in that umbrella that we directly contribute into, Linux being one, P4 being another one. Very recently, we are one of the leading members of Akraino, that's the edge compute stack that LFN is standardizing. Being part of the Linux Foundation community actually allows us to interact with these projects that are sort of in a close neighborhood, and also figure out where we can go and contribute our insight. So I see that as a huge positive of moving to Linux Foundation.
Fierce Telecom: Since you just mentioned it, how does Juniper define edge computing?
Koley: Edge computing is actually a key focus for us, for multiple reasons. Ultimately, the way we view the service provider business, especially as someone is moving into the world of 5G, you need to figure out how do you monetize your infrastructure better. The reason being, anytime you go into a technology jump it does bring a lot of excitement around it, but you also have to deal with the reality that you are trying to turn up a new network or an access layer which may or may not lead to a lot of additional revenue. The obvious economic driver becomes what access I have and how do I monetize it?
One of the things that I often say is that service providers, they have these awesome beachfront properties that they're not fully monetizing. I'm talking about the central offices that they have or the proximity to the users and the low latency access that they have to the users, that even now is not fully monetized beyond just providing connectivity service. To us, edge computing or edge cloud, whatever you want to call it, it's really ability to monetize the low latency access to space and power that service providers have, not only to provide mobility of a service but essentially allow many other services to take advantage of that. The obvious examples are connectied cars, AR, VR, and IoT. Those are some of the leading uses that we see for edge cloud.
We always built Contrail to be a very distributed cloud. That has been fundamental to the architecture of Contrail, where we have abilities to run the control plane remotely so that you can essentially just have workload that is applied at the edge. You can run microservices and you can have embedded security seamlessly over one connectivity.
This has always been part of the architecture of Contrail. An extension of that has been we're taking many of those technologies to this new Linux Foundation edge computing project called Akraino, where we are in fact offering many of the Tungsten Fabric features that are very relevant for edge cloud. You will see us being quite visible in that community, but you will also see us applying Contrail to solving the edge problem.
FierceTelecom: That's all part of the move to cloud-native, right?
Koley: It is absolutely cloud native. It natively integrates with communities. It is designed to launch containers and microservices in a remote location over very small infrastructure. If you so choose, you actually can run this as a multicloud deployment where you can take your edge deployment and you can connect it to your data center or to a public cloud. We support the three major public clouds for this scenario, both for a control plane and for running workloads. Yes, it is absolutely cloud native, from day one.
FierceTelecom: What are the key steps to becoming more of a software company and monetizing it going forward?
Koley: If you look at Juniper, a vast majority of the engineering team are software developers. They're not hardware engineers. Juniper has always been a software company. It's just that the software is run primarily inside the boxes that Juniper sells. If you think of what Juniper monetizes when it sells an MX or a PTX as a router, it monetizes the features from the functions that it ultimately sells in the software. Whether it's BNG or MPLS, it has been our set of software functions that are monetized.
What is changing for us as a company is we're going from being a hardware system provider to becoming a solutions provider. A key part of the solution is in fact software, as you pointed out. The way we view this is that there are functions that used to be enclosed within a chassis that are now freed up to run as a solution outside of the chassis. That also allows it to offer many other solutions that it did not offer before.
One very recent example is our launch Contrail Enterprise Multicloud. The whole idea of Contrail Enterprise Multicloud is that Juniper has always built switches, but how do we take those switches and also Juniper firewalls and maybe even Juniper routers and turn them into a multicloud solution for the customer so that we're not only just doing the physical network we're also taking care of virtual overlay. We have extended our capability in the compute as well where we can orchestrate workload in bare metal servers, in virtual machines, as well as in containers. Again, leveraging Kubernetes for example.
Here's an example of where we are applying software to build solutions that are much bigger than what our individual hardware systems did in the past, which is a very important part of our strategy. Our software revenue is growing at a healthy pace. I expect that we are going to have more and more software components in the solutions that we sell. Whether it's switching, whether it's routing, whether it's security, you're going to see more and more software components in the solutions that we're selling.