>> Announcer: From our studios in the heart of Silicon Valley, Palo Alto, California, this is a CUBE Conversation. >> Hello everyone, welcome to theCUBE Conversation here in Palo Alto, California, theCUBE Studios, I'm John Furrier, host of theCUBE, we're here with Reinhardt Quelle who's the principle engineer, Cloud Platforms and solutions Group at Cisco. Reinhardt, thanks for coming in, good to see you. >> Reinhardt: Thanks for having me. >> So, technical conversation around Cloud is something that we love having. We've seen the evolution over the past decade, Cloud 1.0, compute, storage, greenfield, cloud opportunities, great SaaS applications being built, you've built apps for over a decade, SaaS apps. >> That's right, I've been delivering applications, both to data centers and then of course, later into Cloud for a number of years. >> So you got some scar tissue. You have some successes, you've had some struggles, probably with on-prem, but the world's changed a lot and again, we've been covering this a couple years now. We saw public Cloud, all the benefits, no questions, great, you can lift and ship stuff up there, no problem, but the complexity's still there and now the trend is everything's shifting back to on-prem with Cloud. So now the hybrid model has been validated, Amazon Outpost, Anthos in Google, Azure Stack from Microsoft, clearly this mold, all the cloud vendors are telegraphing, they are doing it, this is a reality, this has been validated. >> Yeah, I think that's no surprise to those of us who've been deploying for a number of years. We've always had data centers where we're running our applications in data centers, and yes we started taking that into the Cloud, but there was always components of our infrastructure that continued to run on-prem, whether for historical reasons, for data gravity reasons, policy reasons, any number of reasons, but what we did learn was how to operate our applications differently and so for the last number of years, we've been moving a lot of the advantages of that Cloud back to on-prem. >> So I want to get your thoughts as principle engineer and look at the overall Cisco holistic portfolio of products because Cisco is a standard in the enterprise, every big company has Cisco gear at some level form of another. You've been dealing with networking for years, but now that networking becomes so much more acute issue because you still got to move packets around, another abstraction layer does networking, security, networking, all tie in to the growth area that is now this next generation of Cloud, Cloud 2.0, intelligent edge, data center on-prem, what's the Cisco story? Why Cisco, why now? What's the story? >> Well the amusing thing, of course, is the Cloud doesn't exist without networking. The very first thing when you set up an Amazon-- a compute in Amazon, you set up a virtual private network and you start deploying into that network, so it's always been true that networking is at the core of Cloud. And so the complexity that we're seeing over time is that the workloads are everywhere. The workloads aren't just in my data center and I'm not paying attention to data center networking or just cloud networking, it's connecting them together, securing them, making sure that they're fast and well managed. And so it's always been true that networking's at the core of this and as the edges get blurry, as we move workloads from one place to the other, all of the things that Cisco does are on managed networks, programmable networks, secure networks, all become even more important. >> And everything's amplified, too, in terms of its purpose. You're seeing automation is a big trend that's impacting the infrastructure and app developers. You've deployed SaaS apps within Cisco for over a decade, you've seen your share of successes and its issues but now as the data becomes critical, you got security perimeter issues are gone, and you got Surface here with industrial in IOT it's only getting more complex. So the complexity never went, but it's still complex these are the same problems. What's changed, what's the-- what's going on? >> Well so one of the things that's changed is that we've-- and this is something we can credit the Cloud providers for doing it is we've learned to treat our infrastructure in a different way. I mean the way we deploy and manage everything including networks compute, even applications. Operating the cloud demanded that we automate those things. Demanded the way, when you're managing now, fleets of thousands or tens of thousands of machines at scale in the cloud and when your call provider won't promise you that any machine won't go away at any moment you get good at replacing machines. And now we take those same tools, concepts, ways of operating that we did on the cloud and we apply them on print. Yeah, so a big part of what Cisco has been doing across our entire portfolio is ensuring that every piece of it from networking storage security is programmable and drivable through automation. >> You and I were talking before we came on camera and I wrote this down a phrase you like to use is, referring to Cisco, why Cisco is, We bring cloud innovation on-prem, what do you mean by that? >> Well really it's taking these new way of doing things, these new opportunities. Yeah, when we talk about-- we've had some funny conversations with our security guys, for example, we're historically in security we would have some policy, we would deploy applications against that policy once every six months or twelve months we would audit against that. Well one example of bringing the cloud innovation on-prem is the way you deploy that software, or deploy a new policy is via software. So auditing that is checking your code before you commit it, this says what it's going to do. Running reporting on the things that you've deployed so that you can see. So its taking these advantages of automation, and observability, and things like code review that are just normal practice in software development and apply them to infrastructure. And so, again, what Cisco is doing is making sure that all of our infrastructure can be-- can be programmed in that way, providing tools that allow us to program the things like Network Services Orchestrator or CloudCenter Suite that allow us to deploy applications or networks or whatever else as software entities . >> How about the reality of the person who's been innovating in the cloud and their reaction when they come back on prem they go, okay I've been doing this in the cloud and I turn around and I see all this. Is this the cloud innovation dynamic that you're referring to? Is it the realization that I had some innovation in the cloud, agility, automation and then trying to figure it out, or applying it, or both what's the reality when someone goes wow, I'm on-prem now, what's that innovation layer? >> Well there's several realities, depending on who you are and where you're coming from. One of my first roles at Cisco was, I was working on the Webex operation team and that-- the way we ran that operations was typical of the time it was built. And we did an acquisition that to accompany-- of a company that had been operating in Amazon and when they saw the way we that had to deploy and manage their application and infrastructure they were horrified. It's like, what do you mean I can't deploy a server in five minutes, what do you mean I can't manage the workflow in this way? So for them it was a shock and horror that they didn't have this infrastructure and that's when we deployed our first private cloud and Webex was to support that style of deployment. The flip side of that is the people who are operating those existing data centers with those existing workflows, their world changed, I mean they had to learn new ways of doing things, they had to learn new ways of managing their infrastructure, coding skills were a requirement not something that a few guys did, scripting in the background. So it was like, there's a lot of change to the people and to the way we did things but really it's a matter of bringing those, you know, bringing the cloud, bringing software development to operations, bringing software programmable to, hard programmability, to hardware. >> Yeah, I mean that's a great point. We cover that a lot on theCube, but I think one of the things you pointed out is the realization that, okay, great, new way of doing things, innovation. But as you kind of pointed out, there's a double edged sword there. The command and control of the network, which has been an old style tactic which doesn't go away, you still need to have control of certain things and on-premise, you certainly can control it on-premise, on cloud you think you control it through software, but this is the deep dive on tech conversation I want to have with you because we're talking about app deployment, Kubernetes management and the reality, I have my own gear on-site, as well as I'm maybe serverless into the cloud, this is the new reality. That you have to manage the controls. Take us through the-- those layers. App deployment, Kubernetes, and the reality of managing infrastructure on a future basis. >> Sure so, it's-- when we think about the application deployment it's very easy to kind of think about it in terms of the layers, and the programmable layers that you provide and I'll just touch--we won't go into detail on the products, but ultimately, today for an application-- someone deploying an application increasing that means push an application into Kubernetes, in other words I'm going to package my application's container, I'm going to hand it to Kubernetes through Kubernetes API and I'm going to expect Kubernetes to do the deployment and management of that. Okay, so that just makes the problem for the guy one layer below you, where's Kubernetes come from? It's like who deploys and manages Kubernetes? And so there's a number of different solutions and the public cloud you can use, you know, AKS, or Google's Kubernetes service, or Amazon's, any of these, but on-prem, where's it come from, who's going to manage it for you, who's going to create that? So Cisco's container platform is a product to deploy and manage Kubernetes to offload that from the developer, I mean, from the operations guy or the platform manager. Of course, that deployer of Kubernetes expects programmable infrastructure, how are you going to be able to deploy a VM or manage hardware that runs below that? >> Back to your innovation message. It's the innovation they want >> Well ultimately the guy wants the simple push the button and get the application deployed, that means someone has to get this layer deployed and well to get that layered deployed, what's there? So we continue to support virtualization managers, whether VMWare or our own cVim, Cisco Virtual Infrastructure Manager. All of these products its like, how do I manage this pool of hardware to provide that next layer of service? So, but in every case the programmability of the infrastructure or as far down as you can go becomes paramount, so, you know, when the guy racks a piece of hardware in the data center he doesn't want to think about how does this read card need to get configured, right? He just wants to rack it, plug it in, and then turn it over to software as quickly as possible. >> And that's the cloud innovation on-prem that you're referring to, that's making it cloud-like operations for Agility Automation, provisioning. >> Consistency, reliability, observability, give you an example of that, I mean when we, when we were talking originally when we were starting these cloud deployments and we had this conversation with Infosac about which application lives in which zone and how do you manage that? And we were like, well the zoning processes that's used in the past don't apply anymore. The way we manage that thing is with security groups, and the security groups are created this way. Here's the software, here's the software. When I'm talking software, I'm talking about configuration and scripts in this case, Ansible, Chef, Puppet whatever, that generate those security groups that generate those rules and it's like, it changes the way the security guy interacts with your team. It's no longer, file a ticket to review your app and app deployment and have a new ticket to do a deployment, it's something that they can do in real time. We're talking about moving these processes left, you know, moving that audit to the system all the way back into the software development stage and then giving the tools to verify that afterwards. And their eyes literally popped open, it was like, you mean at any moment at any time I can say show groups and see what the security posture is right now. And it's like, yes! An that's what sold them on letting us behave in this new way, was the ability to audit in realtime. >> Yeah, and this is a major advantage. This brings up the question that comes us all the time, and I want to get your thoughts on this because this shapes into the overall cloud architecture, cloud portfolio, and in this case with Cisco products is workload portability. It used to be, oh the one way trip to the cloud, not anymore, it's not a one way trip to the cloud, it's now bi-directionally on-premise, been validated by LPOST, Anthos, and Azure Stack, this is going to be an operating model to your point about the cloud innovation now workload portability, I think that's been validated so I think we recognize, the industry recognizes that it's not just public cloud everywhere, it's hybrid. This has been validated. You agree. >> Absolutely we-- there were many things that we never did move to the cloud, never would move to the cloud. Whether it's for policy reasons, or the quantity of data that we had, or systems that weren't available on the cloud, for example DevTest Labs, that have soundproof rooms, it's all audio equipment. We sell phones, we have to test those phones, those aren't ever going to be on the cloud, they're going to be in their soundproof rooms so we can test the audio pairing. There's stuff like that that always lives unrolled. There's a myriad of-- >> Compliance resources also requires-- >> Compliance things, whether its a FedRAMP compliance, this data has to be in this country, well US in that case, European privacy things. It could be-- I was talking to one bank a number of years ago now that worked-- we're deploying, we're talking about deploying Kubernetes from, it's like what applications are you deploying? Why do they need to be here, well, they're building-- they've got a mobile first application they want to use all the latest and greatest ways to build and deploy that application. But the data that that application is accessing is in the mainframe. It hasn't moved in ten years, twenty years, it's not going to move anytime soon. So you put the application next to the data that it needs. An IoT, it might be control devices, or video devices, or any number of things that's like, I think there's a trend overall, it's less about workload portability for a lot of people or being able to move workloads, it's saying, where's the best place for this particular workload to run, and so then provide the appropriate infrastructure to run that workload. And that's where we get back to saying, wait a minute I want to use containerization, I want to use orchestration systems, I want to use all these modern tools for doing this, but still put the workload where it needs to be. >> That is a profound statement, I want to just quickly unpack that a little bit because that really is the heart of the issue, cloud innovation. The workloads are going to be defining the requirements it needs, whether it's cloud selection or where it resides on-prem with what resources underneath it. That's not saying a company has to decide that because of that workload that the entire company has to use that 'cause the choices now because of the levels or granularity that cloud brings, the applications can get almost custom built or-- well not custom built but a specific hardware and compute to serve their needs. So if its a-- you're soul sourcing a set of resources for the workload. That's not saying that the infrastructure has to be that for everything, it's just the whole single cloud versus multi cloud dynamic. >> Yeah I mean, in fact, one of the things we're seeing more and more in our customers is, like, they don't have one cloud, they have multiple clouds, for multiple purposes. On-prem there's not one big private cloud that runs everything, there's lots of Kubernetes clusters and one of the things that a product like CCP does is allow you to deploy and manage multiple Kubernetes clusters for multiple purposes. Multiple problem domains, multiple political domains, financial domains, who's paying for this thing? Well, it's easy if you just buy the servers that are appropriate to your department and you run it. You still get to take advantage of all the way you deploy and package and run these applications, which is just hands down better than we ever did before. And that's some of the innovation we have. Now once you start doing this, once you start deploying these applications in multiple places, in multiple-- well, where are your security borders, where are your perimeters, how do you secure any of this, how do you connect all this stuff? How do you visualize all this stuff? And so, as you look at our products from, you know, we talked a little bit about the infrastructure pieces of that, you know the, Kubernetes deploying to an infrastructure manager, deploying ultimately to hardware, every layer of that. You know, UCS and CVIM and CCP, all of those layers are there and programmable. Okay, now we're deploying workloads, now I've got to connect the things together, how do I monitor it, how do I-- and so that's why you see products like Stealthwatch Cloud, and AppD, and the other applications to do monitoring and security across a now fully distributed application. >> You know, sometimes it's hard for me as a cube host to kind of get the story out about certain trends, especially when big players like Cisco, a lot of people know that I'm pretty bullish on Cisco, I've been very vocal about the Cisco opportunity with respect to cloud and critical, by the way in some areas and I think I would probably advise certain things to be certain ways. But one of the things, I think, is a great opportunity that you guys have, and you're kind of getting at, I want to just get your reaction and thoughts on this, is that what you're talking about here is an environment that's going to be constantly dynamic. That's constantly changing. And being complex is not going away, abstracting away the complexity is the game. But Cisco has always been successful in multi environments, different environments because networking has always been about diversity of networks. Campus this, and SD-- so it's not a new concept for Cisco to deal with this concept of multiple environments. Do you agree with that? What's your reaction to that? How would you answer that? Is that something you think Cisco's dominating in? Is that reason why Cisco is serving all these choices? What's your thoughts on that? >> I would have to say that overall the integrating lots of disparate things. Connecting lots of disparate things is in Cisco's DNA, I mean from our original routers and switches at the very beginning it was always multiple things connected to each other often multi-vendor working across standards and across standard things. When we talk about Kubernetes we're not talking about the Cisco Kubernetes we're talking about Kubernetes, the real thing, the actual Kubernetes, we're talking about-- and we're talking about ceiling, we're talking about openstack a standard, we're talking about-- so across all these boards connecting and integrating disparate things, is kind of what Cisco does. >> And so if you're deploying applications you've done that and certainly your customers are, they're never going to have one general purpose situations that's going to be scenarios, right? And certain things will be guiding principles, some will be governors that will then dictate things that might not be classic cloud native. Can you talk about that and give some examples why that's important and the reality of the statement. >> Yeah so, just use one example of an application, Webex teams our enterprise chat application, for example, that is your classic microservices modern cloud native application. There are three ways of deploying applications in that platform that are appropriate for the three different things. We got the services themselves, the media bridges, or the switching engines that runs these containers in a container orchestration fabric. There's the VM base things that are things like media bridges that don't run in containers very well, not because of the problem with the containers, but because of the overlay networks the containers bring with it and the way you route data to those. And we got physical machines. Now when we're actually running certain things on physical machines and so all of these exist in any kind of, even a brand new modern application so even within a single product family there's not one true way of doing things, what's the appropriate way to deploy this application. What's the right deployment target for this thing and how do I connect these things. >> You measure InfoSec so politics might be a driver that have nothing to do with technology, could be a human capital, resource issue, it could be something scalable. >> And the politics or even or can be even these temporal things, it's like, look I can spend, you know, three weeks trying to convince an InfoSec to do things in a particular way or it can just deploy somewhere where it makes them happy and move on, move on to the next problem and then later when they catch up with the way we're doing things, we may move it later. The other thing about timing on all this is the story is changing constantly when we deployed that application, we did not use Docker containers. And everybody says, why aren't you using Docker? Because Docker didn't exist three years ago! It's like the decisions we were making at that time are changing ever more rapidly. And the reality for our enterprise customers is that you don't just forklift one and then replace it with another one, you tend to manage them all in parallel even as you're making transitions, you know, eventually you kind of get rid of the old stuff, maybe, the mainframe still exists >> Mhmm. >> But in general for most of our enterprise customers it's not and or it's not on-prem or on the cloud, it's not containers or visible machines, its and, I'm running all of the above. >> And to your point about the docker not being around when you guys were doing that, that's going to be a concept that's going to be applied down the road, hey that wasn't around when we set the architecture, so as an enterprise, your customers that you talk to, what is the guiding principle? What is the preferred architecture? Again, a lot of choices you guys are trying to make your portfolio fit the bill. What are some of the decisions they have to make? So, to future-proof because they don't want to foreclose an opportunity and or create technical debt for that matter. Why would they do that? So they kind of have to be holistic in their thinking. >> Yeah, future proof is always-- is a funny concept because the reality is, that the... The way you do things will change. You didn't make something that was future proof, you built an environment that allowed you to do this way and that way. So if you take a look at the way we deployed, for example, our infrastructure in general we start with the UCS substrate, we can run Oracle on bare-metal on those things when we need to. We can run virtualization on top of that, and run a layer of vms on top of that. We can run containers, now I've got choices. Common substrate, common way of managing those things but at least three different ways of deploying on those. So ultimately we're looking for standard practices that enables me to have to do the and to where I can run things side by side and can connect things, I can secure things over the top but run all of the above. And it's really a matter of building things that have kind of clean our connectural layers where one thing consumes the other and then be able to mix and match and plug them together Lego style as it were. >> This a great chat, and really reminds me of the conversations that we'll be having here in theCube. We've been doing a series with engineering leaders and you know, you mentioned foreclose in the future, future proofing which is kind of a buzz word. The conversation happening in the technical circles is about technical debt and I think, you know, I've always seen that enterprise you know, cost of ownership, you know, and the shark fin, the iceberg and what you don't see. Certainly that's been a paradigm that's been known but now you're getting into this notion of not just so much future proofing, it's really the balance of technical debt because you know something new is coming. This is a modern concept that takes costs of ownership and future proofing and kind of puts it to reality because you're essentially taking on some sort of technical debting from point A to point B, but you don't want to take on too much that you can't pay it back if new technology comes in. So this is what's been going on in some of the you know, top customers that we've been talking to. A new management concept, this is kind of a modern new management discipline. Your thoughts and reaction to that? >> So there's at least two different vectors that talk about on it. So, one of the things is, how do I take these older applications, these older ways of managing things and incrementally improve them. Because we can actually make it-- it is easier today to deploy a process running on a machine than it ever was before. Five years ago I would have a ticket, some guy would go and then install software manually, today we don't do that, we use configuration management, puppet and chefs, ansible, etc. We improve the way I do those things incrementally rather than just forklift them. I'm not rewriting these applications and saying okay, we're going to make these into cloud native applications and microservices and bla, bla, bla and replatform them. No I incrementally improve the way I operate that thing. Even if its just deploying the hardware more consistently underneath or improving this layer. So I incrementally reduce my debt by applying, again, deploying some of these new cloud... Cloud innovations, they're grown out of the cloud to the existing ways of doing things. But the other point I'll make on a lot of this, is that, certainly for our team, and for a lot of the customers I talk about we don't just arbitrarily go and replatform things, right? It's like if the thing is working, let it continue to work. Don't deploy the new thing alongside it. You know, we're more concerned about delivering new features, new capabilities, new things. And we do that, and we concentrate our efforts and our engineering efforts on that and not constantly rewriting the past. >> A container can certainly help you there too. >> Absolutely. Containers are beautiful tool for that, for encapsulating dependencies around a thing. And so you'll find in many cases we have applications that are not ready to deploy to run in Kubernetes with a schedule that's going to move it around but I can still take advantage of the container packaging and run it on a physical box with a normal Linux operating system and containerize it. So it's usually valuable. >> Reinhardt, I want to get your thoughts on one last talking track, that is relevant to something that we've been covering. Stu Miniman, co-host of theCube with me on many of these events around networking, we both love networking, both networking nerds. Always joke about how networking is where you go to find out about the state of the industry is. Look at what's going on with the network. Because network ultimately tells the truth. Movin' things around, security people go to the network. You start to see, everything's revolving around the network now, more than ever. I mean, still, it's been that way forever. But you made a comment before we went on camera you said, just adding another layer of networking. If you think about what you just said, the networking paradigm is just kind of slowly moving to another layer. So networking is happening, it's just happening differently. So as the dev ops innovations in the cloud happens it's really a network innovation. 'cause security pivots off the network data used applications, instrumentations, on the network data, everything's around networks. >> It's intrinsically tied. In the past we had a machine, a physical machine had a network interface, singular, and a network identity an address. VMs, multiple network interfaces, multiple on every VM. Kubernetes, an IP address per application, right? And it's like the networking space is exploding as we move up. And yes, we now have a network connectivity and management problem that's over of magnitudes more complicated than it was before because now, individual workloads have IP addresses. And by the way I'm deploying workloads in multiples. I don't run a single application, I run a pool of applications, each one has an address. And so yeah networking is-- continues to be intrinsic and it just moves up. >> And it's fascinating too, you know, we always speculate about looking for that new technology, the new protocol, something new, the shiny new toy. But if you think about it, all the science and intellectual property has been built already. It's usually a combination of a couple different things. In network theory, in network management, the concepts are still around. It's being applied differently now. >> Or sliced into smaller, you know, smaller, the bites are smaller that you're dealing with, right? Everything has an IP address, we got thousands of IP addresses now that we're managing. Having IP address management problems, we have other things to manage now. >> The game is still the same. >> The game is still the same, it's still TCP IP networking. >> So final question, bottom line, why Cisco and the cloud networking as it comes together? As this stuff starts to modernize, hybrid is certainly reality hardcore, as people are doing today. Multi cloud is also another reality right around the corner. Why Cisco? Why Cisco's products and portfolios for the cloud? >> Well fundamentally, as we said earlier, the cloud has a networking problem. Networking underpins everything that we do. The networking, from physical networking the compute has to run on something. So networking, compute, orchestration systems for all of that, security that overlays all of that. I think Cisco uniquely has all of the components that it takes to build a modern infrastructure stack, and in fact deploy applications to that. I think, the breath of knowledge and capabilities Cisco has across those is unique. And then, also, I would say, Cisco's experience. We have many-- several of the world's largest SaaS applications in the Cisco family. Things like umbrella, DNS security, or Webex, web conferencing, we also have deep expertise in running applications and that's within the Cisco domain of expertise. >> Certainly in good position, I really I'm really bull-ish on what you guys can do. I think the network is where the trust is, it's where the data is, that's where the action is, and I think that's the cloud 2.0 equation. Thanks for coming in. Thanks for the insight. Reinhardt Quelle, principle engineer, Cloud Platforms of Cisco here sharing his insight on this Cube conversation. I'm John Furrier, thanks for watching. (upbeat music)