(upbeat music) >> Announcer: From our studios, in the heart of Silicon Valley, Palo Alto, California, this is a CUBE Conversation. >> Hey, welcome back already, Jeff Frick here with theCUBE. We're in our Palo Alto studio today for a CUBE Conversation that's a little bit of a deeper dive into the Cisco CloudCenter, we've had an ongoing conversation and there's a new component today, we're going to do a deep dive, so we're excited to welcome back to the studio CUBE alumni Ali G, technical leader, software engineering group from Cisco, Ali, great to see you again. >> Thank you so much, happy to be here. >> Absolutely, and joining us from New Jersey via the phone is Michael Chenetz, he's a technical marketing engineer from Cisco, Michael, great to see you. >> Hey, great to see you guys. >> And I hope you'll go get a cheese steak when we're finished and figure out how you can send it to me, I don't know if that's possible. But anyway, welcome. So let's jump into it, so Cisco CloudCenter, we've been talking about it for a while, but today we wanted to dig into a very specific feature, and it goes technically by AO, but that stands for the Action Orchestrator. Ali, what's Action Orchestrator all about? >> Well, action orchestration is a component inside our CloudCenter Suite that brings together cross-domain orchestration. And it's extremely useful because not only is it valuable for DevOps engineers to orchestrate and maintain and automate their infrastructure, but it's also useful for application developers to define workflow and orchestration in their products as well. So, this tool is heavily used throughout the stack, inside the cloud, at the application level, all the way down to the intro level as well, and it's made it extremely easy for DevOps engineers to get their hands on defining workflows, and conditions and logics where they can create, maintain, all the appropriate infrastructure that they need. Works very well hand to hand with the current technology out there like Terraform or Ansible, and it's part of our CloudCenter Suite, so. >> And is it more on the config side or is it more on kind of the operational workflow side? >> Correct, so it could be used for both, right, it's so flexible in a matter of this abstraction of having the orchestration engine outside, enables both developers and DevOps engineers to illustrate and create their workflows. Rather, it's again based on infrastructure or even networking layers, are all the way up the stack to the application where if your product requires an orchestration engine in the back end, to process work, this component definitely plays a big role, right, so. >> Okay. Michael, throw it over to you. >> Yeah, so I think everything that Ali is saying is absolutely correct, the nice part about it is it's a product that can really do whatever you imagine, so I mean we've seen people use it for business process, for automation of network, server, cloud, whatever you can think of, it's extensible but we're going to talk about that in a little bit, but really the nice part about it is you create the workflows and you design the way that you want to go. And what I have here, if you can show the next video, is just a little clip of what it would look like to go through a workflow. So let's cue that up and we'll take a walk through it. >> Jeff: Let's go to the video number one, guys. >> Michael: All right, so... Yeah, so if you look here, what we're seeing is, we're seeing a preview of what Amazon looked like beforehand, looking at VPCs and subnets, and now what we're doing is going through a workflow that is going to show afterwards that those actual VPCs and subnets were created by using a flow. So what we're going to do is just pick one flow here, which is called create infra, and this is just an example, and what you see on the left-hand side is something called actions, so these are all the atomic actions that are available. But these are just out of the box, we're adding stuff all the time, and these actions could be dragged over to the right and create workflows. And the nice thing about it is if it's not there, you can create them in minutes and we're going to show you that in a little bit, too. So, right now what I'm going to show you is the fact that if you click on each one of these actions, there's actually some kind of information that you'll see on the right-hand side, and this information is how you configure that particular action, so this particular one's going to create a VPC, and you can see the VPC name, you can see the VPC subnet, and whatever other parameters are needed for that particular action. So now I'll have to do, you pretty much select the target, and this one already had a target selected, which is Amazon, or AWS, and this second action here, if you look down, actually has a parameter too, or a couple parameters, and one of those parameters, you can see the first one is just the name, the second one, though, is actually used in a variable from the previous step. So really really easy to map stuff from different workflow elements, and it allows you to quickly kind of glue things together to make things work, so this is just an example, again, very simple example, that this is going to create infrastructure on Amazon, and you can think about using this as part of the process, like when you're trying to bring up a cloud environment, maybe you run this first. Maybe you run this to say, "Hey, I need some infrastructure "for that cloud environment," and maybe you even want to execute bringing up certain VMs or containers, you could do that afterwards. But this was just a really really quick showcase of a simple thing you can do with very few steps, that you could then run and it will actually, we're going to run, hit validate here, just validates the workflow, but once we click run here, it's actually going to create all of that stuff within Amazon, so in this step you're going to see the run, you can see that both steps work, because they're green. If they didn't work, they'd be red, and we're going to show that in one second. But, when you click on a step it actually shows you the input and output of each one of those steps, so it's really really cool in that all the information that you could possible think of that you'll need to troubleshoot, to look at these things, is available in the workflow by just clicking on each one of these steps and seeing what that input and output, so if you could imagine, if you had an error there, you could quickly figure out what that is, it would tell you the error, it would tell you what's going on, or, if you needed information from a step before, you could run it, get the information from the step before, and then figure out what values you need for the next step. So really really cool in that you could look at this workflow, you get all the information you need, and it allows you to create these workflows and kind of glue 'em together, really really quick. And now what I'm going to show you, I believe, is in the next part here, I'm just going to illustrate that if you go over to the runs that we have here, it'll actually keep a list of all of the different runs we did, and you can see one is in red. Well, that one in red means that a step didn't work. Well let's click on that step and figure out "Hey, why didn't this step work?" Well this step didn't work because of an error that we got, and if we scroll down to the bottom over here, what we're going to see is the actual error that had occurred within this step. So now we know exactly what the problem was, and we can fix it within the next step, so in this particular one, we illustrated right there that there was some problem with, I think a VPC, or the way that I phrased that VPC, or that subnet, I'm sorry, and it caused the problem. But I fixed it within the next step, and now you can see that in these particular two screens that the VPC and the subnet was created automatically within that workflow. >> Pretty cool, so what would they have done to accomplish that in the past? >> So to accomplish that in the past, and this is the real thing that we see, we see that people have all these tools all over the place, those tools might be things that are orchestration engines, other products that might be things that you run from the command line. Which work great together, but what you find is that, there's no central orchestration, and what we want to provide is that central orchestration that can run those other tools, and also schedule them together. So if you use other tools besides AO, that's fine. We're happy to bring them in, and you could use the variables, you could use everything that you still would use, but now you have all the integration, you have all the variables, you have all the workflow, and not only just from AO, but from Workload Manager too, so if you bring up a VM and bring up a container, you get that information. So there's just a lot of tooling inside that allows you to really take advantage of everything you might already even have. >> Correct, I mean that was a good demo, and one of the things I'd like to point out here is that, compared to some of the competitors that are out there with this orchestration engine, I don't want to name anyone particular, but if you look at it, the schema that Michael just showed us in that demo is JSON-based, versus others out there are some still in XML. The other very beneficial to this is that since this is a component of our CloudCenter Suite, it also gets installed on-prem, and what that means is footprint is extremely important when it comes to on-prem especially. And with the technology and the cloud-native solutions, that the team has done inside Cisco, our footprint is very small, due to the technology choices that we use in writing our services in Go, and et cetera, versus outside competitors are doing it in Java, which have a much more larger footprint on the infrastructure, that clients and customers get to install, so there are a lot of features with this orchestration engine that comes when we're trying to compare them with the market and the competitors of that are out there. Conditional logicking, what Michael just showed us inside the workflows, right, it makes it super simple for someone who has not had any experience coding, to put together the workflows and introduce conditions, either for loops or if else statements or conditional blocks, whereas in the competitors, you have to know a certain amount of programming skills in order for you to do those conditioning, so, I feel that that's a great advantage that we have here, so. >> And so does a lot of things come packaged out of the box? Standard processing, standard workflows, standard processes? >> Yep. >> And then what do they code it in, then, if it is a custom workflow that you don't have, how do they go in and manipulate the tool? >> Good question, because like I mentioned, competitors, you would have to know a certain language in order for you to code those logical flows that you want inside your orchestration, right? Inside AO, it's all driven by the DSO, which is all JSON-based, right, and the DSO is so powerful that you can introduce if and else conditions, you don't have to know a language per se, it's just you define your logic, right, and the tool actually allows you to provide those flows, those if conditions, the loops that are required, and also defaulting onto fallbacks or et cetera. >> Think Michael, you were going to show us a little bit more on that, and kind of set up some of these actions. >> Yeah, I think that's absolutely key, is that what we're talking about is extensibility here, so the extensibility is one thing that we kind of tout, because you don't need to be a programmer, but we live in an API world, so we need a way to consume these APIs. How do we do that in companies and businesses that think developer is expensive, and it's very hard to get into. So we're trying to take that out of that and say "Hey, we have this engine." So let's take a look at some of that extensibility on the next video that I have here. >> Jeff: Kay, pulling that up. >> Michael: So what you're seeing here is Postman. So this is a regular tool that a lot of people use, and what I'm showing is just a call, which is in Postman. And this particular call just gets a Smartsheet, so this gets a Smartsheet from Smartsheets, and it just lists what Smartsheets are available. And in AO, I want to be able to create this, and if we look at the timer, I'm doing this in less than five minutes. So I have no calls for Smartsheets, but I want to create a call, so what I did is I created a target for Smartsheets, that's an http target. And what that means is that I can connect to Smartsheets, and if you look at the bottom I list the API address, and I list the default path, so you don't have to enter that path a million times, so we know that API/2.0 is the path that we're always going to use. On top of that, there's always some other kind of element to that path that we're going to need in each particular action that we want to call. So what I'm going to do here is showcase what I did. So, in this first step, what I've done is I actually did a generic http request, so no programming needed, all I had to do is use a URL. People have used the World Wide Web, they know how to use URLs. In this one, the call is /sheets. It doesn't take a brain surgeon to figure this out. So, really I did /sheets is what I'm calling, and I'm using the target, and then the next step what I'm doing is I'm setting up a variable that's going to be my output variable, so what am I going to call this, maybe I'll call it Sheets, and really all I'm doing is just setting this up and saying that we are going to call this Sheets, going out of it, and that's about it. So what I've done within a couple minutes is created a new action that's going to be shown on the left-hand side. So now you can think of a reusable element, and what I'm showcasing here is I'm actually going to turn it off and turn it back on just to showcase, but there's something called atomic actions. So I'm just validating that this is running, I'm going to take a look at the atomic action, I'm going to give it a category, so I'm going to put this under the Smartsheet category, so if you can imagine, I had a lot of these Smartsheet actions, I could just put 'em all into one category where I'll find 'em on the left-hand side. But, I'm just going to validate that the atomic action is good, and now what I'm going to show you is that when I call up a new workflow, I could just drag that right from the left-hand side, and it'll be under Smartsheets, it'll be under get those lists, list Smartsheets, and what it's going to ask for now is a token, because you need a token in order to authenticate with Smartsheet, that's a Smartsheet requirement, so what I'm going to do is just go over to Postman, and grab that token real quick, and then come back over to this page and enter that token in. So, the first thing I'm going to do is create an input variable, and that input variable is going to ask for a token, so what that does is it, when I run this, in this particular workflow, I can ask for an input variable, and that means every time it runs it's going to pop up with that variable. Right now what you're seeing is I'm associating that variable that I created with that token parameter, and this is a secure string, so you can never see what that string is. It's hidden, it's made so that it's not ever seen. And so now if I run the run, you'll see it asks for a token. Now is actually when I'm going to go over to Postman, I'm going to grab that token, so you'll see I'm going into Postman, and Postman, again, is just what we use to test these calls, a lot of people use it, it's very industry-standard, and I'm just grabbing the token from here. It's blurred out so that the public can't see it, but I grabbed it, and now I'll go back out into here, and I hit run, and you'll see that I created that action, I brought the action into a workflow, I ran it, it's running, and now it's giving me that exact same output that I would've got in Postman, but now it's a reusable element. So this just illustrates the extensibility that's available within our product. Again, only took a couple of minutes, and I have an action that I might have needed that wasn't available in this tool, but it was created, and it works out of the box now. >> Very slick, and so that was with Smartsheets, how many connectors do you guys already have preconstructed? >> There are so many, I mean I don't want to list a lot of different vendors, but you can imagine every DevOps tool is in there, there are connections to Amazon, to Google, to Kubernetes, to, internally through ACI, through Meraki, through a lot of the Cisco ecosystem. So really, there's just a lot available, and it's growing, it's growing tremendously and we're building communities and we just want people to try it, use it, I think they'll really like it once they see what it can do. >> Yeah, and I'm just curious, Ali, is this something then that people are going to be working on all the time, or are these pretty much, you set your configs and go back to work, you set these relationships and go back to work, or is this, this is not your working screen. >> This is, I mean how cool was that, right, creating those atomic actions and being able to templatize those and building those building blocks like Lego, right, that in the future you can just build more and more out of, and just add to the complexity without it being complex at all, right? But going back to your question is, a lot of these toolings that are build with AO, one of the other advantages that we see that unfortunately some of the competitors don't have outside, is that you have the ability of four different type of events that inside AO is supported. So you, as DevOps engineers, they tie them up to scheduling, they tie them up to events coming in from a message queue, so these workflows that are created get triggered by these events, which makes it possible for them to execute at a certain time, or for a certain event that gets triggered, right, so again, reusable atomic workflows and actions that Michael just demonstrated, along with having both engineers and, application developers and DevOps, and I kind of stress it out, because of how flexible this is. For them to define it one time, and then have it reusable whenever they want. >> I'm just curious, what's the biggest surprise when you show this to people in the field? What do they get most excited about? >> They love it, they immediately say, "How can we start using it the next day?" And we also have, CloudCenter Suite has a SaaS offering where it's made it very easy for us to get them a trial access so that they can come in, get their foot wet and try it out. And once they start doing these calls and building these workflows and as Michael demonstrated, these actions where they perform API calls at the very least, they just get hooked to it, right, and then start using it from thereon. >> Michael, what about you, what's your favorite response from clients when you demo this, what's the one, two things that really grabs 'em, gets their attention, gets a big smile on their face? >> Yeah, well first and foremost you see people's minds spinning on what use cases have been bothering them that they haven't been able to fix, because maybe they're not programmers, or maybe they are, but it's just, they thought it would be too complex and too much work. So, I think it's just, it's so open-ended but you just see the interest in people's faces, it's like the first time, I have a three year old, the first time I gave him Legos and he's like, "I can build stuff, I can do stuff myself?" I mean it's just like that, I mean that's the amazing part of it is that it's so extensible, and to build onto what Ali was saying, there's so many ways to trigger it, too. So this can work standalone and work by itself, or it can be triggered by an API call, it can be scheduled, it could be called from Workload Manager, it can be triggered from a RabbitMQ, it could be triggered from Kafka. There's so many different things that you can do to trigger these workflows, that it just makes it so that it can integrate with other products, and you can integrate other products, so it really becomes that glue that kind of ties everything together, I mean we really really think about it as building blocks or Legos, or something like that. It just is really extensible, really easy to use, and we think it's a real game-changer. >> Great, all right, Ali, so last word, where do people go to get more information if they can't see that cool demo on that itty-bitty screen on their phone? >> So, we definitely recommend them to go to CloudCenter Suite, if you easily Google it on Cisco website or on Google itself, you'll see it apart from first or second links, but definitely check out CloudCenter Suite, Action Orchestrator is where you would like to visit and learn more about this tool and this component. >> All right, well thanks for stopping by, and thanks for joining us from New Jersey, Michael. >> Oh, thank you, and I'll send you a cheese steak. >> All right. I don't know if I want that in the mail, but we'll see if we can maybe fast shipment, all right, thanks again for stopping by, he's Ali G, he's Michael, I'm Jeff and you're watching theCUBE, we're in our Palo Alto studios, thanks for watching, we'll see you next time. (jazz music)

>>From our studios in the heart of Silicon Valley, Palo Alto, California. This is a CUBE conversation >>and welcome back. You're ready. Jeffrey here with the cue. We're in our Palo Alto studio today for a Q conversation that a little bit of a deeper dive into the Cisco cloud center. We've had an ongoing conversation. There's a, a new component today. We're going to do a deep dive, so we're excited to welcome back to the studio. Uh, Kube alumni, uh, Ali G technical leaders software engineering group from Cisco. All great to see you again. Happy to be here. Absolutely. And joining us from New Jersey via the phone is Michael Chenoweth's. He's a technical marketing engineer from Cisco. Michael, great to see you. Hey rich, see you guys. And I hope you'll go get a cheese steak when they're finished and uh, after grad how you can send it to me. I don't know if that's possible, but uh, yeah. Anyway, welcome. Uh, so let's jump into it. So Cisco cloud center we've been talking about for a while, but today we want to dig into a very specific feature and it's a, it goes technically by a O, but that stands for the action orchestrator Ali. What's action orchestrator? >>Well, action orchestration is a component inside our cloud center suite that brings together cross domain orchestration and it's extremely useful because not only is it valuable for dev ops engineers to orchestrate and maintain and automate their infrastructure, but it's also useful for application developers to define workflow and orchestration in their products as well. So this tool, um, is heavily used throughout the stock, inside the cloud, at the application level, all the way down to the intro level as well. And um, uh, it's made it extremely easy for DevOps engineers to get their hands on the fining workflows and, uh, conditions and logics where they can create, maintain all the appropriate infrastructure that they need. Works very well hand to hand with the current, uh, technology out there like Terraform or Ansible. And, um, it's part of our CloudCenter suites. Huh. >>And is it more on the config side or is it more on kind of the operational workflow side? Correct. >>So it could be used for both. Right. It's so flexible in a matter of, I'm this abstraction of having the orchestration engine outside, uh, enables both developers and dev ops engineers to illustrate and create their workflows. Um, uh, rather, it's again, based on infrastructure or, uh, even networking layers or all the way up the side to the application where if your product requires an orchestration engine in the backend to process work, this, uh, this component definitely plays a big role. Right? So, >>okay, Michael, throw it over to you. >>Yeah, so I think everything that a Ali is saying is absolutely correct. Um, the nice part about it is it's, it's, >>you know, >>it's a product that can really do whatever you imagined. So, I mean, we've seen people use it for business process, for a automation of network, server, cloud, whatever you can think of. It's, it's, um, you know, it's extensible. We're gonna talk about that in a little bit. But really the, the nice part about it is you create the workflows and you designed the way that you want to go. And what I have here, if you could show the next, uh, video is just a little clip of what it would look like to go through a workup. Well, okay, so let's go queue that up and we'll uh, we'll take a walk for it. Let's go to the video number one guys. All right. So yeah, so if you look here, what we're seeing is we're seeing a pre, a view of what Amazon looked like, a beforehand looking at VPCs and subnets. >>And now what we're doing is going through a workflow that is going to show afterwards that those actual VPCs and subnets were created by using a flow. So we're going to do is just pick one flow here, which is called creative for us. And this is just an example. And what you see on the left hand side is something called actions. So these are all the atomic actions that are available. A, but these are just out of the box. We're adding stuff all the time. And these actions can be dragged over to the right and create workflows. And then just think about it as if it's not there, we can create, you can create them in minutes. And we're going to show you that in a little bit too. So right now what I'm gonna show you is the fact that if you click on each one of these actions, there's actually some kind of uh, information that you'll see on the right hand side. >>And this information is how you and figure that particular action. So this particular one's going to create a VPC and you can see the VPC name, you could see the VPC sub-net, um, and whatever other parameters are needed for that particular action. So not a lot to do. You pretty much select the target. And this one already had a target selected, which is Amazon or AWS. And the second action here, if you look down, actually has a parameter two or a couple parameters and one of those parameters you can see the first one is just the name. The second one though is actually using a variable from the previous step. So really, really easy to map stuff different workflow elements and it allows you to quickly kind of glue things together to make things work. So this is just an example again, very simple example that this is going to create infrastructure on Amazon. >>And you can think about using this as part of the process. Like when you're trying to bring up a cloud environment, maybe you run this first, if you run this to say, Hey, I need some infrastructure for that cloud environment and maybe you even want to execute, um, you know, bringing up certain VMs or containers, you can do that afterwards. But this was just a really, really quick showcase. Oh, a simple thing you can do with very few steps that you can then run and it will actually, we're going to run, hit validate here. It just validates the workflow. But once we click around here, it's actually going to create all of that stuff within Amazon. So in the next, in this step, you're going to see the run. You can see that both steps work because they're green. If they didn't work, they'd be red. >>And we're going to show that in one second. Um, but when you click on a step, it actually shows you the input and output of each one of those steps. So it's really, really cool on that all the information that you could possibly think of that you'll need to, to troubleshoot, to look at these things is available in the workflow by just clicking on each one of these steps and seeing what that input and output. So if you can imagine if you had an error there, uh, you could quickly figure out what that is. It would tell you the error, it would tell you what's going on, or if you needed information from a step before you can run it, get the information from the step before and then figure out what values you need for the next step. So really, really cool in that you could look at this workflow, you get all the information you need and it allows you to create these workflows and kind of glue them together really, really quick. >>Uh, and now what I'm going to show you, I believe is in the next part here. I'm just going to illustrate that. If you go over to the runs that we have here, it'll actually keep a list of all of the different runs we did. And you could see one is in red. Well that one in red means that a step didn't work well. Let's click on that step and figure out, Hey, why didn't this step work? Well, this step didn't work because of an error that we got. And if we scroll down to the bottom over here, what we're going to see is the actual error that are had had occurred within this step. So now we know exactly what the problem was and we can fix it within the next step. So in this particular one, um, we, we illustrated right there, uh, that there was some problem with, uh, I think a VPC, um, or the way that I, I sorry, the way that I phrase that VPC or that's something that I'm sorry. >>And uh, it, it, it positive problem, but I fixed it within the next step in. Now you can see that in these declare two screens that the VPC and the sudden that was created automatically within that workflow. Pretty cool. So what, what would they have done to accomplish that in the past? So there'll come a sound the past, and this is the real thing that, that we see. We see that people have all these tools all over the place. Those tools might be, you know, things that are uh, orchestration engines, you know, other products that it might be things, uh, that, uh, they run from the command line, uh, which are, you know, work great together. But what we find is that, you know, there's no central orchestration and when we want to provide is that central orchestration that can run those other tools and also schedule them together. >>So if you use a, if you use other tools besides a AAO, that's fine. We're happy to bring them in. And we could, you could use the valuables, you could use everything that's, that you still use. Okay, now you have all the integration, you have all the variables, you have all the workflow. And not only just for Mayo but from workload manager too. So if you bring up a VM and and bring up a container, you get that information. So there's just a lot of uh, you know, tooling inside that allows you to really take advantage of them. Everything you might already even have. >>Yeah, correct. I mean that was a good demo. And, uh, one of the things I like to point out here is that compared to some of the competitors that are out there with this orchestration engine, uh, I don't want to name anyone particular, but if you look at it, the schema that Michael just showed us in that demo is Jason Bass versus others out. There are some still in XML. The other very beneficial to this is that since this is a component of our cloud center suite, it also gets installed on prem. And what that means is footprint is extremely important when it comes to OnPrem especially. And, uh, with the technology and the cloud native solutions that you know, the team has done inside Cisco, our footprint is very small, uh, due to the technology choices that we use. And writing our services and go and et cetera versus outside competitors are doing it in Java, which have a much more larger footprint on, you know, the infrastructure that clients and customers get to insult. >>So there are a lot of features, uh, with this orchestration engine, uh, that comes when it, uh, when we're trying to compare them with the market and the competitors that are out there. Conditional logic in what Michael just showed us inside the workflows, right. It makes it super simple for someone who has not had any experience coding to put together their workflows and introduced conditions, um, either for loops or if L statements are conditional blocks, whereas in the competitors you have to know a certain amount of programming skills in order for you to do those conditionings. So I feel that that's a great advantage that we have here. So, >>and so do you does a lot of things come packaged out of the box kind of standard processes, standard standard workflows and our processes. Yup. And then what do they coat it in then? If, if, if it is a, a custom workflow that you don't have, how do they go in and manipulate the tool? >>Good question. Because I'm like I mentioned, right? The competitors, you would have to know a certain language in order for you to code those, a logical flows that you want inside your orchestration, right? Inside EO, it's all driven by the DSL, which is all Jason base, right? And the GSL, the DSLR is so powerful that you can introduce if an ELs conditions, you don't have to know a language per se, right? It's just you define your logic, right. And um, the tool actually allows you to provide those flows, those if conditions of the loops, uh, that are required and also defaulting onto fallbacks or etc. So, right. >>I think Becca, you're going to show us a little bit more that, uh, >>yeah, I think that's, that's absolutely key is that, you know, what we're talking about is extensibility here. So the extensibility is, is one thing that we kind of tell because you don't need to be a programmer, but we live in an API world. So we need a way to consume these API. How do we do that in, and you know, companies and businesses that think developer is expensive and it's very hard to get into. So we're trying to take that out of that and say, Hey, we have this engine. So let's take a look at some of that extensibility on the next video that I have here. >>Okay. Pulling that up. So what you're seeing here, uh, is, uh, postmaster. So this is a regular tool that a lot of people use. And what I'm showing is just appall, which is, which is in boost Matt. And this particular call just gets a Smartsheet. So this gets a Smartsheet, uh, from Smartsheets and it just lists what Smartsheets are available and yeah, in a, Oh, I want to be able to create this. And if we look at the time, or I'm doing this in less than five minutes, so I have no calls for Smartsheets, but I want to create a call. So what I did is I created a target for Smartsheets that's an HTTP target. And what that means is that I can connect to Smartsheets and if you look at the bottom, I list the API a address and I list the default path. >>So you don't have to enter that path a million times. So we know that API slash 2.0 is the path that we're always going to use. On top of that, there's always some other kind of, uh, element to that path that you know we're going to need in each particular action that we want to call. So what I'm going to do here is showcase what I did. So in this first step, what I've done is I actually did a generic HTTP requests. So no programming needed. All I had to do is use a URL. People have used the worldwide web, they know how to use URLs. And this one, the cause slash sheets doesn't take a lot of, you know, um, it doesn't take a brain surgeon to figure this out. So ah, really I did slash sheets is, is what I'm calling. And um, you know, I'm using the target and then the next step when I'm doing is I'm setting up a variable that's going to be my output variables. >>So what am I gonna call this? Maybe I'll call it sheets. And really all I'm doing is just setting this up and saying that we are going to call this Sheetz going out of it. And that's about it. So what I've done within a couple minutes is created a new action that's going to be shown on the left hand side. So now you can think of a reusable element. And what I'm showcasing here is I'm actually gonna turn it off and turn it back on just to showcase. But there's something called atomic actions. So I'm just validating that this is running. I'm going to take a look at the atomic action. I'm going to give it a category. So I'm going to put this, the Smartsheet category. So if you could imagine I had a lot of these, a Smartsheet actions, I could just put them all into one category. >>We'll find them on the left hand side, but I'm just going to validate that the atomic action is good. And now what I'm going to show you is that when I call up a new workflow, I can just drag that right from the left hand side and it'll be under smart sheets. It'll be under, you know, get those lists are uh, Smartsheet, um, lists Smartsheets and what it's going to ask for. Now as a token, because you need a token in order to, uh, authenticate with Smartsheet. That's a Smartsheet requirement. So what I'm gonna do is just go over to postman and uh, grabbed that token real quick and um, and then come back over to this page and enter that token in. So, uh, the, the first thing I gonna do is create an input variable and that input variable is going to ask for a token. >>So what that does is it, when I run this in this particular workflow, I could ask for an input variable. And that means every time it runs, it's going to pop up with that variable right now where you're seen as an associate in that variable that I created with that token parameter. And this is a secure string so you can never see what that string is. It's hidden, it's a, you know, it's a, it's made so that it's, it's not ever seen. And um, so now if I run the run, you'll see it asks for a token. Now is actually when I'm going to go over to postman. I'm going to grab that to again a, so you'll see I'm going into postman and post again is just what we use to test these calls. A lot of people use it. It's very industry standard. >>Uh, and I'm just grabbing the token from here. Uh, it's blurred out so that, so that though public can't see it. But I grabbed it and then we'll go back out into here and I hit run and you'll see that I created that action. I brought the accidents who workflow, I ran it, it's running and now it's giving me that exact same output that I would've gotten in postman. But now it's a reusable element. So this just illustrates the extensibility that's available within our product. Again, when we took a couple of minutes and I have an action that I might've needed that wasn't available in this tool, but it was created and it, uh, you know, it works out in the box now, so >>very slick. And so that was with, uh, with Smartsheets, how many connectors do you guys already have pre constructed? >>There are so many. I mean, you know, I don't want to list a lot of different vendors, but you could imagine every dev ops tool is in there. Um, there are connections to Amazon, to Google too, uh, to Coopernetties, to, um, to internally through ACI, through Muraki, through a lot of the Cisco ecosystem. So really there's, there's just a lot available, uh, and it's growing. It's grown tremendously and we're building communities and we just want people to try it, use it, I think really like it. Once they see what it can do. >>Yeah. And I'm just curious all, is this something that then that people are going to be working on all the time or these pretty much, you know, you set your configs and go, go back to work, you set these relationships and go back to work or is this, this is not your work screen, >>this is, I mean, how cool was that, right? Creating those atomic actions and being able to templatize those and, and, and building those building blocks like Lego, right, that in the future you can just build more and more out of and just either add to the complexity without it being complex at all. Right. Um, but going back to your question is a lot of these toolings that are built, um, with EO, the, uh, one of the other advantages that we see that unfortunately some of the competitors don't have outside, um, is that you have the ability of, for different types of events that inside AOL is supportive. So, you know, you as dev ops engineers, they tied them up to scheduling, they tied them up to events coming in from a message queue. So these are workflows that are created get, uh, triggered by these events, which, uh, you know, makes it possible for them to execute at a certain time or for a certain event that gets triggered. Right? So, uh, again, uh, re-usable, uh, Automic workflows and actions that Michael just demonstrated along with, um, having, uh, both engineers and the both engineers, both application developers and dev ops, and I kind of stress it out because how flexible this is, right. Um, for them to define it one time and then have it reusable whenever they want. Right. >>I'm just curious, what's the biggest surprise when you show this to people in the field? Um, what do they get most excited? >>They love it. I mean cut. They immediately say, how can we start using it the next site? Right. And, um, it's, uh, you know, we also have a cloud center suite has a SaaS offering where it's, uh, made it very easy for us to, uh, get them a trial access. So that they can come in, get their foot wet, you know, and try it out. Right. And once they start doing these calls and building these workflows and uh, as a Michael demonstrated these actions where they perform API calls at the very least, right. Uh, they just get hooked to it. Right. And then start using it from their answer. Right. >>Mike, what about you? What's your, uh, what's your favorite response from, from clients when you demo this? W what's the one, two things that really, uh, that really grabs them, gets their attention and gets a big smile on their face? >>Yeah. Well, first and foremost, you see people's minds spinning on, like what use cases have been bothering them that they haven't been able to, to, to like fix, you know, because maybe they're not programmers or maybe they are, but you know, it's just, they thought it would be too complex and too much work. So, you know, I think it's just, it's, it's so open-ended, but you just, the interest in people's faces. It's like the first time, you know, I have a three year old, it's the first time I gave him Legos and he's like, you, I can build stuff. I can do stuff myself. I mean, it's just like that. I mean that's the amazing part of it is that it's so extensible and to build on to what Ali was saying, uh, you know, there's so many ways to trigger it too. So this can work standalone and work by itself. >>Or it can be triggered by an API call. It could be scheduled, it could be called from workload manager. It can be, uh, you know, it can be triggered from a, you know, a rabid. It could be triggered from PACA. There's so many different things that you can do to trigger these workflows that it just makes it so that it can integrate with other products and you can integrate other products. Right? So it really becomes that glue that kind of ties everything together. I mean, we really, really think about it as building blocks or Legos or something like that. Um, it just is really extensible, really easy to use. And you know, we think it's a real game changer. >>Great. All right. All a last word. Where do people go to get more information if they can't see that cool demo on that DVD screen on their phone? >>So, um, we definitely recommend them to go to cloud center suite. Uh, you know, if you easily Google it on Cisco, uh, website or on Google itself, you know, you'll see it, uh, apart from, uh, first or second links. But definitely check out CloudCenter suite action orchestrator is where you would like to visit and learn more about this tool and this component. So. >>All right, well thanks for, uh, for stopping by and uh, thanks for joining us from New Jersey, Michael. Oh, thank you. And I'll send you a cheese. All right. I'm, I don't know if I want that in the mail, but we'll see. We can make fast shit, but all right. Thanks again for stopping by. He's only T's Michael. I'm Jeff. You're watching the cube. We're in our Palo Alto studios. Thanks for watching. We'll see you next time. >>okay.

(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)