 from our studios in the heart of Silicon Valley, Palo Alto, California, this is a CUBE Conversation. Hey, welcome back, you're ready. Jeff Frick here with the CUBE. We're in our Palo Alto studio today for a CUBE Conversation. Did a little bit of a deeper dive into the Cisco Cloud Center. We've had an ongoing conversation. 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. It's probably 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 Chenitz. 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 cheesesteak 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 Cloud Center we've been talking about for a while but today we want 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 Cloud Center 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 info 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 Cloud Center suite. 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 or all the way up the stack to the application where if your product requires an orchestration engine in the backend 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 could think of. It's, you know, it's extensible. We're gonna 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 wanna go. And what I have here if you can show the next video is just a little clip of what it would look like go through a workflow. Okay. So let's cue that up and we'll take a walk through it. Let's go to the video number one guys. All right, so. So what are we looking at here? 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 gonna show afterwards that those actual VPCs and subnets were created by using a flow. So what we're gonna 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 we can create, you can create them in minutes and we're gonna 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 information that you'll see on the right hand side. And this information is how you configure that particular action. So this particular one is gonna create a VPC and you can see the VPC name, you could see the VPC subnet 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 of parameters. And one of those parameters, you can see the first one is just a name. The second one though is actually using 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 can then run. And it will actually, we're going to run hit validate here. It just validates the workflow. But once we click run 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. 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 that all the information that you could possibly 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 can 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 them 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 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 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'd, sorry, the way that I phrased that VPC or that subnet, I'm sorry. And it caused a 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 they run from the command line, which are great together, but what we find is that, there's no central orchestration. And what we want to provide is that central orchestration that could run those other tools and also schedule them together. So if you use other tools besides AO, that's fine. Well, 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. Yeah. Correct, I mean, that was a good demo. And 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, 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 cloud center 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 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 their 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. And so does a lot of things come packaged out of the box or standard processes, standard workflows, standard processes. And then what do they code it in? And 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, right? 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 DSL which is all JSON based, right? And the DSL 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. So. I think, Michael, you're going to show us a little bit more on that and how to 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. Okay, pulling that up. 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 slash 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, they'll call it slash sheets. It doesn't take a brain surgeon to figure this out. So really I did slash 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 smart sheet category. So if you could imagine, I had a lot of these smart sheet actions. I could just put them all into one category. Well, 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 could 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, or smart sheet, list smart sheets. And what it's going to ask for now is a token, because you need a token in order to authenticate with smart sheet. That's a smart sheet 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 we'll go back out into here and I hit run. And you'll see that I created that action. I brought the action into workflow. I ran it, it's running. And now it's given me that exact same output that I would have gotten 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 in the box now. Very slick. And so that was with smart sheets. How many connectors do you guys already have pre-constructed? 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 Ollie, is this something that people are going to be working on all the time or are these pretty much, you know, 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 templateize 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 built 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 supportive. So, you know, 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, you know, 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 both engineers, both application developers and DevOps. And I kind of stress it out because how flexible this is, right? Right, right. 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? What do they get most excited about? They love it. I mean, they immediately say, how can we start using it the next site, right? And it's, you know, we also have Cloud Center 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, you know, 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, right? Right, right. They just get hooked to it, right? And then start using it from their own side. Michael, what about you? What's your favorite response from clients when you demo this? What's the one, two things that really grabs them, gets their attention, gets a big smile on their face? Yeah. 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 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 so open-ended but you just see 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, I could build stuff. I could 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, you know, there's so many ways to trigger it too. So this can work standalone and work by itself or it could be triggered by an API call. It could be scheduled. It could be called from workload manager. It can be, you know, it could be triggered from a, you know, a rabbit empty. It can 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, you know, 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 litty-bitty screen on their phone? So we definitely recommend them to go to Cloud Center Suite. You know, if you easily Google it on Cisco website or on Google itself, you know, you'll see it apart from first or second links. But definitely check out Cloud Center 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 stopping by and thanks for joining us from New Jersey, Michael. Oh, thank you and I'll send you a cheesesteak. All right, I don't know if I want that in the mail, but we'll see if we can maybe send some fast shipment. All right, thanks again for stopping by. He's Ali D, he's Michael. I'm Jeff, you're watching theCUBE. We're in our Palo Alto studio. Thanks for watching. We'll see you next time.