After close to 10 years at Google, Juniper Networks' Bikash Koley has earned his open source stripes, and now he's using that knowledge to help his current company further develop its software ambitions.
Koley has been in his role as Juniper Networks' CTO for a little over a year now, and he is tasked with charting the vendor's technology strategy across network functions virtualization (NFV), hybrid cloud and packet-optical integration, to name just a few of the key projects.
In this Q&A, which was edited for clarity and length, he addresses the use of open source software, the building of operational teams at Juniper and the status of open source communities. In the second Q&A, Koley discusses edge compute, cloud-native, NFV and white boxes.
FierceTelecom: Can you talk about what you learned about software and open source when you were at Google?
Bikash Koley: It was a wonderful experience building one of the largest distributed software systems in the world. There was a lot of focus on really building a distributed software system. There were lots and lots of lessons learned, but the first and probably the most important lesson learned is that open source is not free. Open source gives you a good set of baseline technologies to build on top of, but in order to consume open source it's always people, process, technology. You need people that are conversant with taking software in the raw form and then doing something with it to turn that into solutions.
As for process, when you are building a software system, whether you're building it based on open source or whether you're building it based on your own technology, you ultimately need the process to do upgrades, releases and safe rollouts in a large system.
Ultimately, coming to another part of the journey, you need operations teams that are fully conversant with running software. In the case of Google, that happened to be a team called SRE, site reliability engineers. At Juniper, we have started talking quite a bit about how your automation software has to be run by a new breed of network operators. We sometimes refer to them as network reliability engineers, sort of taking a page out of the SRE model.
What it really comes down to is the form in which you can consume software is a function of the people and the process that you have. It is not the same for everybody. Google, Amazon and Microsoft have a different set of people and processes, including skill sets, than many enterprises would have or many service providers would have.
The form in which you consume the software is going to be different. This is one of the truths that we're taking in building software systems that are very similar to the infrastructure that the hyperscalers operate, but packaged it in a way that it is actually easy to consume for those who don't have an army of software engineers to run the operations. It's very important to keep in mind who is going to ultimately consume the software systems when you build the product. It is not the same for everyone.
FierceTelecom: That all dovetails really well with my next question. How has open source and open software changed the culture at Juniper?
Koley: Yeah, so when we talk about open from Juniper's perspective, there are three things that we're talking about. One is open protocols or open APIs. Juniper has always been about open protocol and open APIs, whether it's BGP, MPLS, or many other things or protocols that Juniper drove, it has always been about open technology. Open source is absolutely important and fundamental to our strategy. Part of the reason being the way that standards get developed in the new world is in open source.
One can say Linux is really a standard, because it gives you a set of standard APIs. We view many of the open source technologies the same way. Kubernetes, in some ways, is an open source technology, but it's also a standard. If you are not part of the open source community, you are not influencing or developing the standards. We want to be part of the community where we are not only participating in developing open source software, but we're also influencing where the open standards are going. That's the second part.
The third part is actually probably the most important, which is we are building products that are open. What I mean by that is are we building products where the product is disaggregated enough that it allows either our customers or our partners to go build things on top of it. I'll give you a concrete example. We have built on Facebook's Open/R. You can call it a standard, but it's what Facebook uses for interacting with their controller. We have built Open/R into Junos. We have done the same thing with an open source programming language, which is called P4. We have built P4 into Junos.
It is building products where the products are open so that others can build additional software or solutions around the product that we're building. All three of these are core to what Juniper does. It's actually a very important part of our strategy.
RELATED: Juniper beefs up MX platform with new silicon, more programmability
FierceTelecom: P4 is becoming the primary programming language for SDN?
Koley: P4 as a programming language is actually quite powerful, especially when you have a very programmable silicon like Juniper produces. We have a new silicon release called Penta that we use in our MX routing platform. P4 gives you a very nice open construct to define how you go and program the silicon. That is part of the reason that we adopted P4, because it allows us to explore the capabilities that our silicon has to an open interface. That would be an example of how we're sort of opening up our products, and adopting open source and open standards in the process.
FierceTelecom: Do you think there are too many open source communities and standards bodies in telecommunications?
Koley: One of the nice things with an open source community is that the law of natural selection works very well. If you are building either a community or a set of products that are valuable, then that community thrives and grows. If you don't, then it ultimately at some point it sort of dies off. I actually don't mind that there are more.
More is better, in some ways, because you get the innovation coming to the front. Oftentimes, they actually leverage each other in the process. Again, ultimately, a community exists only when it's building a product that is valuable to the community members, so I actually believe open source is working as intended.