 from Seattle, Washington. It's theCUBE, covering KubeCon and CloudNativeCon North America 2018. Brought to you by Red Hat, the CloudNative Computing Foundation and its ecosystem partners. Hey, welcome back, everyone, live here in Seattle for KubeCon and CloudNativeCon. This is theCUBE's coverage. I'm John Furrier with Stu Miniman. We've got two great guests, Chris Wright, CTO of Red Hat, Scott Snedden, who's the Senior Director of Cloud at Juniper Networks, breaking down, winding down day one of three days of coverage here. Rise of Kubernetes, the ride of CloudNative is certainly impacting IT, open source communities and developers. Guys, thanks for coming on theCUBE. Appreciate it. Chris, good to see you again. Yeah, good to see you. Welcome to theCUBE. Okay, so talk about the relationship between Red Hat and Juniper. Why are we here? What are we talking about? Well, we're here to talk about a combined solution. So Red Hat's bringing kind of the software platform infrastructure piece and Juniper's bringing a networking component that ties it together. So we do have a fairly, well, in tech terms, a relatively long history working together. We've had a partnership for a little more than two years on some telco cloud initiatives around OpenStack using the Red Hat OpenStack platform with Juniper's Contrail solution as an SDN layer for these telco cloud deployments. And I've had a lot of success with that partnership. A lot of large and small to medium telcos around the world have deployed that. Earlier this year at the OpenStack Summit in Vancouver we announced an expanded partnership to start to address some enterprise use cases. And naturally, OpenShift is the lead technology that we wanted to tie in with around enterprise adoption of cloud and some alternatives to some of the legacy platforms that are out there. And we were talking earlier in theCUBE here, we always get to kind of the feel of the show. It's Kubernetes maturing, but it kind of two worlds colliding and working together, a systems kind of view, almost like operating systems, but network systems, all kinds of systems thinking, and then just apps, kind of the old app thing. So these are the old legacy worlds that we all lived in, kind of happening really in dynamic ways where the apps aren't thinking about what's below it. This is really kind of where you guys have a tailwind with Juniper, because you still got to make things dynamic, you still got latency on-premises not going away, you got IoT. So networking plays a really big thing as software starts figuring things out at Kubernetes. Let's talk about that. Where is that value? How is it expanding? Because clearly you still need to remove packets from A to B. Yeah. Be more efficient with it. Apps going to have policy. Well, yeah, I mean, you've still got to, the network has always been the foundation of technology, at least for the last 20 plus years. As cloud has been adopted, really, we've seen network scale drive in different ways. The mega scalers that have built infrastructure that we've been enabling for quite a while and have been working with those customers as well. We've been developing a lot of simplified architectures just for the physical plumbing to connect these things together. But what we've seen is more and more important is, it's all about the app. The app is the thing that's going to consume these things and the app developer doesn't necessarily want to worry about IP addresses and port numbers and firewall rules and things like that. So how can we just more simply abstract that? And so we've been developing automation aimed at the network for quite a while, but I think it's becoming more important that the application can just consume that without having to direct the automation at the app. And so groups like the Cloud Native Foundation and a lot of the work with Kubernetes around network policy lets us use Cloud Native Primitives and then we can translate into the network primitives that we need to deploy to move packets, IP addresses and subnets. Chris, talk about the multi-cloud dynamic here because again today, if things are moving around the standardization around some of those core value propositions, we just mentioned about networking and software networks, all kinds of software innovations under the covers. I'm a customer, I have multiple clouds now. This isn't going to be a core requirement. So you got to have a clean integration between it. There's really two things. If you look at a modern application, you got your traditional monolithic application as you tease it apart into components and services. There's only one thing that reconnects them and that's the network. And so ensuring that that's like as easy to use as an application developers focuses around the app and not around network engineering is fundamental to a single cluster. And then if you have multiple clusters and you're trying to take advantage of different specialties in different clouds or geo replication or things like this that also require the network to reconstitute those applications across the different multiple clouds. If you expect your application engineers to become experts in networking, you're just sort of setting everybody up with mis-set expectations. It slows things down, requires all these other tasks you got to do. I mean, it's like a rock fetch. You don't want to do it. Stack a bunch of rock moving from there to there. I mean, this is what the holy grail of this infrastructure as code really is. I mean, that's the goal. Help connect the dots for us. When you look at multi-cloud, networking obviously is a very critical component. What are your customers looking for? How does this solution go to market for your companies? Absolutely ease of use is top of the list. So it can't be overly complicated because we're already building complex systems. These are big distributed systems and you're adding multiple clusters and trying to connect them together. So ease of use is important. And then something that's dynamic and reflects the current application requirements I think is also really important so that you don't over utilize resources in a cloud to maintain sort of a static connection that isn't actually needed at that moment. I'm sure you probably haven't- Yeah, I mean, this is the whole concept of SDN and network virtualization and a lot of the buzzwords that have been around for a few years now is the ability to deliver on demand network services that are turned on when the application asks for it and are turned off when the application's done with it. We can create dynamic connections as applications scale and then with a lot of the newer things that we've been doing around control and with Red Hat are the ability to extend those application environments with networking and security into various cloud platforms. So, if it's running on top of an open stack environment or in a public cloud or some other bare metal infrastructure, we're going to make sure that the network and security primitives are in place when the application needs it and then get deep provisioned or pulled out when they go away. Being at a show like this, I don't think we need to talk too much about open source because it's really core and fundamental about what we're doing here. But I guess, how does that play into customers? We've been watching the slow change in the networking world. I'm a networking guy by background. I said, you used to measure changes in networks in decades. And now it feels like we're moving a tiny bit faster. So, yeah, what are we seeing? Well, I mean, the history of openness in networking was the IETF and the IEEE and standards bodies, right? How do we interact? We're going to have our little private playground and then we'll make sure at a protocol layer we can interact with each other and we call that openness. But the new openness is open source and transparency into the platform and the ability to contribute and participate. And so Juniper's shifted a lot of our focus. I mean, we still have our own silicone and the operating system we build on our routers and switches, but we've also taken the control platform, open sourced it a few years ago. It's now called the tungsten fabric project under the Linux foundation and we're active participants in a community and our customers really demand that. The telcos are driving towards an open source model. More and more enterprises want to be able to consume open source software with support, which is where we come in, but also be able to have an understanding of what's going on into the covers to participate if that's a possibility, but really driving interoperability through a different way than just a protocol interaction and a standards body. I can see how Kubernetes would be a great fit for you guys at Juniper, clearly out of the box. You have this kind of inter-cloud, inter-networking paradigm that you're used to, right? How does the relationship with Red Hat take it to the next level? What specifically are you guys partnering on? Where's that, what's that impact for customers? Can you just give a quick explanation, take a minute to explain the Juniper. A lot of it comes down to usability and ease of use, right? I mean, what Red Hat's done with OpenShift has developed a platform leveraging Kubernetes heavily to make Kubernetes easier to use with a great support model and a lot of tooling built on top of that to make that more easily deployable, more easy for developers to develop on top of. What we're doing with Contrail is providing a supported version of our open source project and then by tying these things together with some installation tools and packaging and most importantly a support model that lets a customer have the proverbial single throat to chill. The Red Hat customers, they can run beautifully on your environment. Yeah, yeah, and the installation process is seamless. It's a knob at install time to consume Contrail or some other networking stack and they can call Red Hat for support and they'll escalate to Juniper when appropriate and vice versa and we've got all those things in place. I think one of the things that we have shared vision on is the ease of use and then if you think about two separate systems with a plug-in, there's going to be some integration that needs to happen and we're looking at how much automation can we do to keep those integrations always functional so that if we need to do upgrades, we can do those together instead of abandoning one side or the other and I think another area where we have shared vision is the multi-cloud space where we really see the importance for our customer base to get applications deployed to the right location and that could be taking advantage of different pricing structures and different clouds or it could be hardware features or functionality especially as we get into edge computing and really creating a different view of computing fabric which isn't quite so client server, cloud centralized but much more distributed. I like how you said that Chris earlier about how you decompose that monolithic app it connects with the network. That's also the other way around. Little pieces can come together and work with the network and then form in real time whether it's an IoT data coming into the data center or pushing compute out to the edge. You've got to have that network interaction. This is a real cloud native evolution. This is the core. Yeah and I think another piece that we haven't touched on as much, Scott mentioned it was the security component. So, explain that. Again, as you decompose that application in the components, you surface those components with APIs, those were internal APIs when they're now exposed externally security really matters and having simple policy that describes not just the connectivity topology but who can speak to whom. It's pretty fundamentally important so that you maintain security posture and a risk profile that's acceptable. And then I think it's really important as your traditional enterprise starts to adopt these cloud native models. You've got a security team there that might not necessarily be up to speed or on board. So you've got to have tooling and visualization and analytics to be able to present to them that policies are being enforced correctly and are compliant and all of those things. Yeah, they're tough customers too. They're not going to expect really rock solid capability. They don't let you just deploy a big flat network with no policies. Yeah, surface areas exposed in the IoT space. Now you've got to nail it down. Yeah, absolutely. And so, I mean that's a lot of what we're bringing to the table here is a lot of Juniper's history around developing security products. Take a minute to explain. I want to give you a time to get a plug if a Juniper, I've been following you guys a long time, Juno's back in the old days, Contrail. Juniper's had a software, big time software view. Yeah. Explain the DNA of software at Juniper. You know, the early days of Juniper were, we weren't the first network vendor on the market. There was already somebody on the market in the mid 90s that had a pretty solid stronghold on carrier and enterprise networking. We had to come in with a better model, right? Let's make the box easier to use and simpler. Let's make the interface a little more structured and understandable. Let's make it programmable. I mean, the first feature request for Juno's was to have a CLI because the first interaction to it was just an API call. And that was out of the box from day one. We had to write a user interface to it just to fit into the existing network world in the mid 90s. And so, we've always been really proud of the Juno's operating system that runs on our boxes. We've really been proud that we've had this one Juno's concept of a common operating system on every network device that we've delivered as we've started to virtualize those network devices for NFV and things like that. It's, again, that same operating system that we deliver. Control came to us through acquisition so it's not Juno's in and of itself but still leveraging a lot of those same fundamentals around model driven configuration management, understandable APIs and openness that we've always had. That's not an operating model that everyone's going to. The common operating model fits in that unification vision that you guys have had. Yeah, absolutely. And really early, by the way, that was before SDN was SDN. I think that was SDN's kind of like. I like to try, I call it SDN. Right, I describe SDN as just a big distributed router and really we've had big distributed routers for a long time. Yeah, John, we are in Seattle. Everything we're talking about in tech is hipster. So. Chris, great stuff. Great to have you on, Scott. Good, great smart commentary. CTO, Red Hat, you guys are winning. Congratulations on the bets you made at Kubernetes early. CoreOS, great acquisition, great team there and some news there around some doing stuff back into the CNCF. So, I mean, you guys got a lot going on. A lot going on. And then I was with big news with the other things. I can't remember what it was. There was some big Red Hat news out there. Thanks for coming on. I appreciate it. Good to see you. All right, just breaking down day one coverage on John Furrier, Stu Miniman. Day two starts tomorrow. Three days of wall-to-wall coverage. You've gone there shutting down the hall. Be right back and see you tomorrow. Thanks for watching.