The former Google exec has moved quickly to build a Juniper PaaS and disaggregate its products, all in preparation for a multicloud future.

Craig Matsumoto, Editor-in-Chief, Light Reading

January 12, 2017

12 Min Read
CTO Bikash Koley & the New Juniper

In just a few months, Bikash Koley has set some big wheels in motion at Juniper.

He joined as CTO in August, arriving from a high-profile job as Google's head of network architecture. He helped define some of the principles we now bundle into the word "hyperscale." Often, an executive isn't made available to the press so quickly after arriving, because they don't have that much to say yet. Koley has a lot to say.

Yes, he's bringing some Google mentality into Juniper, but his ideas are much more specific than that. Having worked on the vendor side before -- and understanding that his Google experience doesn't match that of the typcial customer -- Koley took the Juniper job with a sharpened vision, ready to fill the gaps between today's networks and the multicloud future that enterprises want.

Figure 1:

Here's what we covered:

  • Page 2: What's Missing in Automation

  • Page 3: Contrail-as-Platform

  • Page 4: Disaggregating Juniper: P4 and SDn

CM: When you left Google, was there a reverse culture shock? Did you have to re-adjust to the real world?

Koley: The good news for me is that I did work in the "real world" for a long time before I joined Google. I was at Ciena for four-plus years, and then I did a startup for four-plus years.

But there are things that are different. One way of looking at my job at Google -- I was there ten years, and I joined right when YouTube was getting absorbed into Google infrastructure. Pre-YouTube and post-YouTube are very different networks in scale and capacity. It was a huge amount of work. The whole CDN infrastructure that we had to build and the whole edge that we had to build, to a very large extent, was driven by Google. Of course, every single application used it.

But the way I always viewed my life at Google is: We had to invent a bunch of things because they did not exist. There was no scale-out architecture in data center; everybody was doing the standard two-tier design. There was no lean core. The whole idea of SDN was not called "SDN" when we started doing it.

In most cases, there wasn't an option to buy, so we built it.

CM: I think a lot of people mistook that for "Google wants to do this for fun."

Koley: Absolutely. If I had to do it again, there are many things I built that I would not build. I'll give you an example. The last SDN project that we worked on was Espresso. Espresso did not try to build the hardware in-house at all. It was standard hardware with some APIs and programmability.

Over 10 years, the industry changed to a point where you can expect programmability on the hardware. Look at the Facebook Open/R announcement, where Open/R runs natively on Junos. They didn't need to go build the hardware. So, it was almost never by choice. It was by necessity.

CM: So let's talk a little bit about how you came to Juniper.

Koley: I still spent quite a lot of time, as Google was getting into cloud, with customers who were trying to get into cloud. One of the things that became pretty obvious was that every Fortune 500 company has a plan to migrate to multicloud, but honestly, they don't know how to do it, not because they're not smart people but because they haven't built this technology. They're very smart people, but it just takes time to build technology.

I did not think this was a problem any of the public cloud companies were going to solve. The reason being: They're not the same. Google's infrastructure is very different from Amazon's.

CM: And they have no incentive! It would be a lot of work.

Koley: Exactly. So, I viewed that as a real problem that the industry needs a solution for. It's a real-world problem and a very large-scale problem. It needs some of the same expertise I had to employ at Google to solve it, but the problem statement is very different.

The thing that hyperscalers do well is: Software-driven control, or software-driven network or security automation, is never an afterthought, right? You never build an infrastructure where your assumption is that a human is going to drive it. It's going to be software that drives it. It's a core principle.

If you look outside, at software automation -- and frankly, I really don't like the term "automation" because it talks about a sliver of the problem; it's not the whole stack -- people are not solving automation the right way.

People are solving automation as a glue layer on top of something they've built, and when they built those elements, they did not build them thinking of automation. They built them for something else, and now they're trying to put a glue layer on top.

One thing I believe very strongly in: At Google, they never treated overlay and underlay separately. It's a seamless choice between where some part of the function runs on a server and some part of the function runs on a switch. It's part of the same system. It's the same controller, the same management domain, where some of the functions happen to be virtual and some of the functions happen to be physical.

CM: Which makes sense, but -- you thought of it that way because you weren't in the business of selling the underlay. Google doesn't sell routers.

Koley: Absolutely. And this is the other thing I felt strongly about: The networking industry is not solving it the right way. Yes, people have overlay and they have underlay, but you cannot make them two different things. How are you going to troubleshoot, if they're two ships in the night?

So, I looked around the industry. I looked at the most programmable underlays. Looked at: Who has an overlay that has a chance of scaling? And something that actually has the right policy language -- the abilities to apply security and microsegmentation.

It's a very short list. You start removing players very quickly, once you look at it that way.

This opportunity was sort of the obvious place to come and solve that problem. It was the right timing, and of course I have known Juniper for a long time, as a customer. Of course, I knew the challenges and the opportunities of the company. It has been a really busy, interesting, fun first three months.

CM: What are you spending your time on?

Koley: First, there are three units which have GMs that report up to me: Contrail, Appformix and Aurillon. So I run them as a business. It's a slightly unusual CTO job, but one very attractive part of this job for me, because it allows me to have direct influence on execution. It's not just strategy.

The second part is the technology strategy for the company, and not at the level where you're writing fuzzy, high-level strategy. It's really: How are our next products lining up with the strategy? One of the big strategies for me is that Juniper has done phenomenally well having Junos as the common software for the [network] elements. I want to do the same thing for the applications that we build.

It's a platform. So, how do you build a real PaaS [platform-as-a-service]? This is another thing I've learned from my past life: That one of the reasons that Google has been able to innovate so quickly is because everything runs on a common PaaS. So, if Search does something that improves the PaaS, maybe because they need the performance, Maps benefits. Or Cloud benefits.

This is, by the way, a very common mistake in the networking space. If you look at Juniper's peers, almost nobody has a PaaS. I do one thing for data center, something else for core, something else for cloud.

CM: And sometimes they pit them against each other.

Koley: Yes, and the way of doing "simplicity" is to build a glue layer on top.

So I'm laser-focused on building this PaaS for Juniper, and of course, I have the advantage of having Contrail and Appformix. These were pretty mature PaaSs.

CM: OK. So you're not starting purely from scratch on building this platform.

Koley: It would have taken years if we'd started from scratch. These were very mature PaaSs; they were just missing functions.

For example, Contrail had very strong overlay, as you know, but did not have as strong an underlay support. But at Juniper, there are very strong element management systems that are built. Bring those pieces into part of this PaaS, use the common policy language -- you know my background with OpenConfig.

So, I spent a lot of time on that. Spent a lot of time on the operating system evolution that's happening: How do we get Junos more disaggregated, where you get the ability to program the operating system in the layer that you care about? Which actually, again, is a different approach from what most of our peers are taking.

CM: I'm not familiar with your disaggregation plan.

Koley: Let me walk you through it. As you know, I'm a very strong believer in open programming interfaces. But different users have different capabilities of programming.

Some users, like enterprise, for example -- they would much rather have some orchestration system like Contrail go and program their fabric. For those, the interface that they care about in the switches and routers is mostly in the management plane. You want the ability to go configure, the ability to go do software upgrades, to possibly remote-boot -- things like that. That's one level of programming interface, and Juniper has very strong interfaces there.

The second layer is where you actually can run complex applications. You don't want to completely program the hardware underneath, but you possibly want to program part of the control plane. This is the Facebook Open/R use case. It's where I have a centralized controller, I'm not interested in programming the FIB [forwarding information base] or the forwarding silicon. I'm interested in programming the RIB [routing information base] or the overall control plane. How do I expose the ability to program my control plane either by exposing the APIs or by giving people the ability to run third-party agents on the Linux kernel?

The third is possibly the most evolved application of SDN, where someone wants to go and program the chips. If you have seen the Juniper paper from Google, that has been Google's approach, that you use something like OpenFlow to really go and open the FIB.

There are a couple of things we are doing there. One is, we are building a common abstraction for the hardware layer, be it a Juniper custom ASIC or merchant silicon or x86. We call this layer AFI -- abstracted forwarding interface. It's actually in the open-source domain.

But we are also building native P4 support. We are very active in P4; that's something I'm personally involved in driving. We'll have common P4 support across the Juniper switch and routing stack, irrespective of whether it's on Juniper silicon or merchant silicon.

In many ways, when the industry talks about "white box," they're not so much talking about merchant silicon even though that's what it gets translated to. They're talking about: Do I get the ability to program the hardware if I need to, in whichever way I want?

So, I am enabling that ability on both merchant- and custom ASIC-based boxes Juniper is building. A lot of my time is spent there, in actually assuring we get disaggregation across the board.

CM: What does all this mean in Juniper terms? For somebody looking from the inside, seeing Bikash walk in, what changes do you need to make?

Koley: Engineering has always been in the DNA of the company. It's simplicity. For most networking companies, simplicity hasn't been front-and-center in the products we have built. It's the nature of this space.

CM: As I learned when I first started covering networking.

Koley: Networking has been about exposing as much complexity as you can to the users -- because many of the users actually asked for it. So, it's as much technology as it is cultural, and they're hearing a lot from me about why simplicity is important, how it needs to be part of your product strategy, how it needs to be part of every technology that we're building.

You see people's eyes lighting up when they walk through the reasoning of why simplicity is important. They want to do the right thing. It's more about how you make that part of the technology life cycle.

It's a lot of drinking from the firehose, but there is a solid strategy, and Rami is very excited about that strategy.

CM: As you've talked with customers, I know hybrid cloud has been a common theme. What else? Any surprises?

Koley: One is how much legacy people still carry in their infrastructure. There are many customers where they're still running release 12.X. And in many cases, they want porting of all the new functions to 12.X.

CM: [Laughter, because Junos' latest release is 17.4.]

Koley: I can understand the logic. If you have a network that works, and it's reliable, why touch it? Obviously both for them and for Juniper or our peers, that makes it so much harder to move them to the simpler world. That actually has been interesting. Where I spent the last 10 years, and the peers in that space, three to five years is the technology refresh life cycle. You hardly have anything that is older than five years. So, that part is definitely new to me.

CM: Yeah. All the stuff I wrote about, back to the 90s -- Sonet -- that's all still in there.

Koley: [Grinning.] They still have Class 5 switches, right?

— Craig Matsumoto, Editor-in-Chief, Light Reading

About the Author(s)

Craig Matsumoto

Editor-in-Chief, Light Reading

Yes, THAT Craig Matsumoto – who used to be at Light Reading from 2002 until 2013 and then went away and did other stuff and now HE'S BACK! As Editor-in-Chief. Go Craig!!

Subscribe and receive the latest news from the industry.
Join 62,000+ members. Yes it's completely free.

You May Also Like