Cisco Network as Code: Self-service Network Operations

Oh, so how do we kind of go from, working on individual configuration files? How do we trying to think about different people who might want to try.00:00Find use some of the automation that we've got. So it's with all of our sessions, we're not trying to sell anything as part of this, but it's something that we see a lot of our customers who, you know, brought into ACI or SD WAN or any of the different domains are wanting to to do to put into practice. So really the the goal for the session is that we we talk through some of those decision points.00:20That you might need to think about as you start building self service capabilities. I'm gonna be using an open source self service tool which I'll share and I think it's links in throughout the slides. And then we're gonna be doing demos as we talk about some of these topics as well.00:40So as always, if you have any questions, just feel free to put them into the chat. I think Razor's gonna be helping us with answering some of those. We've also got some time at the end in case there's any longer questions. So if any of this is something you know that you're, you're working on at the moment, it should be something that we we should be able to answer either in this session or you can contact us afterwards and then we'll.00:56We can help you through that as well.01:16So the the 1st point is just to make sure we're all kind of on the same page in case you haven't joined any of the previous sessions is when we talk about network as code, we have a pretty much a standardized architecture where we have underlying that there's some element of Cisco infrastructure involved in what we've done throughout all of them is we've tried to.01:18Abstract them so that you can try and describe all of the, the infrastructure in a standardized way. So the way we might try and talk about, ACI configuration or we might try and talk about SD WAN configuration starts to look the same but the actual conflict's gonna be different, right? They they do different jobs, but actually the way that we can then use.01:38Different tools around it to do validation and different tools in order to do the deployment, start to become a bit simpler. In today's demo, i'm using XRD mainly because it's really easy to set up, it's just a little container in our environment and we can use it there, but we could be doing this for any of the different domains that we've got.01:57The next level up from that is that we need to have somewhere to store our data. In our case today, I'm gonna be using a GitLab instance that I've got hosted just to see implementation for that. And then we're gonna be using terraform, and the network is code modules for that one as well.02:16So when we look at the layer on top of that, I'll be discussing this a little bit, but I haven't included it into the demo because what my plan is, is to make the code from the demo fully available. So if you want to stand up your own self service instance or just start playing with some of this stuff, you should be able to do that. Nac API is one of the things that we've created as part of the services code.02:33Offering, which is the the one that we deliver through professional services.02:53And that one is we'll discuss it, but we won't be including that as part of the demo basically. But the goal behind that or what we want to do is we need to be able to simplify integration towards northbound systems. So if we're gonna start having ITSM integration or we want to start offering services out or we want to start interacting with agents, we don't necessarily.02:57Necessarily want them to have to build static YAML files every time and understand the schemas for for everything involved. So we created knack API to kind of help us in that space as well.03:17And then the layer on top main kind of use cases as I mentioned, ITSM self service, the different ops methodologies. Today we're looking at self service in here. I'm gonna have a look a little bit on ITSM next week when we do some of the, the agent sessions as well. So the 1st question is why, why are we looking at self service? Like.03:28Who is it that we're trying to build for? And the reality I think a lot of us have to face is that when we are automation oriented people, not everybody's like us, you know, not everybody wants to consume technology in the same way. You might have people who've been very used to, to operating in a certain way or you know maybe you've got a managed service provider.03:48I'm in place where, you know, they're doing elements of the job and the contract something like this. And so the way that we want to use technology is, is gonna be different depending on who's gonna be using it. And so when we look at an architecture like this, this is a very simplified platform architecture, we can consider all the different resources we talked about before, so SD.04:07All that kind of stuff, and then more, you know, we're gonna have lots more than that when we look at enterprise architectures and have load balances with people like F five and you're gonna have maybe, you know, you've chosen checkpoint or it's your firewall or PA. And so you're gonna have to try and figure out what's the easiest way to do operations across all of that. And so this is an architect.04:28So that we look at as part of platform engineering, which is we say we treat all of those things as resources, we make all of them available via an API or some kind of adapter, and then all of that is then usable as part of some portal. So in platform engineering it's called an IDP, but from our case today we're just gonna have a a simple self service.04:47So there's three personas that we tend to focus on, the user that somebody that just wants to consume the service that you've got that could be non technical kind of person. You might have a developer that is technical in their own domain, but you know doesn't understand how networking works.05:06And then you might have the people who are actually gonna manage the the infrastructure themselves so the platform teams. And so for the platform teams, maybe the the traditional get OPs kind of methodology works really well for them. They might be you know more than happy doing this and self service is massive overkill, but if you spend quite a lot of your time dealing with requests from, you know, people outside of your immediate or.05:23Organization. I know I work with a bank at the moment that they worked at about 70 % of their time. It's just trying to understand requirements given from others. So I want a new branch put up in this location and they need to figure out, ok, what kind of templates do I need for, for SD WAN for that and you know what kind of profiles do we need to set up?05:43And all of that kind of thought we want to try and reduce as much as we can do and we standardize it and create these things for golden paths.06:03So in this example, we're gonna be looking at a very, very simple self service portal, and then we're gonna have a little use case around creating a loopback interface. So just as an indicator rather than everything that we could do. So I'll pause at that point and just show you the environment that we've got. So just to show you the the setup that there is.06:10So this is all running as part of a dock a large docker compose file basically. We have me accessing this information via proxy service, and then we have open self service here and I'll I'll go to the Git repository in a second. This is a public repository for building self service portals. You might.06:31For you guys that you say actually maybe Ansible Tower is a good place to do this or if you do an AAP, you know, that might be a useful thing for you. You might say actually what we want to use ServiceNow in that domain, you know, it doesn't really matter too much. You know, I have a customer at the moment who's doing backstage. It's whatever works for your organization, right?06:51But all of them have got pretty much a very standard setup is that we've defined who our users are, we know what they want to do. Here's some kind of form interface maybe or chat interface, we've got the ability to store all of that and then we've got the ability to trigger workflows afterwards and after they request.07:11In this setup I'm using GitLab C as I mentioned, I've run a few different pipelines and then we have a runner and are you sharing something now because we we see only the what actions do we need to perform? I don't know if this is what you wanted to share.07:28No, that is absolutely my fault. Yeah, now it's good. You good? Yeah, now, now we can see that you are sharing the camera. Yeah, lazy gitops, ok. Hey you saved me David, thank you very much.07:44So yeah, just to explain what we were talking about before, proxy, open self service, pipelines into GitLab, and then we have a runner. So we actually have two in this case, one of them's running ansible, the other's doing terraform. They both got some different tools for doing validation as part of that and I'm gonna be going directly towards XR, but we we do.08:01We actually have set up for lots of different S codes, so if you're interested in any of these ones, you know, feel free to ask any questions. We we can kind of cover some of those, it's NO problem.08:20So, right, so that's the overall setup. So what actions do we need to kind of perform, right? And so what when we're talking about the, we've defined, you know, some kind of thing that we want to build, what do we have to do as part of that? And it's not quite as simple anymore, it's just.08:30You know, being able to say put in this network configuration for the device because am we still sharing David, sorry I've just got a mark saying, do I need to resume? Everyone sees ok? Yeah, you're sharing.08:48Thank you. So we have the this the same process that we would normally have with infrastructure as code where a file is updated and then based on that file update, we're gonna trigger a different workflow. We're gonna have a deployment with inside the different domains that might be interesting to this request, do some testing validation.09:04Has everything kind of worked ok? And then are we gonna notify, you know, based on that? Now, when you do different types of requests, the actual workflows that you're gonna go through are gonna be slightly different. And so if you're gonna be doing something at a single domain, you know, with a technical user focus, maybe it's fine, you know, to focus on one particular area.09:23And that you expect that they're gonna understand IP addresses, maybe they understand VLANs or, you know, some of those kind of attributes that we would normally have within networking, but if you're doing something for a project manager, you know, we're not gonna do that at all. And so in those kind of scenarios, we're gonna build slightly different workplace than what we would normally have. And so you can see an example.09:43Example of that here. So if we have a look at portal, e.g., so this is one I use for deploying SD WAN, and again, all of these kind of kick off different.10:03A pipelines within GitLab, but here's an example for configuring a dual VH site. So if you're a project manager, e.g., you might get information that you know, you know, you're in Manchester, yeah so what's the new address for.10:13Say we're gonna be doing something for Andy Bernon. We can select different users, maybe we want the dates that something needs to occur, something like this, right? And then based on this information that we've got, just fill this out with my details. Based on this information that you've got, you're gonna kick off a different kind of process, right?10:32You know, we didn't ask them really at any point there about IP addressing or any of the kind of networking information that we would normally care about, but we can auto create some of these elements. So we said, ok, this is gonna be an IP address and a gateway and you know some kind of template we might use for this, right? And so.10:52Let's just submit this Hopefully it works. Yep. So it's gonna pull up into a different pipeline. And so for each of these different requests, we're gonna have our own different workflows. What's really important when we're building self service is that we have the idea that we've monitored what's happening at each different stage. So we need to do a lot more.11:10Observability, you know, this is something Raz was talking about quite a lot last week. We want to be able to know who's made the request, e.g.. Do we want to trigger, a different.11:31Workflow to notify somebody or do some kind of validation, right? So the the goal for all of this should be the process is really well defined from inputs, all the different stages throughout and then execution. So if I just pop back to just another quick example for SD WAN, if we are a network engineer, we need to have a portal that's gonna be able to give us more.11:41Different information. So here's the same thing a V Edge. So we still ask for the site name and all this kind of stuff, but maybe you want to have a different IP addressing or different kind of.12:00Information that you would need in order to be able to actually do something. So we've now got two different personas who are using the same platform, but we can request slightly different services that we would normally do. So just to pop back to this. So when we talk about that kind of validation, that that's really important as well and I'll touch that in a second.12:12When we start looking at the demo, but what we're gonna find actually is that the way that we deploy with inside these environments is going to become quite structured, and in this case we're doing multiple levels of validation here. So when I was describing before that customer, you know, the, the bank that I was referring to, they have to do a lot more validation than they normally do when they received.12:32Receive all the requirements from the end customer because what when you are an engineer and you you you can kind of build a solution for yourself, you do a lot of that stuff for you, you know, you kind of make sure that there isn't any funky mistakes or, you know, you'd hope that you do that. And so we need to kind of build this stuff into code.12:52And for me, this is the biggest opportunity that we're seeing with a lot of agentic use cases is starting to build and analyze some of that data. So actually in the workflow we'll be looking at today, we're doing some LLM review of the Terraform plan output, which is basically telling us what we're expecting to change and to kind of try and dictate.13:08And some of the behavior that we see behind this.13:28In this case we're using both these things, so we have NAC validates and then some analytics as well for when we're doing ACI in this space as well. So what we've got now, just to be clear, we've got some kind of front end with some self service portal. We have some workflows that we're gonna define. For me, I'm using GitLab CI, and then throughout.13:30All of these different steps I'm gonna use different elements of network as code and some different open source tooling in that space as well. And then by the end of it, what we should have is the deployment that's you know appropriate for the different requests.13:50So, how should we describe this? So this to be honest is was the biggest difficulty that I had when I was starting to to move from automation into some level of orchestration when we were doing some kind of abstraction that was gonna make sense to other users because it's really quite hard to be able to describe what you want to do.14:04How do you try and merge that request into the existing database that you might have or different file structure you might have? And then how do we try and make it so that we're not gonna cause conflicts when you have multiple requests that come in place? There's some of the big problems that we have in in this area. And so what we do within network as codes, so very.14:23Generally we we take what was a relatively verbose or quite complex sometimes configuration that we have within terraform. And then we we simplify that as much as we can do into YAML files. And the reason we do that is purely so that we can understand very clearly what we're doing. There isn't a big jump for people to start to understand this because.14:43You know, I don't mind what area of networking you work in? I'm pretty sure you can read this file and kind of understand what is it that it's doing or what is it that we're trying to define?15:03And then once we've got that kind of YAML structure, the way that we work, oh sorry, I'll talk about that in a second. So for some people, they they might be very happy with that YAML structure, we've touched briefly before about the self service capabilities and if they're not happy with that structure, so what do we need to do in that case? And so we can create.15:13Two different interfaces, one of them via the self service and one of them could be directly towards getting.15:33Now the reason that's useful in the the architecture that we're working on today is that you don't have to then duplicate things in between. What you really, really don't want when you're building this stuff out is two completely separate processes because firstly you have to maintain both of them. The secondly, it's gonna be confusing to people actually what's gonna be, you know, what's what's gonna happen.15:38So in this case what we're doing is we're making changes directly to GitLab via the self service portal or we can make changes to the YAML files directly to the same Git environment as well. Now I mentioned here earlier before, we have this open self service i'm using today.15:58So I'll just show you this. This is a public resource I use it a lot for demos, that kind of stuff, but it's actually pretty, well written projects and it's managed by this company in Poland. I think they put their names at the bottom. Yeah, this highcomm digital, so well done to those guys, but it's really, really useful for me at least for kind of spinning up some.16:15Examples, so it gets you started on on how that works. So if you're interested to kind of do this on its own, this is the one that I'm using. It's very useful for those kind of demos or proof of concepts or that kind of stuff.16:36So just to pop back to this. So just to be clear, we've got two approaches, config or we can do self service. So in terms of how we kind of structure that part of our data, what is it that we we can use is we have the, the configuration that we would normally have. So in this case, it's ACI configuration for.16:48I'm a Cisco live tenant with some different tenant specific configuration for ACI, and then what we were able to do is within the the main file for terraform, is we can say actually what parts of the configuration do we want to configure? So what I do, e.g., is if I want to set up a self service approach, I'm not going to allow, say e.g..17:08Interface with sorry infrastructure related configuration changes. So you might limit it actually to within the description to only allow tenant based configuration, and we can start to at that point what we're doing is we're trying to restrict already the the the issues that we might have when we start letting other people make changes into our own infrastructure.17:29At a really easy way. So because we've separated up the the data from the the actual code element of things, it's it's easy to do. When you're doing it and it's tightly coupled, you know, you've kind of written scripts or maybe you haven't been as.17:49I don't know, forward thinking maybe when you were creating some of the automation, it's hard to separate data and the code, you know, afterwards. But actually if we use this kind of approach it sounds to become a bit easier to do quite a lot of different stuff.18:03So in this case, just to be clear, we're looking at a single directory at the moment and we're saying you can do everything. In reality, we're gonna restrict that where we can. Now, because we've started to restrict these into different segments, one of the things that we actually do when we build things with networkers code is we restructure all of the configuration again based on the YAML files that we.18:19We've to find. So if you look at the previous example, we're saying look at everything with inside this data folder. If these two files are here, what we're gonna build is a structure that we would then merge the two together and that's really, really useful because what again when I started doing this kind of stuff it's really quite tricky in order to do merges properly and how do you kind of make sure that you.18:39Describes the configuration effectively and you can see an example of that here. So I'll just.18:59I'll just pop to this one so you guys can have a look what we've got. So so this is a repository that we're looking at XRD, and so it's just set up for this example, but we have this data folder that we we talked about before. And so with inside of it, what I have is some inventory data. So it's a this is the device that we're we're looking at just a single.19:05Device. And then with inside of it, what I have a multiple sets of YAML files. So here, e.g., we've created loopback a hundred, we've created 9199 and then each of these have got snippets of configuration. Now, what this means isn't this is just an indication so hopefully you understand that part.19:26And we can break apart our configuration into different segments and that makes it really useful for when we want to start doing service requests cause you can see exactly what the user's requested and we can look at the the specific snippet. It's really, really tough to do this when you files 3000 lines long. So it's nice that we're gonna do this rebuild as part of the actual process as well.19:44So back to this one. So that's what we're talking about with the different separations, right? And then the next part of the the challenge really or what we want to kind of look at is how do we scale the solution to work, across very large domains. So maybe if some of you guys are already working on Terraform solutions already, you might know the.20:04Answer to this, but when we start to to monitor the state of a very large infrastructure or we want to kind of describe a very large set of infrastructure, it's difficult in order to be able to do that and still be fast. And one of the examples we always kind of give is there was a customer who described their entire data center. It was ACI based and they didn't do any.20:24The Optimization at this point, they were just trying to get it you know written. It took 13 h to build, and that was across all of the different configurations had lots and lots of leaves, you had to configure each of the different ports that was there, all the EPGs contracts, everything like that.20:44And so in that scenario, automation hasn't helped you at all, right? You know, I don't think any of your, you know, customers or people that you work with will be willing to to sit for 13 h after requesting a simple thing. So we need to look at how we can try and optimize some of these things. That particular customer after they've looked at splitting up their state file.21:00While and kind of increasing some resources and doing a bit smarter things with their pipelines.21:20They went down to about 40 min, so they could do a complete DC build in 40 min, which is you know, I think we can also say that's an acceptable time to to build a full data center, but it's important though that it's not just that we start using Terraform or Ansible or whatever it is and it's gonna be fine. Like we need to really think about.21:25How we can try and optimize this as well. So to talk about scalability, what you'll see that's slightly different from that data folder we just looked at is the concept here of workspaces. So in this regard, what we've actually got is we still described all of the different data files with inside of this directory repository, but what we've.21:45Created now with these separate workspaces for different tenants. And this means that for when we want to make a change to the production tenant, e.g., we've isolated part of that configuration. And that's a really important concept when we're looking to build, service portals because what you can do at that point is split the configuration up into smaller blocks. So you want to.22:05Say you can make changes to the deaf tenant, e.g., by a standardized process, but you're not allowed to make changes to production in a standardized way. We can now use Git and we can use these kind of functions within Terraform to enforce that for us. So we stop people from being able to make changes outside of the domain that they might be working in. So on top of the.22:25Performance benefit you get with this because it means we don't have to track the full state for every change. You also get the security benefit as well, which is a very handy thing to do.22:45So, just to be clear, single safe files not very good. You you don't want everybody being able to make changes across everything or every change to affect everything. You want to be able to try and run changes in parallel, so if you have separate tenant configurations in ACI or within SD WAN, you're making changes to different sites, e.g..22:55And you want to be able to try and do those concurrently so people don't have to wait. And the reason for that one is most of the time people's expectations of when you build a portal is that they want it to be similar to if they go to something like Amazon or Google or whoever, they say if you're gonna have some kind of private cloud or you know you've got some infrastructure that I want to consume, they want to.23:14To be fast. And so I think that's one of the things that we should have in mind that whatever service we're describing, whether that's, you know, I want to have.23:34Connectivity to the internet for this particular IP or, you know, I want reachability from one location to another. Any whatever the the use case is, there's always gonna be an SLA element of things. So are you gonna do that in 40 min or, you know, at the moment does it take three weeks? And so we need to kind of factor that into the different service we build as well.23:43And also you you don't want to make it overly complicated about what you're doing. So if we just pop back also to this, gitops portal here, so if, if you gave a, you know, project manager a template or you gave anyone a template that said, you know, please enter these ten IP addresses, I think at that point, you know, we.24:02You know as designers or you know kind of automation architect because they don't want to have to understand all this stuff and what you've done is you've opened up another avenue there to start making mistakes, you know, to start.24:22Typing in the wrong IP addressing or all this kind of stuff. So what we actually want to do in most cases is we want to use default values, so we only give them information that's gonna be unique to what they want. And for things like IP addressing, we really need this point should be dynamically pulling that data from some IP address management service. You what we actually want to avoid.24:36In nearly all cases of automation, when we're looking at.24:56Sources of truth is we don't want to have the same artifact written in multiple locations. So you don't want to have like today even you don't want an Excel file and you know SolarWinds and some of the monitoring service because when one thing changes, how do you go and change it across all of them? It becomes a bit of a pain, right? So.25:00Ideally what we want to try and do is dynamically pull variables from a single source of truth. So in this case we're talking about IP addresses, so it could be something like infoblox or netbox. And then things like VLAN IDs as well, that's a similar one, maybe Netbox is a good solution for that. And then we can actually integrate that into our pipelines ourselves, so we make it as simple as.25:20Possible for the user, and then we actually make it as simple as possible for us to build the the automation.25:40So just talk about the the defaults again to close that one off. In this example what we're doing here is we're setting up this idea that we want all of the names of our bridge domains to be have a suffix of_BD. Now you can create quite complex defaults. You could say actually, you know, you're gonna standardize the majority of your configuration. That's usually.25:46Good thing to do that because what we don't want to have is we discussed kind of before is we don't want to have these 3000 line monster configurations that describes infrastructure. We want things to be easy to understand simple for people who aren't maybe automation focused and easy for us to change what we can do. And and that's kind of what the.26:06The approach generally here is what you saw with the merge at the beginning and, you know, part of the scalability and separation so far. And now defaults is that it should be easy for us to create new configuration and to remove it again. So that's one of the biggest challenges that we actually see with customers is not necessarily creating configuration. It's creating.26:26The configuration after others has already existed. So I'm doing the work with a service provider at the moment and they're hitting a VLAN limit and the their problem is they don't know what a thousand or almost a thousand VLANs that they've allocated, whether they're still in use or not, right? So with this kind of approach it becomes a lot easier to understand that as well.26:46And, ok, so so we talk about some of the scaling elements as well. We took, We touched scalability in in terms of performance before in terms of how it actually works and some of the data sources you've got here. So this is an example for the netbox. So withinside netbox, what we have a.27:05Few different VLAN IDs. We have some a snippet of configuration within ACI.27:25And then as part of the, the main file for for ACI in this case, we say go to this directory to get the YAML files, but also you're gonna go to this location in order to get information from netbox, right? And so for after we've got that, we've now got that as part of the configuration and we'll import that whenever we want to make a change. That's a really important.27:30Something because it's difficult when we're kind of trying to build these productized services about where we've defined different configurations, right? So it should be in your mind that we want to have as simple as possible and we should be trying to integrate towards these other devices where we can do as well.27:50Now, lastly, before I go into some bit more of the demo, I wanted to explain briefly about the the NAC API elements of things. So what we have here is the the infrastructure that we talked about before, we have the the different types of domains.28:09That you might be, you know, working with, maybe you're working with terraform or Ansible, you know, it doesn't matter too much, but if we don't want to expose that directly to other people, what we've created is this thing called the network as code API and that offers different interfaces. So you have a REST interface so that if you have a ServiceNow team e.g..28:24Or you know some other ITSM team instead of having to explain how the configuration looks like for ACI or whichever they might not care about, you could say actually well this is the.28:44The rest interface that we have. This is the schema for the data that we would expect, you know, build their own integrations into that as well. So, so that's quite a nice tool that we're finding to, to really speed things up with some of those teams because for you, you know, you might not own absolutely everything, right? You might only own a portion, whether it's the info.28:57Structure itself or or maybe some of the the the management systems at the top but but not everything. So.29:17If all you wanting to kind of do is to start a project with a team who owns ServiceNow, e.g., that's something that's gonna really help you because you don't have to sit there and manually work out all of those integrations in between. Now I'm gonna go through and show how the demo setup is working now, but I think, yeah, that's all the kind of slides.29:24I wanted to have a look at. So I'm just gonna pop NO questions so far. Okay, I was gonna say I was gonna answer some of the questions but I think we're, we're ok for now. So in terms of most of the things I've been talking about for this slide so far, nearly everything is gonna be here for you on nettiscode.cisco.com. So if we just pop to that.29:44Here. So if you're starting and you you know you want to kind of understand how some of this works, there's explanations for all the different components. So this is e.g., I'm picking ACI just because it's at the top, but it kind of shows you how to actually do a lot of this kind of stuff to begin with, we have sandboxes for, for all these environments.30:04As well. But then actually if you go to guides this answers quite a lot of the questions.30:22That you might have when you when you're trying to design your own network as code set up. So a lot of this information we talked about before with separation and how the merging works between different, between different file structures, that's all explained here as well as some of the deployment related topics about how we might want to try and do.30:27Sorry, I'm going through these quite quickly. I appreciate you might not be able to see all of this, but if you wanted to look at scalability.30:48Practices and how you might try and do that. We've tried to document it here and pretty fully as well. So that should be you know fairly useful for you for when you're starting to work with some of these as well. So if I just pop back and we'll have a quick look at the demo. So in this case what I've got is, we're looking at SD WAN, but I've also got a really big.30:55And so it's on purpose really dumb, right? So this one here is a single device, we're just configuring a loopback and we're putting in a different range. And so we're assuming that whoever's filling this in knows.31:16An IP address that they want to configure and they know the information that they've got. And so this use case for me is really for people who don't want to start working with Git. You know, they just want a simple portal that they're able to start working on some of these pieces with. So we can create an example here.31:28What address should we give it? 99 as well and then we can deploy. And so I haven't done any really validation at this point. So we could do kind of front end validation, e.g., on the contents of the different variables that we've got. We could say actually we don't want to kick off a full pipeline until you've done the validation or had something approved.31:47You know, you can start to build all this stuff into the portals yourself, and then the step that happens after that is probably where we start looking at things like billing and, you know, access rights and what people are able to actually perform. But if we just pop into get.32:06Assuming the demo gods are being nice to meet. Yep. You can kind of see that we're running an instance of it here. And so what we've got in this case is we have a series of different steps that we're gonna use, to, to validate, to make sure that everything's gonna be ok with with what has been proposed, some level of review, and then based on the.32:21Review itself, it's gonna tell us what kind of deployment we want to do. And I'll touch how we do that in a second.32:41But just to show you an example of from this, if you look in here, we've created this loopback interface that we'd we'd specified kind of before and we have all these different files that are gonna be, you know, end up adding. When we remove the service, we also want to have the opposite. So you want to be able to know for this particular.32:46Ask what have you added? So then if you want to get rid of that service, how do you then try and take it away, you know, to get rid of that?33:06So we pop back to the pipeline to see what we're actually doing in this case. So the the 1st thing that actually happens is we wanna start validating some of that content, right? So in this case what we're doing is we're saying, go and have a look to make sure that the format of the terraform that we've created is correct. Now we could do a step even before that. We could say, you know, we have a particular.33:14Formats maybe we want to have a look out of the the files, sorry, of the variables that are being created. So I don't even want you to be able to create a YAML until we've checked that, e.g.. But in this case what we're doing is we're saying does Terraform look ok? And then we're using NAC validate and then we've got a set of static rules here that we've defined. We also could have.33:35A schema that kind of describes the infrastructure. Maybe if I just pop to another repository, I can kind of show you what that looks like to. So if I just pop back in this setup we've just got loads of just test deployments. So.33:54Sorry this one. Have a look at something like I've got a schema in this example. So just to be clear in case you haven't come across this before, schemas essentially describe what we expect some of the variables to be. So in this case we we're configuring under VXLAN, we should say actually this element we we absolutely have to have.34:13Have as part of the YAML files that we want to build, and we give a format.34:33So e.g. here, this is a regex pattern that basically says it can be any alphanumeric numeric character and that's fine. You could say e.g. that you wanted to have fit a certain pattern as part of your schema, and so we can enforce that very early on because what we don't want to do is we want to accept a request and then it takes an hour.34:37To figure out that, you know, we've done some kind of stupid mistake at the very beginning. So in this context, we're not using a schema, but if we were, that's pretty much how it would work. We would define the schema as part of the, the, the setup here and we'd validate at the very early stage as well.34:57So let me just pop back to XRD where we were doing the change, our pipelines again, and we can see we're pretty green all the way along. So we've done that initial validate and then what we go into is the actual plan. So a concept within Terraform is that we want to be able to.35:14We want to be able to describe what the change is gonna be in advance. So in this case what we're doing is we've actually removed one of the other loopback interfaces that we'd already created and we're gonna replace it with this one that we have here in 99. And it's because the I would actually.35:34Yeah, and with with the new one that we've created. And so based on this kind of change, it might change how we want to interpret it. So we could say actually for very simple changes as part of our pipeline, we want to approve those, you know, we don't want to put any barriers in front of people to doing that kind of request, but if it's a very complex change or maybe something outside of the.35:52The domain you expect that person to be in, you wanna stop it at that point. So we can enforce all of that into our environments.36:12As well, so you can kind of see we've done the plan. We've created an output for the plan that we're gonna use in the next step as well. So plan review. Now what I did in this case was I took the the plan review and I passed it to a Gemma four model with inside Alarma.36:20So on this machine, I'm running alarma locally, and then I have just a single model in place to do this. Now, the reason I'm doing a local version is because I can bundle all the demo together, so you you could actually use whatever your you know kind of corporate or organization approved models could be for this. But what I would recommend.36:40Because you don't just do this, so.37:00At the moment, we're still at a stage where I think we're not fully confident as to how to use different agents as part of automated workflows. And so what I'm doing in most cases is I'm using them to give indicators. And then I'm using some of those static tests at the beginning that's enforce a particular.37:02You know, outputs than I would expect or, you know, say I want this particular file format or I want to make sure that it's not gonna delete, you know, configuration outside of that. And then I use these kind of AI tools, which maybe I don't know if you can see that whether it's a bit easier to see if I zoom in.37:22Yeah, and it's given me some output. Now this is really important because what we're able to do in this case is we we're going away from the I have to read a thousand lines or you know read quite complex syntax to understand what's going on. And you can look to see actually what the impact's gonna be in a in a relatively a simple way.37:40So we're destroying this resource and we're creating a new resource validation was clean, NO failures on the network, but because we're.38:00Getting rid of an interface, it might be important. So we're going to say require human review, e.g.. Now, I can't remember in the setup if I just set it up for low and high, so we'll have to check what the deploy was. Yeah, ok, so as long as I haven't screwed something up, it should be deploying into regular one.38:11Yes, ok. So we've gone into auto and what it's done in this case is basically said that it's not going to execute as part of this one. So this is a an issue with inside the lab. It shouldn't have executed this job at all. But what it did do is it went off into the deploy manual. So we'll have a look just quickly on this.38:32This is a fail. It shouldn't have done this within the lab, so apologies guys, you shouldn't have seen this. What what it should have done is it should have paused this deploy stage where we had a manual action in place. And so the reason for that was it categorized it correctly at medium. I I hadn't tested a creation and the deletion at the same time. I'd only tested the hide, but it should have.38:54Of this step, so actually we would be able to review the contents of the previous request. We should be able to go ok well yeah this is ok. Maybe that needs human intervention at that point. And then we can get move on to the next step. In this case what it did, it incorrectly automatically deployed and then did the the the full phase.39:14So what I'm gonna do is I'm just gonna pop back to one of the other elements. Oh, it looks like I've broken it a few times. Ah, you can see it here. So in this example, I imagine what it's gonna tell me is I have a high and request. Ah, NO, this is just wrong. I'll fix this for the demo, so if you guys are gonna run this code, I'll I'll.39:32We'll have it separately so you can have a little look at how this works as well. So passed, here you go.39:52So what we can kind of see here as part of a normal deployment is that we've taken the Terraform plan that we had before, and then we've gone and applied the configuration on the device. So you can see here what we've tried to build as part of this as well. And then we have some basic information. In most cases what we would usually have here is we need to let people know, you know what.40:00Happened. So that's where we have integrations towards other 3rd party systems or Webex or quite crucially what we should be doing is updating the portal or whatever we're using.40:20To indicate the service that it's been completed, that it's finished. And so in this case I think what the last one is, we're looking at yeah is we're creating the reporting that we can then share with other people to kind of let them know.40:31What's going on? Again, I was using another LLM in this case to review the output of some of these files. It looks like.40:51It looks like because it's empty it's not able to review it. No, you know, we probably should update this so that we were able to kind of pull some different information to to see what's working. But in the whole what we've done, so if I just open up the validate.41:00In how what we've kind of done is that we've done some level of validation from the request that's been received. We've automatically rendered the YAML that's been produced here. Now you can you don't need to use NAC API in that case, you can build your own, like I'm doing in this case, I'm just rendering the YAML directly from the self service instance.41:17But if you do use NAC API, it's a lot easier validating it, we're doing a plan based on that and then some level of review. It's at this point that if I had properly written my CI file, we should have seen the two different deployment types.41:35So the goal should be whenever we're creating a lot of these self service capabilities is that we don't want to get people involved as much as we can do. You know, you don't want to have to wait a week for a proper review or you don't have to treat everything as a custom project. Once it's a standard kind of change, we'd like to see automatic deployment in that space as well. And we can use tools.41:48Just like different AI models in order to help us for this or we can also categorize with static tools where we've developed rules and tests and that kind of stuff as well.42:08Just to show you this one as well, because I don't think we've touched on that one so far. In terms of some of the rules and how we set those things up is we have, as part of this setup is a very simple one where we're saying actually we want to make sure that all of the addresses, e.g., are in this range. And so we're going to have a look at the.42:21Have a look at the input that's received, so essentially it's part of this YAML. We're going to analyze the.42:41Actual range and then check to see whether it's the right thing. This one is fully generated and so I I think actually in terms of if you're looking at use cases of where you can use agentic AI in this development, I think rule based testing is a good place to look at, but you can create, you know, ultimately whatever you want to see. So, within, let me just open another.42:47And one here I think I have quite a few in the ACI one that you can see. Okay, not too many. So we you know we can create different rules that we want based on this and then we can standardize that across all the different technologies we've got. So if you can imagine.43:07At the moment we're looking at rules here just for ACI, but actually what you can have eventually is that you could have rules that span all the different elements that you've got. So what I was doing in another project was I was checking to see whether something was configured on an F five load balancer and then based on that and whether it was correct. And then based on that, I would then.43:27Say that the rule had passed, you know, that they that it was fine to, to con to configure what they want. And that that's really the goal for all of this is that, you know, you've done a lot of the thinking or the, the things you'd have to do in a manual way, we can do them in an automated way as well. So just to pull back to.43:47The presentation. So all of these kind of topics, you know what you'll see across this whole series is gonna be different use cases that our customers are kind of trying to follow at the moment. The self service is a very large one and it's kind of split into two areas. It's one where we see a team that owns the full stack. How do they want to do that?44:05And so if you are in that.44:26Band. The the the 1st step that we should kind of focus on is really the trying to understand the users that you've got. So what we do, the majority of the times we build something called a use case catalog where we kind of say ok well these are the say the 20 things that people request from us, you know, very commonly, and these are the ones that, you know, we think are gonna be quite simple.44:28Maybe to implement and then we would start adding them in that way.44:47I used to think the best way to do it was to, was to fully do one domain and then move on to another domain, but I don't think that's necessarily true. So I I think actually the the approach that's working for customers I'm working with at the moment is they're picking the simple service requests, the ones that they can add that they have to do quite.44:51Often and that are relatively low in complexity. And then what we can do is we can build the process in order to satisfy that. And once we've done that, we've built up all the different skills that we might need in that domain. Because as soon as we've added this out, you know, we're starting to look at.45:11More than just, you know, scripting or CLI based kind of stuff. We started to add quite a few elements into this place, right? You know, we need to understand how to define these services when, you know, if you're hosting these things yourself, you've got lots of different topics that you might need to learn. And so it's good to kind of get an understanding when things are as easy as possible.45:29So when you start to then see the value out of some of those things, you then start to grow, and that's where we we see some of the broader use cases that we've got. So you might look at things like.45:49Software image management across large sets of infrastructure or you might look at full data center or branch kind of deployments, that kind of stuff. And so for that one it's good to to to be confident, you know, the different tools that we want to use in that place. The 2nd example is when you have.46:01Part your own part of the the tools that you want to kind of use against. So in that case what we do is we still take the use case catalog, but we need to define quite clearly the services that we're going to create. And so in that case there are things where I'll try and provide this as part of some of the resources from this session is where we start to provide UML based.46:21Diagrams or you know some kind of clear definition over what the different service we want to provision is. And so in that case, we're able to then give them to the people who might be the ServiceNow owners or ansible, AP owners that are gonna actually manage the portals that we've got.46:40So I hope that kind of makes sense overall. I'm gonna be providing the codes later today once I fixed that GitLab CI issue that you saw, and then you should be able to after that starts at least kind of understanding some of the components and how we build the structure into our own environments as well.46:56There is a session as well that we're going to have next week where I'm gonna look in more detail about how we can try and control some of the actions of those agents using things like hooks and rules as part of that and how we might do selection of different models, e.g..47:15So we'll cover that one next week. But for now, if you've joined us with both series, hopefully you've seen how we can integrate towards tools like Splunk and get different visibility over the process that we're running, how we can build those kind of self service capabilities as well. And then hopefully next week it will give you an idea for the future maybe about where we've seen things go after.47:31So we're just at the top of the hour and we'd left quite a bit of time for questions, so have we got any in this session? Let me just pull this up. I see NO question for the moment. Okay. No problem at all. So I think we can get a bit of time back then. It was a pleasure to speaking.47:52To all of you guys. As I mentioned before, I'm gonna be publishing the what's called the lazy gitops project later on if you want to have a look at that or any questions, you know, feel free to reach out to Raz and I.48:11I don't know if you share the email in our chat, but if you would like to ask anything unicast, you can always send me a message. But if not, it was pleasure, thank you very much and have a good day.48:23