 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 studios with two great guests from Cisco as we talk about a content series around cloud, cloud management, cloud orchestration, and it's going to be cloud natives, cloud native world, hybrid, multi-cloud, 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, pretty good to see you. Thank you for having us. Sporting the nice Kubernetes shirt there, of course I'm jealous. Great shirt, of course we'll be at CUBECon, so look forward to that. Absolutely, we'll be there too. So thanks for coming, 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 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 in 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 self-host it on-prem, or we also have a SaaS platform or SaaS-hosted capabilities for the cloud center. And sir, the market's growing like crazy. You guys are doing a lot of product work. We've done great interview with Reinhardt from your team on the business benefits, but there's a lot of technical product managers out there, 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 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 into you and they say, okay, implement this. Does it work together? Can I 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 as a developer, 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 then two weeks 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 have already set up their tools around Jenkins and different CI components that they have, which is great, but me being in that part of the work and we hit roadblocks where failures happen and we have to have our eye on the builds and unfortunately there are manual 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 CI CDs, right? We've spent so much time. However, if we can bring idempotent 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 tolerance, that'd be great. And that's what Cloud Center Suite has to offer, right? As Matt pointed out, there are different components to it. You have the workload manager which setups 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 your CI CD 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 tolerance? Does threshold settings and retries? Does it do circuit breaker patterns? 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 engine. I want to unpack it. I said a lot there. I want to just kind of 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 is about Kubernetes. Some people say no, orchestration is 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, that's a good point. Sure, 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 CI CD. Not everything needs to be inside our CI's whether as if there are command patterns that are item potent in design 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 back end. 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 make sense? I mean, fault tolerance you mentioned, you mentioned loosely coupled. What do you mean by that? Because I get loosely coupled anyone that designed OS's knows. You want to couple things and make things highly cohesive. That's a great practice in the systems architecture. What do you mean by loosely coupled? What's the impact of me as I'm trying to figure out my DevOps, my got developers, pipeline? 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, do you talk about it first from a product perspective as you had a roadmap to deal with? Obviously Cisco has legacy positions in the enterprise and you guys are number one in networking in other areas. Now the cloud-native world, so you got to deal with third-party, you guys have done that, been multi-vendor in the past. There's a business of technical impact connecting. As the world's getting faster and more micro-service oriented, what does that mean third-party? What does that mean to be third-party connected? Yeah, it's a great question. So we're going through this 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 provide either the line of business owner or the business element of the IT organization of maybe the cost associated with how much that particular development effort is taking by looking at how much a public cloud provider is charging. We might be able to leverage different infrastructures. So you could leverage on-prem and in the cloud, the public cloud. And so we're having with Cloud Center, you're able to actually take either in workload manager, you're able to actually set up 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 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, Allie, 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. People don't want, 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 a user, your customer, in this case a DevOps or developer or 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 real-time data that cost optimizer is providing from the underlying clusters that we have our services running provides us, if you tie that, and then again, I want to use the word glue here, if you tie that with the orchestration engine, you can do real-time system decision-making on knowing that the next service that you're introducing, now think about it, when we're talking about companies, 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, and 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? Let's explain cost. I mean, cost is cash, but there's also cost in code, there's cost in operations. What do you mean cost in terms of actually hard dollars? Are you talking about cost to the service, impact to the system, or both? What's that? I mean, why do I care if I'm a technical person? I think 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 cost 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 interference at all. 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, 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 I'd let one our next segment we do more of these interviews. I'd love to drill into technical debt, but I'll ask you guys one year, technical debt is something that developers are used to dealing with, especially when they want to go from idea to POC. You take chances, it's technical debt and people have a good form of a balancing technical debt. Costs also factors in other things like that. And when you add microservices to the equation, this service is 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 something, 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 and then I'll fill in an after. Right, so I think like Matt mentioned about the different components that play inside the suite. 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. Go just keep it agile, keep it going. Absolutely. What you guys take on automation, obviously when you look at the biggest trends in multi-cloud and hybrid cloud, two things pop up in this new cloud architecture. Observability and automation are two hot trends which is essentially observability is this network management on steroids and automation is configuration management on steroids. 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. So another element that I think we haven't really talked about was, we have a container platform that actually will leverage the APIs to either the public cloud or on-prem to like a 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, hey, put your workload there. If you want to leverage something that's in the public cloud and because of a service or something, we're not actually putting a cluster on AWS. We're leveraging EKS. We're connecting via APIs the cluster that you are controlling and from the control plane all the way to the workload or the worker node that 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, that connectivity piece and being able then to understand the connectivity and the workloads that go there. Bridge, an old school term. Bridge, it means something. Bridge, gateways, internet working, cloud, same movie, different generation, isn't it? Yeah, moving up the stack. 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 to end this up. Bottom line, I'm a technical person. I have responsibility on 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 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 ops organization that can also sort of let go. I am able to provide that for their developers. And Ellie, 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. This is theCUBE here in Palo Alto for CUBE Conversation. Thanks for watching.