(intense orchestral music) >> Hi, I'm Peter Burris, and welcome to another CUBE Conversation from our studios in Palo Alto, California. We've got a great CUBE Conversation. One I've been looking forward to for quite some time, with me is Bikash Koley, who is the CTO of Juniper Networks. Bikash, welcome to theCUBE. >> Thank you very much, Peter, really excited to be here. >> Well, the reason I'm excited about it Bikash, cause you've been at the vanguard of thinking about the role of cloud in business for quite some time. Why? Where've you come from? >> Yeah, so I have been the CTO at Juniper Networks for exactly about a year now. Spent a decade before that at Google. I used to operate Google's production network and boy, it has been a journey. >> Oh, I'm sure. >> I joined Google the year after Google acquired YouTube, when it was a tiny little video service company, search was growing. The way I describe my experience at Google is I saw necessity as the mother of invention like in front of me, because a lot of what we had to build there we had to build out of necessity because we're scaling at a pace, or scaling to an extent globally, that hasn't happened before. And if you really think of what is the core of that scaling? It was almost always data. Whether it was indexing the whole internet which was growing, it was doubling every year at the time. Or, whether it was this little video service called YouTube, which was growing at a crazy pace. The core to it was how do you manage this volume of data both ingestion processing and distribution? And the core to that was always network. The interesting part was a lot of the technologies that are used for really both consuming and distributing data today, did not exist in those days. >> Well from the outside, one of the things that's fascinating about Google is it always looked like what it was doing with technology made sense, and so it might've been a degree of chaos and emergence, which is kind of what the necessity of invention kind of ends up looking like. >> Yes. >> But your contributions to opensource, your diffusion of knowledge about what you were doing was so advanced and so different that it became kind of the beacon, kind of the lighthouse for thinking what the future of cloud was. >> Yes. >> Now I'm going to make an assertion here, and here's my assertion: That in many respects cloud really is the programming model for networks. >> Yes. >> Would you agree with that? And then I'm going to ask you about how you're going to transfer all this knowledge into Juniper to help other customers? So starting with that notion, is cloud really the programming model for networks? >> It actually is the programming model for any data and application, and network is a key part of that. Out of the description that I've used often is there're three characteristics that if you omit in an infrastructure that is around either IT or applications, then I call it a cloud. It is ubiquitous, it is reliable, and it is fungible, right? And if you think about it, it's the same three characteristics that you find in all the utilities that you rely on day in and day out. You find that in electric grid, you find that in water. I have a term for it, I call it invisible infrastructure. >> Well hold on, when you say fungible then, just to make sure, >> Yes? >> You're saying that fungible in the sense that the service that you're using is the service that you're paying for. >> That is correct. >> Okay. >> And you can get to use the resource for the service that you need. >> Got it. >> And not pre-build everything on day one, right? Very similar to what we do with electricity. >> So ubiquitous, resilient, fungible. >> That's correct. Now, if you look at how you get ubiquity and resiliency and fungibility, you'll find that it's network that gives you all of that. Ubiquitous because you have a global network, it's fungible because you build this fabric whether inside of data center or connecting your data centers that allows to move resource as they're necessary, right? >> And track your utilization of resource. >> And track utilization, give you security, right? And reliable because every time you build a data center, or every time you build an edge connectivity, you are ultimately giving people or applications multiple ways to access where they're going, right? So network is absolutely key to how something becomes cloud, and I mention that because cloud is almost always used as a term for public cloud. I actually believe, like you said, cloud is a programming model, cloud is an application consumption model, and it's not just about public cloud. It is absolutely applicable to infrastructure that you build on-prem, as long as you're meeting those criteria. >> So we like to say that the notion that you're going to move all your data to the cloud which is kind of the popular concept. >> Yes. >> Is not necessarily, I don't want to say it's wrong, but it's not right. >> Yes. >> That the real way of thinking about it is you're going to move the cloud to where your data's located, and data has very real characteristics, latency, cost, et cetera. >> Absolutely. >> So if we start from that proposition it suggests that it's not like all the networking problems are going to be suddenly the public cloud providers' issues. Every enterprise still has to conceive of how they're going to define their network, because they've got installed machines that aren't going to go away any time soon, they've got new applications that they want to build on data that must remain private, >> Yep. >> Or has local attributes that have to be instantiated. So it means that the notion of networking inside the enterprise remains important. How are you going to help Juniper take that knowledge that you've gained about building great cloud networks, and bring it into an enterprise so that they can take advantage of everything that they need to take advantage of with their networks? >> Yeah, Peter, you're exactly correct. It's that cloud is going to follow data, because ultimately data has gravity, and it's gravity in the form of the cost of moving it, whether the law of the land allows you to move it, whether the physics of it, the latency that you need to the data allows you to be away from where users are, and there's some things that don't change. Your users are where they are. They're not necessarily going to come close to-- >> And those users are not necessarily people. >> They aren't necessarily people. >> Increasingly there are devices and other types of things. >> Absolutely. >> That must be where they are because they're preforming an act that must be performed right there. >> Water meter readers are in water meters, and utility pole readers are utility poles, right? So they need to be what they are. So you're absolutely correct is that cloud has to come to the data, not the other way around, and network has a huge role to play. Going back to what lessons I learned, and am bringing with me, to Juniper, but more importantly to networking for the cloud era. First of all, every infrastructure has a context and it solves a certain problem. So it is a mistake to try and solve every problem the same way. So one of the questions that I get asked all the time as I talk to the CIOs of the Fortune 500 companies is "I'm not that interested in what my peer is building. Tell me how I build a Google or an Amazon or a Microsoft-like infrastructure." And my answer to them always is it's a question of what problem you're solving. >> Mm-hmm. >> Now when they say, I want to build a Google or a Microsoft or an Amazon-like infrastructure I believe they're actually asking for a few properties, not necessarily building it the same way. You actually can't build it the same way because it's always people, process, technology and more than likely an enterprise doesn't have the same software engineers or the same operations folks that a Google or a Microsoft or an Amazon or others like that, Facebook, have, right? So what are the properties? The properties are very applicable to enterprise. First of all, when you're building for scale you cannot treat your infrastructure as pet. You cannot go and configure every single element individually, you have to treat it as cattle. So when you are building a network you are building the network, not the elements in the network, right? And that is the concept of what is now called software defined networking, right? Where an intent driven software model drives what your network does. You cannot scale it out in any other way. >> Mm-hmm. >> Two, when you're building for scale, things will fail because that's the law of probability. If you have 10 times more switches, you're going to have 10 times more the number of failures. It's the nature of the beast, right? What makes your system reliable is the software because the software understands when failure is happening and it does something about that without waiting for a human to go and react, right? You must have software or automation that allows you to scale in that way. Third, you really cannot start separating between what is physical networking and what is virtual networking because if you think of the world that we're going in to, as you pointed out, most enterprises have lots of legacy infrastructure not because they love it but because their business relies on it, right? >> Mm-hmm. >> You still have things that are on bare metal, it's not that you tomorrow decide I'm going to run everything on serverless on Amazon and I'm able to do it. You can't, even though you might want to, right? So it is important to build an infrastructure that respects the legacy and allows you to still build automation and software abstraction-- >> But it's even more than respects legacy. That allows you to generate new options on the value of that legacy. >> Absolutely. >> So that legacy can sustain and increase in value. >> Yes. >> As you add new elements, have I got that right? >> Absolutely correct. It is where, you know, if we use an example you might actually have a database that runs on a traditional NAS database server. You might be building applications that are running on public cloud that needs to access that database because you have all of your customer data there, right? So a key here is build an infrastructure where that set of bare metal servers that might be connecting to a switch or a firewall, gets to talk to a public cloud endpoint that might be running virtual network, right? And that's the power, in my mind, of overlay and really combining overlay and underlay together. These are the ways that public cloud infrastructures have been built. If you look inside an Amazon or a Google or a Microsoft or Facebook, you will see these qualities, right? Where virtual and physical have been blended. Software is used for operation, including automation. Reliability's the key driver as to why you put software and let's not forget the importance of having operators that are comfortable with operating a software stack, not so much a collection of switches and routers, right? Those are really the learning that I believe are very applicable for any enterprise that are building or any service provider that are building large infrastructure. >> That suggests that ultimately, the business has to look at the primary citizen of the network differently? >> Yes. >> The primary citizen used to be the server or the device, or you know, the switch or whatever else, the router? >> Yes, of course. >> We have to move beyond that as these are the assets we're trying to take care of and start thinking in terms of where the data is. A concept that I like to use with clients is this notion of building networks of data. >> Yes. >> And having a software defined infrastructure that's capable of configuring those networks rapidly where the asset that we're worried about is the data, and not the switches. Would you agree with that? >> I would completely agree with you and the key word, Peter, that you mentioned is rapidly. The need of the day is, you know, the days of having more or less static network is gone and what I mean by that is, yes every network is in some ways dynamic, it does stuff in there. >> Sure. >> But in most networks the endpoints have been static. You have this many servers, you have this many pops, you have this many data centers, right? The world that we're in is where, and this is what I meant by fungible when I said it's fungible, right? That my endpoint which was a VM on my data center today or say 'til noon, might become a VM on an AWS or a GCP or a zero instance in the afternoon because that's the most cost effective way for me to run that application. >> Mm-hmm. >> And what enables that is actually network and ultimately if you sort of look at why the concept of Kubernetes has become so popular? Because Kubernetes has tried to do the same thing for compute. It allows you to move compute in a very fungible way, irrespective of where the endpoint is. What my vision of networking really is, is an equivalent for network where network allows you to fungibly move applications and users as needed, on demand, and very rapidly, right? I'm coming back to the key word that you used there. >> I want to build on that, because I think it's a very important concept. When we talk about static endpoints, look the performance of every network goes back to Claude Shannon. The performance of every network is a function of the degree of certainty you have and the various parts and elements of the network. Static at one end, static at another end means you can build a really, really high performance networks at either end. Uncertain in between means you end up with very, very slow wide area networks. >> Yes. >> Software defined, however, allows us to bring more information into that equation so we have better visibility into the patterns, better visibility into the traffic, into the routes so that we can bolster the entire performance of the entire network, have I got that right? >> You got it exactly right. I would go one step further. So there are two camps in networking and I think both are wrong. One camp is it's going to remain in physical network because they are most performant and they give you reliability. The other camp is you don't need physical network, everything is an overlay and I think both are wrong for the following reason; the best distributed systems are built in a way where you apply the right resource that is most cost effective for what you're doing. >> Sure. >> There are resources that are static. You data center, your number of data centers don't change that rapidly. Where you connect to internet providers or other carriers, they don't change rapidly, right? So the best way of building that, is by building physical network with physical routers that does physical packet processing or physical optical gear and so on because that's the most cost effective way of moving bits, data, right? >> Right. And the number of options that you have to worry about in the future is limited. >> Absolutely, exactly, right? But when you are trying to go and tie up endpoints where the endpoints go up and down on demand? A physical network cannot do it. It is just not possible for you to run around the data center and add switches because you decided to have 10% more load on a certain cluster, right? So it has to be virtual. But the key here is that you really cannot have physical and virtual looked at independently because then they're ships in the night. >> That's exactly what I mean, and so the whole notion is to uplift the entire-- >> Yes. >> Software defined can allow us to uplift the performance of the entire thing. >> Yes. >> Because it is an end to end problem. >> Yes. >> And optimize performance at one end point, optimize performance at another end point but not have to pay the performance penalty because we don't have visibility to know what's happening in between. >> That is correct. And use, whether it's a physical network that is forwarding your packets or it's a virtual network that's forwarding your packet, that should really be best run intent. >> Right. >> It should be best all in all. Same thing where I'm doing overlay on a switch. Let's say I'm doing a VX line overlay on a switch in a physical data center? Can be applied to a virtual instance that I'm running on AWS using the same VX line abstraction but now it's not a physical switch anymore, it's a function that I'm offering, right? >> Right. >> And that's key. >> So CIOs have to, they're not trying to build the new AWS, they're trying to take advantage of this notion of scale computing, any service, any data, anywhere, any time, anybody in the context of their business? >> Yes. >> How are you, with Juniper, taking a lot of these concepts which are still, need to be diffused in the industry, and turning that into offers, engagement, new ways of doing things that allow these CIOs to start to envision >> Yes. >> How these principles get applied concretely, discretely, cost effectively to their business? >> Yeah, you know, I was fortunate in having the ability to run a very large cloud network for a long time. >> That would be Google. >> That would be Google, yes. I spent a lot of time with, Juniper's CIO because Juniper runs a pretty large IT, right? One of the things that I hear from him is something that I hear with every single CIO conversation that I have. People have gone into cloud, public cloud, with the expectation of saving money. For most companies, public cloud consumption has been through a shadow IT where some team decided my application just seems to run better in AWS. Same thing with Juniper, by the way. And I'm just going to run it there and when the CIOs start looking at the collective bill that comes from all this cloud consumption, what they realize is that it's actually not a decrease in op ex, it's an increase in op ex because instead of running one infrastructure, you're now running two or three or four. There is also a myth that there is one public cloud. There isn't one public cloud. There is no standard that defines what a public cloud is, and so depending on who you're using, you are really building both expertise on your team as well as applications that are specific to that infrastructure, right? >> And worse, there are economic powers at play that are likely to avoid coming up with that one standard. >> Absolutely, right? End of the day, if I'm a CIO, what I really want is I have the ability to chose between the options that I have that is most economical for me, but it meets my SLA, right? That's what I'm looking for, right? What I want is one cloud but not in the way one cloud is described, it's not one cloud from one provider. It's a cloud infrastructure that looks like one cloud to me so I can use it fungibly, right? That, I believe, is the most critical problem in IT, in the last two decades. >> And isn't it interesting that people continue to think about the idea of virtualizing things in the cloud is at bottom, predicated on the notion of virtualizing, but we still look at the cloud almost as a physical thing? >> Yeah. >> And what you're really describing is no, you need to take that notion, that concept, of virtualizing and extend it to your cloud utilization as well. >> Absolutely. >> And it's the network that's going to make that real. >> Absolutely, and so what we have been building in Juniper, there are some pretty interesting asset that Juniper had much before I joined Juniper. Juniper acquired a company called Contrail before. Juniper has invested a lot of energy in taking all the routing and the firewall stack and completely virtualizing it so that you can take an SRX firewall and you can run it on AWS, the same way it would run on a data center. Or take RMX router and run it as VMX as a gateway for cloud. And then Contrail, which originated in really telco NFV has one of the most performant SDN stack that is out there. What we did is we took this asset and we're really delivering on the promise of physical and virtual are the same. So Contrail has been expanded to support, obviously the virtual network which is the SDN that it does but it now incorporates physical switches and router from Juniper and from our competition. And the second part is important because if I'm a CIO, I don't want to run a cloud that is Juniper cloud, and a cloud that is somebody else's switches and routers. It's fundamentally different philosophy from what many of our competition does and we believe very strongly, I believe very strongly, in the philosophy that if you're really going to take a legacy infrastructure and move it forward to what is truly cloud, you got to bring the legacy with you. >> Mm-hmm. >> And if that legacy is not Juniper, it still needs to be supported in the virtualization that we're talking about, right? We are heavily investing into integrating not only the capability that we build for open stack which was VM based and physical servers extending to VMware on one side but also building the most performant Kubernetes networking that is out there. I can tell you that we probably have the most performant Kubernetes networking that you not only can run on prem, which we do with our partnership with Red Hat, but you can also extend the same Kubernetes implementation to all the major public clouds. And what that allows you to do, is all of a sudden you have a network that spans physical and virtual. You have the ability to extend the same overlay from your one prem data center to any of the public cloud ones that you care about. You are able to speed up workload, whether they're VM or whether they're micro services and use the power of open stack on Kubernetes to move it around fungibly in where you need. But the most important bit in all of that is if you're a CIO, what we are most concerned about when you go to public cloud is security because when you ran everything in your data center, you have a pretty good idea of where things reside. Whether you have done perimeter security or whether you have done zero transfer, a combination, you know what you have. When you're going into an API based model or serverless or you're turning on VMs on public cloud, the concept of localization goes away. So what we're really delivering is network, not only gives you connectivity, it gives you secure connectivity. So we actually have built extensive distributed firewall in our Contrail product and leveraging SRX so irrespective of where you're running your workload, you get the same policy, you get the same security implementation, you get the same visibility, right? >> And very importantly, because certainly the public cloud suppliers have a lot of security. >> Sure. >> So you can have security here, and you can have security there and you're right, you don't have the same visibility into their security but even if you had the same visibility, you still have to connect the two together. >> Absolutely. >> And its the end to end that you're worried about. It's the security in flight? >> Yes, absolutely. And it's the same concept of there isn't one cloud, right? When you describe the same thing-- >> The cloud's defined by the workload. >> Exactly, right? Ultimately your security need to be in description of what the workloads can do. >> Right. >> Not what API I go-- >> And where it needs to do it. >> Absolutely, yes. >> Alright, so this has been a great conversation. I'll give you one last opportunity to kind of say, okay so, where's this end up in three years? You're a CTO, you got to worry about this. Help a CIO understand, let's not say three years, let's say five years, a little bit longer. How is what they're doing right now going to make life better in five years? Give 'em where the new classes of services are coming from, et cetera. >> Yeah. >> What do you think? >> I believe it's a journey and it's important to acknowledge that it's a journey. Different CIOs are in different places of this transformation. I believe in five years, you are going to see a world that is multi cloud, where every CIO is consuming more than one public cloud but they're also operating private cloud in true sense, in the definition that I use. And for CIOs every investment that they make now is going to determine whether they end up in a cul-de-sac where they're stuck with what they know how to operate today or whether they're taking the steps towards the endpoint which is a multi cloud that they can operate in a lot more fungible way. That's the product that we're building. Our goal is to be there when you're ready to take the step and one of the beautiful thing of the Juniper product family is that you are actually not committing to just buying Juniper products because it is multi vendor from day one, it's multi cloud from day one. It also doesn't lock you into just building things on prem, you actually have the ability to go on prem and off prem so use that flexibility and make decisions, build decisions so that it gets you closer to end goal that you have, not where you are comfortable today. >> Well Juniper, by virtue of the situation that Juniper's always been in, has always been a company that focused on connecting, integrating and co-habitating. >> Yes. >> With other technology. >> Yes. >> And it sounds like that remains a core feature of your DNA. >> That is absolutely core. >> Bikash Koley, CTO of Juniper. Thanks once again for being on theCUBE. >> Thank you very much, Peter. >> And once again, I want to thank all our audience for participating in this great conversation. Until we have another opportunity to have a CUBE Conversation, thank you very much. (intense orchestral music)

>> Announcer: Live, from Vancouver, Canada it's the CUBE, covering OpenStack Summit North America 2018, brought to you by Red Hat, the Open Stack Foundation, and it's ecosystem partners. >> Welcome back, I'm Stu Miniman and my cohost John Troyer and you're watching the CUBE, the worldwide leader in tech coverage. Happy to welcome back to the program long time friend of the CUBE back from the earliest days, Randy Bias, Vice President with Juniper, Randy, great to see you. >> Absolutely, great to be back with you guys. >> All right, so Randy, we've been talking about, you know, community, and everything's going good and attendance might be down a little bit but how we fit in with containers and kubernetes, and everything, so we expect you to tear everything up for us and tell us the reality of what's happening in this community. >> I'll do my best (laughing). >> All right, so before we get to the kubernetic stuff, you're working on, we used to call it OpenContrail? Which you were involved in before Juniper acquired it, went through a rebranding recently, Tungsten, which I was looking up, came from the word heavy stone, give us the update from the networking side. >> Yeah, so the short history is that there was a company called Contrail, and they created a software defined networking controller, it was acquired by Juniper in 2012, 2013, and then that was open sourced, so Juniper for a long time was running with sort of two editions, Contrail which was the commercial offering, and OpenContrail which was the open source, and then shortly after I joined Juniper, identified that, you know, we really needed to go back to the drawing board on the way that we had organized the community, and transition it from being Juniper-led to community led, and so over the past year, I spearheaded that effort, and then that culminated in us announcing at the end of March at ONS that, you know, OpenContrail was now Tungsten Fabric. We renamed it, we moved it into the Linux foundation, under its governance, and now Juniper is one of many people of the community that have a seat at the table for the management, both from a business and technical perspective, and we're moving forward with a new reinvigorated community. >> Yeah, so networking sits at really the intersection of this multi-cloud world that we're living in. There's so many players trying to be there, you know Cisco, really moving to become more of a software company, when I interviewed their number two guy at their show, he's like, when you think of Cisco in the future, we're not even going to be a networking company, we'll be a software company. VMware, of course, pushed heavy through, then the Nicira acquisition, where does Tungsten fit, kind of compare and contrast for us, where it fits among some of these other offerings out there in the marketplace. >> Yeah, I mean, I think most enterprise vendors are in a similar transition from being a hardware to software companies. We're no different than any of the rest. I think we have a pretty significant advantage in that we have a lot of growth in the cloud sector, so a lot of the large public clouds are our customers and we're selling a tremendous amount of hardwaring to them, so I think we've got a lot longer runway. But, you know, we just recently hired CTO, Bikash Koley, out of Google, and we're starting to see some additional folks out of Google, like my new boss, Morgan, and what that's bringing with it is a very much a software first type perspective. So Bikash and Morgan really built everything for the Google network from the topper rack all the way out to the win and it's almost all software-based, disaggregated, hardware, software, opensource software running on top of white boxes, and so that kind of perspective is now really deep, start beginning to become embedded in Juniper. And at the head of that is Tungsten. So we see Tungsten Fabric as being sort of a tool that we use to create, you know, a global ubiquitous network fabric, that anybody can use anywhere, without talking to Juniper at all, without knowing that Juniper's part of Tungsten, and then as they grow up and they get to a point where they need multi-cloud, they need federation, or they need kind of day two enterprise operations, you know, we have a commercial version and a commercial distribution that they can use. >> Randy, we talked a little bit about OpenContrail and last year, at OpenStack Summit and moving it to a more of a community based governance model, and now that's happened with the Linux Foundation, can you talk a little bit about the role of opensource governance, and corporate governance, and then foundations, and just going forward, you know, what's an effective model for 2018 going forward, for a foundation-led project and maybe in the context of Tungsten Fabric, and how is that looking? >> Yeah, so again, OpenContrail's now Tungsten Fabrics, might be new for some of the viewers, lot of people still coming to terms with that. And so one of the things that we noticed is that, and when many people go and they say, hey, we want opensource first, the AT&T's of this world, part of what they're saying, one of the aspects of being opensource versus we want to be one of many around the table, we want to have a seat at the table, we want to have the option to contribute code back, and we want to feel like it's a group effort. And so that was a big factor, right? It was an opensource project, but it was largely the governance was carried by Juniper, all the testing infrastructure was Juniper, you know, all of the people who made architectural decisions were Juniper, all of the lead contributors were Juniper, and so, going to Linux Foundation was critical to us having a legal framework, for the trademarks, the code, the licenses, the contributor license agreements, are all owned and operated by the Linux Foundation and not by Juniper, so we basically have a trusted third party who can mediate all those things and create a structure, a governance small structure where Juniper has one seat at the table, and all the other community members do as well. So it was really key to getting, to moving to that model to increase people's interest in the project and to really go the next level. There just wasn't any way to do it without doing this. >> All right, so, Randy, let's talk about OpenStack. You were watching the keynote yesterday, you were, you know, in the Twitter stream, >> Randy: I don't usually watch keynotes, man. >> Stu: But you know this community, so-- >> I do know this community (laughing). >> Give us kind of the good, the bad, and the ugly from your standpoint as to, you know, where we've gone, you know, what's doing well, and what you're frustrated as heck that we still haven't fixed yet. >> Well, I mean, it's great that we have so much inroads amongst the carriers, it's great that, you know, that there's a segment that OpenStack has been able to land in. I mean, at some points when I was feeling particularly pessimistic on some days, I was like, oh man, this thing's never going to go anywhere, so that's great. On the other hand, you know, the promise that we had of sort of being the Linux operating center, operating system of the data center, and you know, really gaining inroads into private cloud and enterprise, that just hasn't materialized and I don't see a path to that. A lot of that has to do with history, I'm not sure how much of that I want to go into here, but I see those as being bright lights. I see the Ocata containers effort and sort of having this alternative structure that's more or less like the umbrella structure that I lobbied for while I was on the board. So for several years on the board, I said we need to really look more like the Apache Software Foundation, we need to look less like the Linux Operating System in terms of how we think about things. Not this big integrated monolithic release, you need more competition between projects and that just wasn't really embraced. And I think that that, in a way, that was one of several things that really kind of limited our ability to capture the market that we really wanted, which is the enterprise market. >> Yeah, well, I know, and one of those sticking points there that I've talked to you many times over the years about is how do I actually deploy this? You know, getting a base configuration and scaling this out, simplicity is tough, getting to those environments, you know, getting it up in two weeks, is good for some environments, but maybe not for others. >> Yeah, I mean I think there's sort of a spectrum, right? At one end of the spectrum, you say hey, I'm going to have a very opinionated approach like kubernetes does, and we're going to limit what we say we can do, you know, we're not all things to all people. And I think that opinionated approach, like the Linux operating system worked very, very well. And then other end of the spectrum is we've got no opinion like the Apache Software Foundation, and then it's up to vendors to go and cherry pick the pieces they want and turn that into some kind of commercial offering, whether it's Hortonworks, or Thi-dare or Du-per or whatever it is, the problem is that OpenStack wound up in the middle where it had the sort of integrated monolithic release cycle which it still does, which started to be all things to all people, and it was never as great as it could be, so it's like we got to support Hyper-V, we got to support VMware, and as the laundry list of all things we have to support grew longer, it became more and more difficult to have a compelling, easy to use, easy to scale offering that any enterprise could consume. >> Randy, a lot of talk this week about edge computing, with several different definitions, right? But it does strike me that, you know, there's a certain set of apps, that you write 'em and that they live fine in a big public cloud, and a big data center somewhere. But there's a lot of hardware that's going to be living out in the world, whether that's at the base of a radio tower, or in a wall, or in my shoe, that is going to be running hardware, and is going to be running something, and sometimes that something can be OpenStack, and we're seeing some examples of it, many examples of that already. Is that an area of growth for OpenStack? Is that an interesting part of how this fabric is going to expand? >> Well, I probably have a contrarian view here. So, I spent a bunch of time at Juniper, one of the things I worked on for a while was edge computing and we're still trying to decide what we want to do there and you know, kind of to the first point you made is everybody's edge is different, right? Is it on the mobile phone, is it back in the data center, the difference is that the real estate gets more expensive as you move out, right? And it's in terms of latency, and it's in terms of bandwidth and it's also in terms of cost of storage and compute. There's a move closer to the mobile device that becomes progressively more expensive, and so that's why a lot of people sort of look and say hey, wouldn't it be nice if we can get you out the closer lower latency and bandwidth and so on but as we looked at it, a lot of the different use cases it became really interesting in that, it wasn't clear if there was that much value between 5 milliseconds and 20 milliseconds, right? I mean, that's pretty, either one's pretty close, sure there's a lot of difference between 20 and a 100, but maybe not so much between 5 and 20. And so we kind of came to the conclusion that at least for right now, probably, the bulk of use cases are fine with 20 milliseconds, and what that means is that regional systems like AWS's Lambda at the Edge, they're in metro, those are probably good for most cases. I don't know that you need to be on the tower, I don't know that you need to be in the central office, so I think edge computing is still nascent, we don't know exactly what all those use cases are, but I think you might be able to service most of them from regional data centers, and then the question really becomes what does that stack need to be and if you have a regional data center that's got plenty of power, plenty of space, then it might be that OpenStack is a good solution, but if you're trying to scale down onto the tower, I got to have some doubts about whether OpenStack can really scale down that far. >> Randy, analytics is something we've been seeing, the networking people used for many years, at this show, starting to hear a lot of discussion about AI and ML, would love your view point as to what you're seeing in that space. >> You know I have some friends who started off in AI in very early days and he had a very pessimistic view. He said, you know this stuff comes and goes, but I'm actually very positive and optimistic about it because the way I look at this is there's a renaissance happening which is that, you know, now ML is really available to masses and you're seeing people do really interesting things like, we have a product called AppFormix, and what they do is they take ML and they apply it to operations and I love this because as an operations guy, you know, I used to have these problems in production where something would go out and the first thing I'd do, is I'm trying to do correlation and then root cause analysis, like, what was the actual failure? Like I can see the symptom on this end and now I have to get all the way back to what caused it, and the reality is that machine learning, AI techniques and protocols can do all the heavy lifting for operators very, very quickly and basically surface a problem for somebody to do the final analysis on. And so I do think that ML and AI apply to very specific vertical problems, it is just a place where we're going to see a tremendous amount of revolution in the next couple years. >> All right, and that hits right at really that intersection between kind of the developers and the operators there-- >> Absolutely. >> What are you seeing from an organizational standpoint, companies you're talking to these days, how are they doing adopting that change, dealing with that, you know, often schism or are they bringing those groups together? >> Well, I think you remember that like in the early days, I used bring my deck along and I would talk about assembly line IT versus the robotics spectrum all of IT and I would sort of make that sort of analogy to sort of the car manufacturing process, and I think what machine learning is really going to do is take us to that next level past that right? So we had the assembly line where we have all the specialists, we had the robotics factory where we had people who know how to build a robots and software, and it's really sort of like, just churning out with a lot of people on the line, and I think the next level after that is, you know, completely fully automated applications driving themselves, you know, self-driving applications, and I think that's when things get really interesting, and maybe we start to remove the traditional operator out of the equation and it really becomes about empowering developers with tools that are comfortable and that leverage all the cloud era and stuff that we built. >> All right, so Randy, you're credited with the pets versus cattle analogy, what's the latest, you were talking about some of the previous slide decks, what's Randy Bias looking on down the road? >> I mean, the stuff just comes to me, man. I can't like predict, but the thing I've been talking about a lot lately is services of platform, I think we might've talked about that last time, which is just this notion that if we look at where Amazon's invested and what's interesting, it's certainly not at the infrastructure layer and it's really not at the PAS layer, it's that thick layer in between with like database as a service and NoSQL as a service, and messaging service, and DNS and so on, where you can kind of cherry pick those things as you're assembling your own PAS for your application, and I still think that's the area that is under-discussed, and the reason is is the people back into basically doing that, building kind of the service as a platform system, but they're not like going into it, kind of like eyes wide open. >> Yeah, so just following up on that last piece, one of the criticisms I have this week is when you talk about multi-cloud, most of the people talk about, oh well people are clawing things back to their data centers. Juniper plays across the board, strong partnership with Amazon, yet you're here, what are you hearing from customers, you know, what do you see as kind of the balance there and, you know, the public cloud's role in the world? >> I mean, they're still winning, right? I don't think there's any doubt, I haven't seen a decline back here talking about, but we are starting to enter into the era of, okay, this stuff is out there, and it's running, but I need to find my governance model, I need to understand who's using what, I need to understand what it's costing me, and that's the sign of the maturation process. And so I think that, you know, we saw in the early days of cloud, people jumping the gun, creating compliance services, and you know, SAS products that would basically measure how much you're spending and think that it's time for that stuff to come back in vogue again, because the tool needs to be there for people to manage these extended supply chain of IT vendors which include the public cloud. And I think that the idea that would claw them back as opposed to like just see that as holistic part of what we're trying to accomplish doesn't make any sense. >> Well learned. Well, Randy Bias, always a pleasure to catch up with you. >> John. >> John Troyer, I'm Stu Miniman, getting towards the end of two days of three days of live coverage. Thanks for staying with the CUBE. (bubbly electronic music)