 from our studios in the heart of Silicon Valley, Palo Alto, California. This is a CUBE Conversation. Hello everyone, welcome to theCUBE's CUBE Conversation here in Palo Alto, California. The CUBE studios, I'm John Furrier, host of theCUBE. We're here at Reinhardt-Kwela, who's the principal engineer, cloud platforms and solutions group at Cisco. Reinhardt, thanks for coming in. Good to see you. Thanks for having me. So, technical conversation around cloud is something that we love having. We've seen the evolution of 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, been delivering applications both to data centers and then of course later into cloud for a number of years. So you get 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 for a couple of years now. We saw public cloud, all the benefits, no questions. Great, you can lift and shift stuff up there, no problem. The complexities are 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 from Google, Azure Stack from Microsoft. Clearly this, all the cloud vendors are telegraphing. They are doing it. This is a reality. This has been validated. Yeah, I think that's the most surprised 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 with data centers and yes, we started taking that into the cloud but there was always components of our infrastructure that continue 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 principal engineering. 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 an acute issue because you still got to move packets around. Another abstraction layer does networking, security, networking all tie into 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, you know, a compute in Amazon is 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 it into the 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 is 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 around 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 issues. But now as the data becomes critical, you got security perimeter issues are gone. You got surface area with industrial and IoT. It's only getting more complex. So the complexity never went. But it's still complex, even the same problem. What's changed? 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 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 in the cloud demanded that we automate those things. They demanded the way, you know, when you're managing now fleets of thousands or tens of thousands of machines at scale in the cloud. And when your cloud 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 in the cloud and we apply them on-prem. And so a big part of what Cisco has been doing across our entire portfolio is ensuring that every piece of it from networking to 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'd 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 ways of doing things, these new opportunities. You know, when we talk about, we've had some funny conversations with our security guys, for example, where historically in security we would have some policy, we would deploy applications against that policy. Once every six months or 12 months we would audit against that. Well, one example of bringing the cloud innovation on-prem is the way you deploy that software is, or deploy a new policy is via software. And so auditing that is checking your code before you commit it that says this is what it's going to do. Running, reporting on the things that you've deployed so that you can see. So it's 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 programmed in that way, providing tools that allow us to program the things like the network services orchestrator or Cloud Center suite that allow us to deploy applications or networks or whatever else as software entities. Tell about the reality of the person who's been innovating in the cloud and their reaction when they come back on-prem and go, okay, I've been doing this in the cloud and then 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. And one of my first rules at Cisco was I was working on the Webex operations team and the way we ran that operations was typical of the time it was built. And we did an acquisition of a company that had been operating in Amazon. And when they saw the way that we had to deploy and manage their application on an infrastructure, they were horrified. It's like, what do you mean I can't deploy a server in five minutes? What do you mean that I can't manage the workflow in this way? And 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 in 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 back. So it's like, there was a lot of change to the people and to the way we did things. But really it's a matter of bringing those, bringing the cloud, bringing software development to operations, bringing software programmable to hard, programmably to hardware. Yeah, I mean, that's a great point. I mean, we cover that a lot in the queue 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 can, I think you can control it through software, but this is the deep dive tech conference I want to have with you because we're talking about app deployment, Kubernetes management and the reality of, I have my own gear on site as well as I'm maybe server listening to the cloud. This is the new reality that you have to manage the control. So take us through those layers, app deployment, Kubernetes and the reality of managing infrastructure on a future basis. Sure, so 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 in the products, but ultimately today for an application, someone deploying an application, increasingly that means pushing application into Kubernetes. In other words, I'm going to package my application as a container, I'm going to hand it to Kubernetes through Kubernetes API and I'm going to expect Kubernetes to do the deployment and manage that. Okay, so that just makes the problem for the guy one layer below you, where does Kubernetes come from? It's like who deploys and manages Kubernetes and so there's a number of different solutions in the public cloud, you can use AKS or the Google's Kubernetes service or Amazon's any of these, but on-prem, where does it come from? Who's going to manage it for you? Who's going to create that? And so Cisco 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. I need to be able to deploy a VM or manage hardware that runs below that. That's your innovation message. Yeah, it's like. It's the innovation they want. They need, 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 layer deployed, what's there? And so we continue to support virtualization managers whether VMware or our own CVM, Cisco Virtual Infrastructure Manager. All of these products is like, how do I manage this pool of hardware to provide that next layer of service? And so, but in every case, the programmability of the infrastructure as far down as you can go becomes paramount so that when the guy racks a piece of hardware in the data center, he doesn't want to think about how does this RAID 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 you're referring to. That's making it cloud-like operations for agility, automation, provisioning. Consistency, reliability, observability. Giving an example of that, I mean when we were talking originally and we were starting these cloud deployments and we had this conversation with Infosec about which application lives in which zone and how do you manage that? And we're like, well, the zoning processes that you use 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 that, when I'm talking about software, I'm talking about configuration scripts in this case, Ansible, Chef, Puppet, whatever, that generate those security groups and 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, moving the audit of a system all the way back up to the software development stage and then giving them the tools to verify that afterwards. And their eyes literally popped open. It's 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. And that's what sold them on letting us behave in this new way was the ability to audit in real time. Yeah, and this is a major advantage. This brings up the question that comes up all the time. And I want to get your thoughts on this because this shapes into the overall cloud architecture, cloud portfolio in this case, for 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 got on-premise been validated by Outposts, 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. 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 in the cloud. For example, dev test labs that have soundproof rooms. We saw audio equipment. We saw phones and we have to test those phones. Those aren't ever going to be in the cloud. They're going to be in their soundproof rooms so we can test audio pairing. And there's stuff like that that always lives in our world. There's a myriad of compliance for us that requires it too. Compliance things. Whether it's a Fed ramp compliance, this data has to be in this country, US in that case, European privacy things. It could be, I was talking to one bank a number of years ago now that we're talking about deploying Kubernetes for them. It's like, what applications are you deploying? Why do they need to be here? Well, 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 10 years, 20 years. It's not going to move anytime soon. So you put the application next to the data that it needs. In IoT, it might be control devices or video devices or any number of things. It'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 just want to just quickly unpack that a little bit because that really is the card of the issue of 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, the entire company has to use that because the choices now, because of the levels of granularity that cloud brings, the applications can get almost custom built or not custom built, but a specific hardware and compute to serve their needs. So if it's your sole sourcing, a set of resources for the workload. It's not saying that the infrastructure has to be that for everything. This is the whole single cloud versus multi-cloud dynamic. Yeah, I mean, in fact, one of the things that we're seeing more and more in our customers is 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 boards? 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, we talked a little bit about the infrastructure pieces of that, the Kubernetes deploying to an infrastructure manager, deploying ultimately to hardware, every layer of that, UCS and CVIM and CCP, all of those layers are there and programmable. Okay, now I'm 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 StealthWatchCloud 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 involved. 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, 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 it, 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 the way the complexity is the game. But Cisco's always been successful in multi environments, multi, different environments because networking has always been about diversity of networks. Camp is this and SD went, so it's not a new concept for Cisco to deal with this concept of multiple environments. Do you agree with that? And what's your reaction to that? How would you answer that? Is that something you think Cisco's going to be dominating in? Is that the reason why Cisco can solve up all these, serve up all these choices? What's your thoughts on that? I would have to say that overall that 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, like the real thing, the actual Kubernetes, we're talking about, and we're talking about Steven, we're talking about OpenStack of 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 situation that's going to be scenarios, right? And certain things will be guiding principles, some will be governors and dictate things that might not be classic, cloud native, can you talk about that and give some examples of why that's important and the reality of that statement? Yeah, so just to 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've got the services themselves, the media bridges or the switching engines that are run as containers in a container orchestration fabric. There's the VM-based things that are things like media bridges that don't run in containers very well, not because of the problem of the containers, but because of the overlay networks that containers bring within and the way you route data to those. And then we've got physical machines where 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. And so even within a single product family, there's not one true way of doing things. So it's what's the appropriate way to deploy this application? What's the right deployment target for this thing? And then how do I connect these? You mentioned infosec, so politics might be a driver that have nothing to do with technology. It could be a human capital resource issue. It could be something scalable. And the politics can be even these weird temporal things. It's like, look, I can spend three weeks trying to convince an infosec to do things in a particular way. Or I can just deploy somewhere where it makes him happy and move on. Move on to the next problem. And then later when they catch up with the way we're doing things, then we may move it later. The other thing about timing on all of this is the story is changing constantly. When we deployed that application, we did not use Docker containers. Everybody says, why aren't you using Docker? Because Docker didn't exist three years ago. It's like the wood 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 replace it with another one. You tend to manage them all in parallel. Even as you're making transitions, eventually you kind of get rid of the old stuff, maybe. The mainframe still exists. But in general, for most of our enterprise customers, it's not an or. It's not on-prem or the cloud. It's not containers or physical machines. It's and. I'm running all of the above. And to your point about the Docker containers 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 principles? What's 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 have to kind of be holistic in their thinking. Yeah, future proof is always a funny concept because the reality is that 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 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. And so ultimately we're looking for standards, standard practices that enables me to do the and where I can run things side by side. I can connect things. I can secure things over the top, but run all the above. And it's really a matter of building things that have kind of clean architectural layers where one thing consumes the other and then be able to mix and match and plug them together Lego styles or. This is a great chat. And it reminds me of a conversation that we've been having here in theCUBE. We've been doing a series with engineering leaders. And you mentioned foreclosing the future or future proofing, which is kind of a buzzword. 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, on the shark fin, the iceberg and what you don't see. Certainly that's been a paradigm that's been, you know, 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 cost of ownership and future proofing and kind of puts it into reality because you're essentially taking on some sort of technical debt to move 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 with some of the top customers that we've been talking to. And a new management concept. This is kind of a modern, new management discipline. Your thoughts and reactions to that? Ooh, so there's at least two different vectors to talk about on this. 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. And five years ago I would have a ticket, some guy would go and install software manually. Today we don't do that, we use configuration management, puppet chef, Ansible, et cetera. 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 blah, blah, blah and re-platform them. No, I incrementally improve the way I operate that thing. Even if it's 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 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 re-platform things, right? It's like, if the thing is working, let it continue to work, 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. And containers certainly can help you there too. Absolutely, containers are a 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 scheduler that's going to move it around, but I can still take advantage of container packaging and run it on a physical box with a normal Linux operating system and containerize there. So it's hugely valuable. Right, 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 in many of these events around networking. We both love networking, both networking nerds. Always joke about how networking is where you can go to find out what the state of the industry is. Look at what's going on in the network. Because network ultimately tells the truth. Moving things around, security people go to the network. You're starting to see all these, everything's revolving around the network now, more than ever. I mean, still it's been that way forever. But you just 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 DevOps innovation in the cloud happens, it's really a network innovation. Because security pivots off the network data, use application, instrumentation on the network data, everything's around networks. It's intrinsically tied. I mean, 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. 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 order 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 or run a pool of applications. Each one has an address. And so yeah, so networking continues to be intrinsic and it just moves up. And it's fascinating too. 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 and network management, the concepts are still around. They're just being applied differently now. This seems to be the- Yeah, the grand or sliced into smaller, the bytes are smaller that you're dealing with, right? Everything has an IP address. We've got thousands of IP addresses now that we're managing. We have an IP address management problem. We have other things to manage now. But it's- 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, certainly reality, hardcore as people are doing today. Multi-cloud is 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 is a networking problem. Networking underpins everything 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 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. And I think the breadth of knowledge and capabilities that 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 WebX, web conferencing. We also have deep expertise in running applications and that's within the Cisco area of our domain of expertise. Certainly in good position. I'm really bullish on what you guys can do. I think the network is where the trust is. That'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. Raina Arquella, Principal Engineer, Cloud Platforms of Cisco Cisco here, sharing his insight on this CUBE conversation. I'm John Furrier, thanks for watching.