(upbeat music) >> From our studios in the heart of Silicon Valley, Palo Alto, California, this is a CUBE conversation. >> Hello everyone, welcome to this special CUBE conversation. I'm John Furrier, host of theCUBE. We're here in our Palo Alto studio with two great guests from Cisco as we talk about a content series around cloud, cloud management, cloud orchestration, and interesting cloud native. It's a cloud native world, hybrid multicloud. Two great guests, Matt Ferguson, director of cloud management orchestration at Cisco, and Ali G, technical leader in software engineering. Guys, thanks for coming on, good to see you. >> Thank you for having us. >> Yeah, tanks for having us. >> Sporting the nice Kubernetes shirt there. Of course I'm jealous. (laughs) Great shirt because we'll be at KubeCon, so looking forward to that. >> Absolutely, absolutely. >> We'll be there, too. >> So thanks. Matt, first start with you. You're the director of product management. You see the whole portfolio. What makes up the Cloud Center Suite? What are the components, let's get that out. >> Yeah, no, thanks, I appreciate that. Cloud Center is really our cloud management platform. It's a suite of products, quite candidly, and in the suite we have a Workload Manager module that is about taking workloads and modeling them out in blueprints, and then actually targeting them to very specific infrastructures, whether that's on-prem or in a public cloud, so that's module number one. The second module is our Action Orchestrator product, and this is an orchestration platform that can take various elements of code, of script, and take functions and actually sort of apply those with various different sort of capabilities to either set up infrastructure, or you know, do other sort of capabilities. And the third product in the suite is Cost Optimizer, and this is about understanding how much you're spending. It's understanding budgets, it's trying to categorize that in the public space. We can also apply that into an on-prem and how much you might want to sort of target that. We have, so that's the suite, and the suite is a combination of either self-hosted, so you can actually sort of like download the software and then self-host it on-prem, or we also have a SaaS platform, or SaaS-hosted capabilities for the Cloud Center. >> And the market's growing like crazy. You guys are doing a lot of product work. We've done a great interview with Ryan Hart from your team on the business benefits, but there's a lot of technical product managers out there, or cloud architects, people who are actually in the trenches, who need to look under the hood and figure out if this kind of is going to fit their environment. Ali, you've been, you know, a developer, you are a developer. At the end of the day all the talk on the marketing side is about the benefits. When they come in to you and they say, "Okay, implement this." >> Right. >> Does it work together, can it work by itself, I mean, can you mix and match? Take us through what it means for the folks who have to implement or design around the platform. >> Absolutely, so (clears throat) as a developer, you know, when we're coding it's key that we take our thoughts and ideas and as soon as we can bring it up to a POC, because normally we're working in an Agile fashion, and in two-week sprints at the end of the sprint you have to do a demo. So in order to achieve that this suite gives the capability of taking away any blockers that a developer may have, so a lot of times the developers and the teams already set up their tools around Jenkins and different CI components that they have, which is great but you know, me being in that part of the work and we hit roadblocks where failures happened, right, and we have to have our eye on the builds. And unfortunately there are manual, you know, interactions that we have to do retries. It would be great if the system was fault tolerant. Now that doesn't mean that we have to completely remove what we've done inside our CICDs, right? We've spent so much time, however if we can bring item potent commands and loose couple them a little bit and use the suite in order for us to do some of the work and give us that fault tolerancy, that'll be great, and that's what Cloud Center Suite has to offer, right? As Matt pointed out, you know, there are different components to it. You have the Workload Manager which sets up the infrastructure, but then you have AO, Action Orchestrator, which is the orchestration engine. Where I strongly believe that picking out an orchestration engine, either for you CICD and devops work, or even at the application level for development, becomes challenging, right? Does it support all the features that I have, does it have the patterns that does fault tolerancy, does threshold settings and retries? Does it do circuit breaker patterns, you know, does it take care of everything? So having that AO being your center of orchestration, both for your devops and your application, I feel that plays a strong role as a developer, right? >> So talk about the orchestration engines. I want to unpack, there's a lot there. I want to just kind of-- >> Yeah. >> Unpack it a little bit. Okay, so I'm a developer, I'm like, okay. I'm working hard, I've got the cloud architecture, I've got some cloud native, and every single day a new thing comes over the transit. "Try this new tool, it's going to be killer." Orchestration you mentioned is a buzzword that's been kicked around a lot. Obviously some people try to say, "Orchestration's about Kubernetes." Some people say no, orchestration's about a lot of other things within the enterprise, so IT is starting to get this orchestration fatigue of meaning. What is, when you say orchestration engine, what is it specifically applying to, because certainly there's orchestration within containers with Kubernetes-- >> Absolutely. >> And you're wearing, supporting the shirt. >> Right. >> But it's more than that, what does that mean for me? I'm the person in the trenches, I'm making it happen. >> No, that's a great question. The reason it's a great question is because orchestration means different things at different levels, and you brought up a good point, like Kubernetes. Kubernetes is an orchestration, but it's a container orchestrator, correct? But I'm looking at Action Orchestrator acting as the orchestration for your devops activity, as part of your CICD. Not everything needs to be inside our CIs, whether as if they're command patterns that are item potent and designed, that could move into the Action Orchestrator so that we can leverage retries and have the system be fault tolerant, that's one thing. The other thing is if you're building an application that requires orchestration, that has a workflow, that requires some requests that are given to the application to be processed at the backend, right? That could also leverage this Action Orchestrator engine as well, so you're absolutely right that orchestration is there, for example, in Kubernetes, but that falls into the context of containers, whether as this falls into the context of developers. Does that-- >> Yeah, makes total sense. I mean, fault tolerance you mentioned, you mentioned loosely coupled. >> Right. >> What do you mean by that, because I get loosely coupled. Anyone that designs OSs knows. You want to couple things and make things highly cohesive. Great practice in a systems architecture. What do you mean by loosely coupled, what's the impact of me as I'm trying to figure out my devops, I've got developers pipelining. What does that mean, loosely coupled? >> So when it goes to keeping loosely coupled is if you look at today how let's say I would have done it in my team, and we've done this before, right, is that we'd set up a pipeline in our CI environment where we're performing unit testing and then we're performing integration testing, but then we're also building, packaging, pushing the containers up to the registries, right? What happens where the endpoint registry is down, there is no retries, right, there is no capability of the system knowing how to heal itself. Okay, so keeping loosely coupled in this sense is why not I keep a lot of my UT and integration testing remaining inside Jenkins, which I've done already a lot of investment in, right? I don't want to remove it, right? However, if I bring those third party connection calls that we're doing inside the orchestration which the system heals itself, that's where I see the loose coupleness that can definitely benefit us here. >> Talk about third party. Matt, you talk about it first from a product perspective because you have the roadmap to deal with. Obviously Cisco has legacy positions in the enterprise. You guys are number one in networking, in other areas. Now the cloud native world, so you got to deal with third parties. You guys have done that, been multivendor in the past. There's a business and technical impact in connecting. >> Right. >> As the world's getting faster and more microservice-oriented, what does that mean, third party? What does it mean to be third party connected? >> Yeah, it's a great question. So we're going through this, you know, transition as well where we have to enable the development community as they're going through their proof of concepts, as they're becoming more Agile, as they're actually doing the true continuous integration, the continuous delivery of that proof of concept that ultimately will land into production. So what we want to provide is the tools in order to, you know, provide either the line of business owner or the business element of the IT organization of, you know, maybe the cost associated with, you know, how much it's, you know, that particular development effort is taking, you know, by looking at how much their, you know, that public cloud provider's charging. We might be able to leverage different infrastructures, so you could leverage the, you know, on-prem and in the cloud, the public cloud, and so with Cloud Center you're able to actually take either, in Workload Manager you're able to actually set up, you know, that infrastructure and place that workload there. You're able to use Action Orchestrator to glue a variety of different either scripts or languages, or you know, whatever element that the developer is friendly or familiar with, and then you're also to actually leverage the cost associated. So I get an update on how much this is costing me as the developer is going through their cycle. >> All right, Ali, let's attack that statement. Glue, who doesn't like a glue layer? But at the expense of throwing away what I got is not cool. Like people don't want-- >> Absolutely. >> They want to be, I love to create more opportunities to glue things together, make it more integrated with data modeling going back and forth, I love that. How does your customer, in this case a devops or a developer or a technical architect, get the best of a glue layer-like feature at the same time not compromising any disruption to how they do their business? >> Perfect, so a lot of the work that they already invested inside their devops work could be there. However, like I mentioned about the orchestration section is that the ability to introduce any custom adapters are also available, correct, so there are out-of-the-box adapters for Ansible, Terraform, and many more, for RESTful API calls, and if a team requires to do a custom adapter creation via an SDK that they have inside they can simply implement it because of the interface that's available. So that's where I feel that the glue is where it comes to the orchestration level. Now where Matt pointed out on the Cost Optimizer this is very key because the realtime data that Cost Optimizer is providing from the underlying clusters that we have our services running provides us, if you tie that, and ending out I want to use the word 'glue' here, if you tie that with the orchestration engine you can do realtime system decision making on knowing that the next service that you're introducing, now think about it, when we're talking about huge companies, right, 200-plus microservices, you know, we're not talking about one or two, and there are out there, and when we're talking about those number of microservices cost becomes important. Where should I be able to push the next service? Should I push it, if it's in my public cloud should I go to Azure or should I go to AWS, right? And cost is a key factor there as well, right? >> Explain cost, I mean cost is cash, but there's also cost in code, there's cost in operations. Do you mean cost in terms of actually hard dollars, are you talking about cost of the service, impact to the system, or both? I mean, why do I care if I'm a technical person? Hey, someone else is paying the bills. >> Correct, so a couple of things as a technical person's concerned is that when it comes down to, costs aside, but where the orchestrator actually plays a role and when it comes to where deployment needs to happen on which cloud is key. As a technical person sometimes our environments and our persistence layers that we have services connecting to require only access to private data, so it cannot go into the public sector. So that service needs to be deployed onto the private cloud. Whereas you have other services that have to live on the edge because they communicate with the internal cloud, so those services need to be pushed onto that public. So it's here that the suite basically gives you the opportunity to do all of that automatically without any, you know, interference at all. >> And you know, and I'll just dive in. I mean, I think the thing that, you know, if I was a line of business owner, right, I'm really looking for my developer community, my team to move faster. I don't want to necessarily slow them down, so I want to be able to say, "Hey, if there is a service within Azure, "if there is something within Google Cloud "that really helps you develop either faster "or provides a service that makes "the functionality of the experience better," I want the developer to be able to use that as a target infrastructure. At the same time, you know, I also want to go, "Okay, so as we're building out this application "or this service, is it growing out of bounds in cost, "is this something that I can actually "sort of take to production," and then I have an awareness of exactly when they go through the unit test, the integration test, how much this is actually going to cost. >> It's a fascinating conversation, certainly on our next segment when we do more of these interviews I'd love to drill into technical debt, but I'll ask you guys while you're here, technical debt is something that developers are used to dealing with, especially when they want to go from idea to POC, you take chances, there's technical debt and people have a good form for balancing debt. Cost also factors into things like that, and we add microservices to the equation, there's services going up and down, you don't know what's happening. So automation comes into a big part of this. So this idea of getting from point A to point B, whether it's idea to POC or POC to production, there's sometimes technical debt involved, there's sometimes thinking around that. How does the platform help there? Is that something that you guys help developers with? Because that's some, I'll take a chance. If I want to get a POC up and running maybe I take some technical debt to try to get it going, then I'll fill it in after. (laughs) >> Right, so I think like Matt mentioned about the different components that play inside the suite, you know, you have the infrastructure handled by Workload Manager, you have your orchestration again by AO, you have Cost Optimizer providing cost. The ability to set up your system inside these components and then creating a template out of it so that later when you want to challenge technical debt you're not reinventing things, so you already have templates created. So going back and dealing with technical debt is about how you can take your templates to the next version. >> And that's in line with devops thinking, iteration. >> Exactly. >> You know, just keep it Agile, keep it going. What's your guy's take on automation? Obviously when you look at the biggest trends in multicloud and hybrid cloud you have two things pop up in this new cloud architecture, observability and automation are two hot trends, which is essentially, observability's just network management on steroids and automation's configuration management on steroids, (chuckles) so the world's kind of the same but evolving. I mean this is in your, both are in your wheelhouse for Cisco as a company. >> Yeah, and another element that I think we haven't really talked about was, you know, we have a container platform that actually will leverage the APIs to either the public cloud or on-prem to like an ESXi host on VMware, and what that provides is to leverage the best of where that particular service would reside. If it's on-prem because of particular use cases, of data sovereignty or just locality, you know, hey, put your workload there. If you want to leverage something that's in the public cloud because of a service or something, we're not actually putting a cluster on AWS, we're leveraging EKS, we're connecting via APIs. You know, the cluster that you are controlling from the control plane all the way to the workload or the worker node, it would actually be spun up within EKS. So we're trying to bridge that on-prem world to the public cloud, so very much hybrid cloud, the connectivity piece and being able then to understand, you know, the connectivity and the workloads that go there. >> Bridge, an old school term. >> Bridge, yes. >> It means something. >> Yes. >> Bridge. >> Yes. >> Gateways. >> Yes. >> Internetworking. >> Yes. >> Cloud, same movie, different generation, isn't it? >> Yeah. (laughs) (laughs) >> You got it. >> I mean they're moving up the stack a bit. >> Yeah. >> But this is serious, this is going on. People want to have things move around. It takes a lot of networking knowledge, but it's all being done now with software with a lot of automation abstraction. This is why I think the devops and the net devops world, whatever we're calling it, is really creating this new abstraction layer. So great conversation, let's bring it all together and end this up. Bottom line I'm a technical person. I have responsibility, my boss is saying, "Go faster, be Agile, be devops," but we've got all this legacy to deal with. Why Cisco platform, what's the bottom line? >> With the container platform what we're trying to do is enable IT to have the tools that they can actually enable the speed and agility for their developers, and that's really the bottom line. And we're trying to, you know, just basically empower and move at the speed of Agile, so IT is now a part of the process of innovation and proof of concepting. I know the challenge though is governance, policy, security, all the things, the connectivity. Those are the elements that we're bringing to the table for the IT, you know, ops organization that can also sort of like go, "I am able to provide that for their developers." >> And Ali, your perspective, you're one of us. You're a technical brother. What's the bottom line, why should I take a chance, why should I implement this platform? >> Because developers really want to code at the end of the day, and they want to just focus on their business logic. They want the system to be automated. They want the system to be self-healed, and just like what Matt said, right, this suite basically gives you that so that you just focus on your code and your business logic, nothing else. >> Awesome, guys, great conversation. Looking forward to following up. I think there's a lot to unpack. I think as this cloud 2.0 world, or whatever it's being called, is about modernization of the enterprise, and it's going to be around for a long, long time. Thanks for sharing your expert opinions and commentary, appreciate it. >> Thank you very much. >> Thanks for having us. >> This is theCUBE here in Palo Alto for a CUBE conversation. Thanks for watching. (upbeat music)