x
Cloud Strategies

CTO Bikash Koley & the New Juniper

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.

Previous Page
2 of 4
Next Page
Be the first to post a comment regarding this story.
HOME
Sign In
SEARCH
CLOSE
MORE
CLOSE